Så självhostar du Memos 2026: Anteckningar, API-åtkomst och säkerhetskopior

Betrakta Memos som ett litet system, inte som en Docker-avbild. Målet för användaren är tydligt: snabba Markdown-anteckningar med ett API. Driftsättningen är godtagbar först när du kan skapa en privat memo och en bilaga, hämta dem via API:t, redigera dem och bekräfta att de finns kvar efter att containern ersatts.

Den skillnaden fångar det fel som operatörer stöter på efter lokal testning: databasfilen ligger på containerns lager och försvinner när containern ersätts. Den gör också planen för säkerhetskopiering och uppgraderingar tillräckligt specifik för att kunna testas.

Gör det lokala kommandot till en inspekterbar tjänst

Den första containern ska vara enkel att ta bort och skapa på nytt. Håll data borta från det skrivbara lagret, bind port 5230 endast där proxyn kan nå den och skicka in konfigurationen vid körning.

docker run -d \
  --name memos \
  --restart unless-stopped \
  -p 127.0.0.1:5230:5230 \
  -v memos-data:/var/opt/memos \
  neosmemo/memos:stable --mode prod --port 5230

Lås avbildens version efter det första testet. Läs det tidigaste startfelet i stället för det senaste omstartsmeddelandet, verifiera varje mount med docker inspect och följ loggarna medan du skapar en privat memo och en bilaga, hämtar dem via API:t, redigerar dem och bekräftar att de finns kvar efter att containern ersatts. Den sekvensen skiljer ett felaktigt image-kommando från ett beroende- eller behörighetsproblem.

Definiera först vad som räknas som lyckat för Memos

Separera fyra delar för Memos: ingress, lyssnaren på port 5230, beständigt tillstånd samt stödjande tjänster eller lokal kapacitet. Det lokala runtime-kravet är en beständig volym för den inbäddade databasen och tillgångarna. Testa den gränsen före publicering och igen efter att en container ersatts.

Kör den kända fungerande transaktionen — skapa en privat memo och en bilaga, hämta dem via API:t, redigera dem och bekräfta att de finns kvar efter att containern ersatts — innan du betraktar separationen som färdig. Mät SQLite-skrivningar, tillväxten av bilagor, API-trafik och sökning bland ackumulerade anteckningar, och spara resultatet tillsammans med driftsättningsposten. Det ger både ett acceptanskriterium och den första kapacitetsbaslinjen.

Ge inte Memos hela värdmaskinen

För Memos är den värdefulla attackytan inte nödvändigtvis landningssidan. Det vanligaste misstaget är att låta registreringen vara öppen längre än avsett. Motverka det medvetet: stäng registreringen när det är lämpligt och skydda privata memon bakom ett starkt konto och HTTPS.

Memos har ingen obligatorisk bootstrap-hemlighet i den här baslinjen. Skydda i stället det faktiska administratörskontot eller autentiseringen uppströms. Använd en containeranvändare utan privilegier när avbilden stöder det och montera inga orelaterade autentiseringsuppgifter. Tillämpa rate- eller storleksbegränsningar vid ingress där opålitlig trafik kan förbruka SQLite-skrivningar, öka mängden bilagor, belasta API-trafiken och påverka sökningen bland ackumulerade anteckningar.

TLS är enkelt – genererade URL:er är det inte

Undvik tillfälliga och permanenta publika origins för Memos. Använd i stället en stabil HTTPS-origin för browser- och API-klienter, peka det valda DNS-namnet mot plattformsrutten och proxya endast till port 5230.

Testa den här åtgärden utanför värdmaskinen: skapa en privat memo och en bilaga, hämta dem via API:t, redigera dem och bekräfta att de finns kvar efter att containern ersatts. Om ingress misslyckas beskriver felsökningsguiden för 502 vanliga fel med port och lyssnare. Om Memos tar emot begäran men databasfilen ligger på containerns lager och försvinner när containern ersätts, pekar bevisen nu bortom proxyn.

Bevisa att Memos överlever en ersättning

En containeravbild kan laddas ned igen. Memos-databasen och uppladdade resurser kan det inte. Montera /var/opt/memos före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. Inspektera den aktiva mounten i stället för att lita på ett Compose-filnamn och kontrollera att runtime-användaren kan skriva där Memos förväntar sig det.

Välj retention och en destination utanför värdmaskinen, och öva sedan på återställning utan att röra produktionen. Övningen är godkänd först när användare, memon, taggar och resurser är tillbaka och API:t kan hämta den kända privata memon. För databastillstånd ska du kombinera snapshots av lagringen med applikationskonsistenta exporter enligt beskrivningen i återställning till en viss tidpunkt jämfört med snapshots.

