Sådan self-hoster du Memos i 2026: Noter, API-adgang og backups

Betragt Memos som et lille system, ikke som et Docker-image. Det brugerrettede mål med Memos er klart: hurtige Markdown-noter med en API. Deployet er kun acceptabelt, når du kan oprette en privat note og en vedhæftning, hente dem via API'en, redigere noten og bekræfte, at den stadig findes efter udskiftning af containeren.

Den skelnen afslører den fejltilstand, operatører møder efter lokal test: databasefilen ligger på containerens writable layer og forsvinder efter en udskiftning. Den gør også planen for backup og upgrades tilstrækkeligt specifik til, at den kan testes.

Gør den lokale kommando til en service, der kan inspiceres

Den første container skal være nem at slette og oprette igen. Hold data væk fra det writable layer, bind kun port 5230 dér, hvor proxyen kan nå den, og send konfigurationen ind ved runtime.

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

Pin imaget efter den indledende test. Læs den tidligste startup-fejl i stedet for den sidste restart-meddelelse, verificér hvert mount med docker inspect, og følg logs, mens du opretter en privat note og en vedhæftning, henter dem via API'en, redigerer noten og bekræfter, at den stadig findes efter udskiftning af containeren. Den rækkefølge skelner mellem en forkert image-kommando og et problem med en dependency eller permissions.

Definér først, hvad succes betyder for Memos

Adskil fire forhold for Memos: ingress, lytteren på 5230, durable state samt supporting services eller lokal kapacitet. Kravet til det lokale runtime-miljø er ét durable volume til den indlejrede database og assets. Test denne grænse før publicering og igen efter udskiftning af en container.

Kør den kendte transaktion — opret en privat note og en vedhæftning, hent dem via API'en, redigér noten og bekræft, at den stadig findes efter udskiftning af containeren — før du kalder adskillelsen fuldført. Mål SQLite writes, vækst i vedhæftninger, API-trafik og søgning på tværs af akkumulerede noter, og gem resultatet sammen med deployment-recordet. Det giver både et acceptance-kriterium og det første kapacitetsbaseline.

Giv ikke Memos hele hosten

For Memos er den værdifulde surface ikke nødvendigvis landingssiden. Den største fejl er at lade registrering være åben længere end tilsigtet. Modvirk det bevidst: Luk for registrering, når det er relevant, og hold private noter bag en stærk konto og HTTPS.

Memos har ingen obligatorisk bootstrap secret i denne baseline; beskyt i stedet den faktiske administrator-konto eller upstream authentication. Brug en unprivileged container-bruger, når imaget understøtter det, og mount ingen uvedkommende credentials. Anvend rate- eller size limits ved ingress, hvor ikke-betroet arbejde kan forbruge SQLite writes, vækst i vedhæftninger, API-trafik og søgning på tværs af akkumulerede noter.

TLS er nemt; genererede URL'er er det ikke

Undgå midlertidige og permanente offentlige origins til Memos. Brug i stedet en stabil HTTPS-origin til browser- og API-klienter, peg det valgte DNS-navn på platformens route, og proxy kun til port 5230.

Udfør denne handling udefra og væk fra hosten: Opret en privat note og en vedhæftning, hent dem via API'en, redigér noten, og bekræft, at den stadig findes efter udskiftning af containeren. Hvis ingress fejler, dækker fejlfindingsguiden til 502 Bad Gateway fejl med porte og lyttere. Hvis Memos modtager requesten, men databasefilen ligger på containerens writable layer og forsvinder efter en udskiftning, peger evidensen nu på noget andet end proxyen.

Bevis, at Memos overlever en udskiftning

Et container-image kan downloades igen; Memos-databasen og uploadede ressourcer kan ikke. Mount /var/opt/memos før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Inspicér det effektive mount i stedet for at stole på et Compose-filnavn, og kontrollér, at runtime-brugeren kan skrive dér, hvor Memos forventer det.

Vælg retention og en destination uden for hosten, og øv recovery uden at røre produktionen. Øvelsen er kun bestået, når brugere, noter, tags og ressourcer er tilbage, og API'en kan hente den kendte private note. For databasebaseret state skal storage snapshots kombineres med application-consistent exports som beskrevet i point-in-time recovery versus snapshots.

Fem checks, der er stærkere end container health

