Slik self-hoster du Memos i 2026: Notater, API-tilgang og sikkerhetskopier

Se på Memos som et lite system, ikke som et Docker-image. Målet for brukeren er tydelig: raske Markdown-notater med et API. Distribusjonen er bare god nok når du kan opprette et privat notat og et vedlegg, hente dem via API-et, redigere notatet og bekrefte at det fortsatt finnes etter at containeren er erstattet.

Dette avdekker feilen operatører møter etter lokal testing: databasefilen ligger på containerlaget og forsvinner når containeren erstattes. Det gjør også planen for sikkerhetskopiering og oppgradering konkret nok til å testes.

Gjør den lokale kommandoen om til en tjeneste du kan inspisere

Den første containeren bør være enkel å slette og opprette på nytt. Hold data utenfor det skrivbare laget, bind port 5230 bare der proxytjenesten kan nå den, og send inn konfigurasjon ved kjøring.

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 image-versjonen etter den første testen. Les den tidligste oppstartsfeilen i stedet for den siste omstarts-meldingen, verifiser hvert mount med docker inspect, og følg loggene mens du oppretter et privat notat og et vedlegg, henter dem via API-et, redigerer notatet og bekrefter at det fortsatt finnes etter at containeren er erstattet. Denne sekvensen skiller en feil i image-kommandoen fra et problem med avhengigheter eller tillatelser.

Definer først hva som betyr suksess for Memos

Skill mellom fire områder for Memos: ingress, lytteren på 5230, persistent state og støttetjenester eller lokal kapasitet. Kravet til det lokale runtime-miljøet er ett persistent volume for den innebygde databasen og ressursene. Test denne grensen før publisering og på nytt etter at en container er erstattet.

Kjør den kjente, fungerende transaksjonen — opprett et privat notat og et vedlegg, hent dem via API-et, rediger notatet og bekreft at det fortsatt finnes etter at containeren er erstattet — før du anser separasjonen som fullført. Mål SQLite-skrivinger, vekst i vedlegg, API-trafikk og søk på tvers av oppsamlede notater, og lagre resultatet sammen med distribusjonsdokumentasjonen. Det gir både et akseptansekriterium og det første kapasitetsgrunnlaget.

Ikke gi Memos hele vertsmaskinen

For Memos er den verdifulle overflaten ikke nødvendigvis landingssiden. Den vanligste feilen er å la registrering være åpen lenger enn planlagt. Motvirk dette bevisst: steng registrering når det er riktig, og hold private notater bak en sterk konto og HTTPS.

Memos har ingen obligatorisk bootstrap-hemmelighet i dette grunnoppsettet. Beskytt i stedet den faktiske administratorkontoen eller autentiseringen oppstrøms. Bruk en containerbruker uten privilegier når imaget støtter det, og mount ingen uvedkommende credentials. Bruk rate- eller størrelsesbegrensninger ved ingress der upålitelig arbeid kan forbruke SQLite-skrivinger, vedleggsvekst, API-trafikk og søk på tvers av oppsamlede notater.

TLS er enkelt – genererte URL-er er det ikke

Unngå midlertidige og permanente offentlige origins for Memos. Bruk i stedet en stabil HTTPS-origin for nettleser- og API-klienter, pek det valgte DNS-navnet til plattformruten, og proxytjen bare til port 5230.

Test denne handlingen utenfra vertsmaskinen: opprett et privat notat og et vedlegg, hent dem via API-et, rediger notatet og bekreft at det fortsatt finnes etter at containeren er erstattet. Hvis ingress feiler, dekker veiledningen for feilsøking av 502 Bad Gateway feil med porter og lyttere. Hvis Memos mottar forespørselen, men databasefilen ligger på containerlaget og forsvinner etter at containeren er erstattet, peker bevisene nå lenger enn proxytjenesten.

Bevis at Memos overlever en erstatning

Et container-image kan lastes ned på nytt. Memos-databasen og opplastede ressurser kan ikke det. Mount /var/opt/memos før bootstrap, skriv ufarlige eksempeldata, og erstatt containeren for å bevise at denne banen faktisk er persistent. Inspiser det faktiske mountet i stedet for å stole på et Compose-filnavn, og kontroller at runtime-brukeren kan skrive der Memos forventer det.

Velg oppbevaringstid og en destinasjon utenfor vertsmaskinen, og øv på gjenoppretting uten å berøre produksjonen. Øvelsen er bare godkjent når brukere, notater, tagger og ressurser er tilbake, og API-et henter det kjente private notatet. For databasebasert state bør du kombinere storage-snapshots med applikasjonskonsistente eksporter, som beskrevet i point-in-time recovery versus snapshots.

Fem kontroller som er bedre enn container-health