Fem kontroller som är bättre än container health

Gör inte trafik från den första användaren till acceptanstestet för Memos. Förbered ofarligt exempeltillstånd och kör hela åtgärden ”skapa en privat memo och en bilaga, hämta dem via API:t, redigera dem och bekräfta att de finns kvar efter att containern ersatts”. Anteckna den exakta publika URL:en, resultatet, avbildsreferensen och loggintervallet som hör till körningen.

Ersätt containern och upprepa utan att bygga om data. Återställ därefter till en tom värdmaskin. Återställningsvillkoret är att användare, memon, taggar och resurser kommer tillbaka och att API:t kan hämta den kända privata memon. Observera SQLite-skrivningar, tillväxten av bilagor, API-trafik och sökning bland ackumulerade anteckningar vid varje körning, och definiera en alert kring försämring av transaktionen i stället för kring inaktiva container-mätvärden.

En sista kontroll ska medvetet misslyckas: skicka ofarlig indata nära resurs- eller formatgränsen som hör till den här gränsen: databasfilen ligger på containerns lager och försvinner när containern ersätts. Kontrollera att Memos-meddelandet som uppstår identifierar den relevanta gränsen i stället för att utlösa dataradering eller en oändlig omstart. Återställ det giltiga tillståndet och bekräfta att samma exempeltransaktion lyckas. Behåll den här korta övningen i release-checklistan.

Loggar som besvarar nästa fråga

Använd ”skapa en privat memo och en bilaga, hämta dem via API:t, redigera dem och bekräfta att de finns kvar efter att containern ersatts” som Memos smoke-test efter varje driftsättning. Tillhörande mätvärden är SQLite-skrivningar, tillväxten av bilagor, API-trafik och sökning bland ackumulerade anteckningar. Skapa alerting där dessa resurser närmar sig en nivå som försämrar användaråtgärden.

Den största förändringsrisken är att Memos databas-migreringar bör övas mot en kopia, eftersom hela tjänstens tillstånd ligger i en enda kompakt sökväg. En säker release börjar med en återställningsbar snapshot och validerar alla enkelriktade tillståndsändringar innan trafiken flyttas. När databasfilen ligger på containerns lager och försvinner när containern ersätts ska du behålla den misslyckade containern tillräckligt länge för att läsa dess konfiguration och första fel.

Använd Dockup för plattformslagret

Dockup tar bort manuellt reverse-proxy- och lifecycle-arbete runt Memos. Tjänsten får en stabil HTTPS-route till port 5230, injicerad konfiguration och beständig lagring vid ersättningar. En ansluten kundserver följer samma modell som Dockup-hostad compute.

Efter lanseringen ska du uppfylla applikationskontraktet: använd en stabil HTTPS-origin för browser- och API-klienter, bekräfta det lokala kravet — en beständig volym för den inbäddade databasen och tillgångarna — och kör detta bevis: skapa en privat memo och en bilaga, hämta dem via API:t, redigera dem och bekräfta att de finns kvar efter att containern ersatts. På så sätt förblir one-click-upplevelsen användbar utan att förenkla bort detaljerna som gör Memos återställbart och säkert.

Vanliga frågor

Vad behöver Memos för en produktionsdriftsättning?

Routa Memos-containern på port 5230 genom en HTTPS-origin. Det lokala runtime-kravet är en beständig volym för den inbäddade databasen och tillgångarna. Betrakta inte Memos som redo förrän du kan skapa en privat memo och en bilaga, hämta dem via API:t, redigera dem och bekräfta att de finns kvar efter att containern ersatts.

Vilka Memos-data ska ingå i en säkerhetskopia?

Gör /var/opt/memos beständig och inkludera Memos-databasen och uppladdade resurser i samma återställningsmanifest. En ren Memos-återställning är godkänd först när användare, memon, taggar och resurser är tillbaka och API:t kan hämta den kända privata memon.

Kräver Memos HTTPS bakom en reverse proxy?

Använd HTTPS för den publika Memos-originen och behåll port 5230 på den interna routen. Tillämpa Memos-inställningen korrekt: använd en stabil HTTPS-origin för browser- och API-klienter. För Memos skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och gör klientbeteende som beror på origin konsekvent.

Hur bör en Memos-uppgradering testas?

Återställ det aktuella Memos-tillståndet till en isolerad driftsättning, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom Memos databas-migreringar bör övas mot en kopia, eftersom hela tjänstens tillstånd ligger i en enda kompakt sökväg. Behåll den tidigare Memos-avbilden tills gränsen för datamigrering och rollback är förstådd.