Brug ikke trafik fra den første bruger som acceptance-test for Memos. Forbered harmløs eksempel-state, og kør den komplette handling: “Opret en privat note og en vedhæftning, hent dem via API'en, redigér noten, og bekræft, at den stadig findes efter udskiftning af containeren”. Notér den præcise offentlige URL, resultatet, image-referencen og det loginterval, der er knyttet til kørslen.

Udskift containeren, og gentag uden at opbygge data igen. Gendan derefter på en tom host; recovery-betingelsen er, at brugere, noter, tags og ressourcer er tilbage, og at API'en kan hente den kendte private note. Overvåg SQLite writes, vækst i vedhæftninger, API-trafik og søgning på tværs af akkumulerede noter ved hver gennemgang, og definér en alert omkring forringelse af transaktionen i stedet for omkring inaktive container-metrics.

Én sidste check skal fejle med vilje: Send harmløst input tæt på den resource- eller formatgrænse, der er knyttet til denne grænse: databasefilen ligger på containerens writable layer og forsvinder efter udskiftning. Kontrollér, at den resulterende Memos-meddelelse identificerer den relevante grænse i stedet for at udløse sletning af data eller en uendelig restart. Gendan den gyldige tilstand, og bekræft, at den samme eksempeltransaktion lykkes. Behold denne korte øvelse i release-checklisten.

Logs, der besvarer det næste spørgsmål

Brug “opret en privat note og en vedhæftning, hent dem via API'en, redigér noten, og bekræft, at den stadig findes efter udskiftning af containeren” som Memos' smoke-test efter hvert deployment. De understøttende metrics er SQLite writes, vækst i vedhæftninger, API-trafik og søgning på tværs af akkumulerede noter; opret alerts dér, hvor disse ressourcer nærmer sig et niveau, der forringer brugerhandlingen.

Den største ændringsrisiko er, at Memos-databasemigrationer bør øves mod en kopi, fordi hele servicens state ligger i én kompakt sti. En sikker release starter med et snapshot, der kan gendannes, og validerer alle irreversible state-ændringer, før trafikken flyttes. Når databasefilen ligger på containerens writable layer og forsvinder efter udskiftning, skal du beholde den fejlede container længe nok til at læse dens konfiguration og første fejl.

Brug Dockup til platformlaget

Dockup fjerner manuelt reverse-proxy- og lifecycle-arbejde omkring Memos. Servicen får en stabil HTTPS-route til 5230, injected configuration og persistent storage under udskiftninger. En tilknyttet kundeserver følger samme model som Dockup-hosted compute.

Efter lanceringen skal applikationskontrakten være opfyldt: Brug en stabil HTTPS-origin til browser- og API-klienter, bekræft det lokale krav — ét durable volume til den indlejrede database og assets — og kør dette proof: Opret en privat note og en vedhæftning, hent dem via API'en, redigér noten, og bekræft, at den stadig findes efter udskiftning af containeren. Det gør one-click-oplevelsen nyttig uden at udviske de detaljer, der gør Memos recoverable og sikker.

Ofte stillede spørgsmål

Hvad kræver Memos for et produktionsdeployment?

Route Memos-containeren på port 5230 gennem én HTTPS-origin. Kravet til det lokale runtime-miljø er ét durable volume til den indlejrede database og assets. Kald ikke Memos klar, før du kan oprette en privat note og en vedhæftning, hente dem via API'en, redigere noten og bekræfte, at den stadig findes efter udskiftning af containeren.

Hvilke Memos-data skal med i en backup?

Persistér /var/opt/memos, og medtag Memos-databasen og uploadede ressourcer i det samme recovery-manifest. En ren Memos-restore er kun bestået, når brugere, noter, tags og ressourcer er tilbage, og API'en kan hente den kendte private note.

Kræver Memos HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Memos-origin, og hold port 5230 på den interne route. Anvend Memos-indstillingen korrekt: Brug en stabil HTTPS-origin til browser- og API-klienter. For Memos beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet klientadfærd, der afhænger af origin.

Hvordan bør en Memos-opgradering testes?

Gendan den aktuelle Memos-state i et isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi Memos-databasemigrationer bør øves mod en kopi, da hele servicens state ligger i én kompakt sti. Behold det tidligere Memos-image, indtil dets data-migrations- og rollback-grænse er forstået.