Ikke bruk trafikken fra den første brukeren som akseptansetest for Memos. Forbered ufarlig eksempeldata, og kjør hele handlingen «opprett et privat notat og et vedlegg, hent dem via API-et, rediger notatet og bekreft at det fortsatt finnes etter at containeren er erstattet». Noter den nøyaktige offentlige URL-en, resultatet, image-referansen og loggintervallet som hører til kjøringen.

Erstatt containeren og gjenta uten å bygge dataene på nytt. Gjenopprett deretter til en tom vertsmaskin. Gjenopprettingskravet er at brukere, notater, tagger og ressurser kommer tilbake, og at API-et henter det kjente private notatet. Overvåk SQLite-skrivinger, vedleggsvekst, API-trafikk og søk på tvers av oppsamlede notater i hver gjennomgang, og definer et varsel rundt svekkelse av transaksjonen i stedet for rundt inaktive containermålinger.

Én siste kontroll bør feile med vilje: send inn ufarlige data nær ressurs- eller formatgrensen som gjelder for denne grensen: databasefilen ligger på containerlaget og forsvinner etter at containeren er erstattet. Kontroller at Memos-meldingen som oppstår, identifiserer den relevante grensen i stedet for å utløse sletting av data eller en endeløs omstart. Gjenopprett den gyldige tilstanden, og bekreft at den samme eksempeltransaksjonen lykkes. Ta med denne korte øvelsen i release-sjekklisten.

Logger som gir svar på neste spørsmål

Bruk «opprett et privat notat og et vedlegg, hent dem via API-et, rediger notatet og bekreft at det fortsatt finnes etter at containeren er erstattet» som Memos-smoketesten etter hver distribusjon. Støttemålingene er SQLite-skrivinger, vedleggsvekst, API-trafikk og søk på tvers av oppsamlede notater. Varsle når disse ressursene nærmer seg et punkt som svekker brukerhandlingen.

Den største endringsrisikoen er at databasemigreringer i Memos bør øves på mot en kopi, fordi hele tjenestetilstanden ligger i én kompakt bane. En trygg release starter med et gjenopprettbart snapshot og validerer alle irreversible tilstandsendringer før trafikken flyttes. Når databasefilen ligger på containerlaget og forsvinner etter at containeren er erstattet, bør du beholde den mislykkede containeren lenge nok til å lese konfigurasjonen og den første feilen.

Bruk Dockup for plattformlaget

Dockup fjerner manuelt arbeid med reverse proxy og livssyklus rundt Memos. Tjenesten får en stabil HTTPS-rute til 5230, injisert konfigurasjon og persistent storage når containere erstattes. En tilkoblet kundeserver følger samme modell som databehandling driftet av Dockup.

Etter oppstart må du oppfylle applikasjonskontrakten: bruk en stabil HTTPS-origin for nettleser- og API-klienter, bekreft det lokale kravet — ett persistent volume for den innebygde databasen og ressursene — og kjør dette beviset: opprett et privat notat og et vedlegg, hent dem via API-et, rediger notatet og bekreft at det fortsatt finnes etter at containeren er erstattet. Slik forblir ettklikksopplevelsen nyttig uten å skjule detaljene som gjør Memos mulig å gjenopprette og sikre.

Vanlige spørsmål

Hva trenger Memos for en produksjonsdistribusjon?

Rout Memos-containeren på port 5230 gjennom én HTTPS-origin. Kravet til det lokale runtime-miljøet er ett persistent volume for den innebygde databasen og ressursene. Ikke erklær Memos som klar før du kan opprette et privat notat og et vedlegg, hente dem via API-et, redigere notatet og bekrefte at det fortsatt finnes etter at containeren er erstattet.

Hvilke Memos-data bør inngå i en sikkerhetskopi?

Gjør /var/opt/memos persistent, og ta med Memos-databasen og opplastede ressurser i det samme gjenopprettingsmanifestet. En ren Memos-gjenoppretting er bare godkjent når brukere, notater, tagger og ressurser er tilbake, og API-et henter det kjente private notatet.

Krever Memos HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Memos-originen, og hold port 5230 på den interne ruten. Bruk Memos-innstillingen riktig: benytt en stabil HTTPS-origin for nettleser- og API-klienter. For Memos beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for konsekvent klientatferd som er avhengig av origin.

Hvordan bør en Memos-oppgradering testes?

Gjenopprett gjeldende Memos-state til en isolert distribusjon, bruk kandidatversjonen, og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom fordi databasemigreringer i Memos bør øves på mot en kopi, siden hele tjenestetilstanden ligger i én kompakt bane. Behold det forrige Memos-imaget til grensen for datamigrering og rollback er forstått.