How to Self-Host Memos in 2026: Notes, API Access and Backups

Treat Memos as a small system, not a Docker image. The user-facing goal for Memos is clear: quick Markdown notes with an API; the deployment is acceptable only when you can create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement.

That distinction catches the failure mode operators meet after local testing: the database file is on the container layer and disappears after replacement. It also makes the backup and upgrade plan specific enough to test.

Turn the local command into an inspectable service

The first container should be easy to delete and recreate. Keep data off the writable layer, bind port 5230 only where the proxy can reach it and pass configuration at 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 the image after the initial test. Read the earliest startup error rather than the final restart message, verify each mount with docker inspect, and follow logs while you create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement. That sequence distinguishes a bad image command from a dependency or permission problem.

Define success for Memos first

Separate four concerns for Memos: ingress, the listener on 5230, durable state and supporting services or local capacity. The local runtime requirement is one durable volume for its embedded database and assets. Test that boundary before publication and again after a container replacement.

Run the known-good transaction — create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement — before calling that separation complete. Measure SQLite writes, attachment growth, API traffic and search over accumulated notes and keep the result with the deployment record. It provides both an acceptance criterion and the first capacity baseline.

Do not give Memos the whole host

For Memos, the valuable surface is not necessarily the landing page. The main mistake is leaving registration open longer than intended. Counter it deliberately: close registration when appropriate and keep private memos behind a strong account and HTTPS.

Memos has no mandatory bootstrap secret in this baseline; protect its actual administrator account or upstream authentication instead. Use an unprivileged container user when the image supports it and mount no unrelated credentials. Apply rate or size limits at ingress where untrusted work can consume SQLite writes, attachment growth, API traffic and search over accumulated notes.

TLS is easy; generated URLs are not

Avoid temporary and permanent public origins for Memos. Instead, use a stable HTTPS origin for browser and API clients, point the chosen DNS name at the platform route and proxy only to port 5230.

Exercise this action from outside the host: create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement. If ingress fails, the 502 troubleshooting guide covers port and listener mistakes. If Memos receives the request but the database file is on the container layer and disappears after replacement, the evidence now points beyond the proxy.

Prove Memos survives replacement

A container image can be downloaded again; the Memos database and uploaded resources cannot. Mount /var/opt/memos before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Inspect the effective mount instead of trusting a Compose filename, and check that the runtime user can write where Memos expects.

Choose retention and an off-host destination, then rehearse recovery without touching production. The drill passes only when users, memos, tags and resources return and the API retrieves the known private memo. For database-backed state, pair storage snapshots with application-consistent exports as described in point-in-time recovery versus snapshots.

Five checks stronger than container health

Do not make first-user traffic the acceptance test for Memos. Prepare harmless sample state and run the complete action “create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement”. Note the exact public URL, result, image reference and log interval associated with the run.

Replace the container and repeat without rebuilding data. Next, recover onto an empty host; the recovery condition is that users, memos, tags and resources return and the API retrieves the known private memo. Observe SQLite writes, attachment growth, API traffic and search over accumulated notes in every pass and define an alert around degradation of the transaction rather than around idle container metrics.

One final check should fail on purpose: submit harmless input near the resource or format limit associated with this boundary: the database file is on the container layer and disappears after replacement. Verify that the resulting Memos message identifies the relevant boundary instead of triggering data deletion or an endless restart. Restore the valid condition and confirm the same sample transaction succeeds. Keep this short drill in the release checklist.

Logs that answer the next question

Use create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement as the Memos smoke test after every deployment. Its supporting metrics are SQLite writes, attachment growth, API traffic and search over accumulated notes; alert where those resources approach a point that degrades the user action.

The main change risk is that Memos database migrations should be rehearsed against a copy because the entire service state lives in one compact path. A safe release starts from a restorable snapshot and validates any one-way state change before traffic moves. When the database file is on the container layer and disappears after replacement, keep the failed container long enough to read its configuration and first error.

Use Dockup for the platform layer

Dockup removes manual reverse-proxy and lifecycle work around Memos. The service receives a stable HTTPS route to 5230, injected configuration and persistent storage during replacements. An attached customer server follows the same model as Dockup-hosted compute.

After launch, satisfy the application contract: use a stable HTTPS origin for browser and API clients, confirm the local requirement — one durable volume for its embedded database and assets and run this proof: create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement. This keeps the one-click experience useful without flattening the details that make Memos recoverable and secure.

Frequently asked questions

What does Memos need for a production deployment?

Route the Memos container on port 5230 through one HTTPS origin. The local runtime requirement is one durable volume for its embedded database and assets. Do not call Memos ready until you can create a private memo and attachment, retrieve it through the API, edit it and confirm it remains after container replacement.

Which Memos data belongs in a backup?

Persist /var/opt/memos and include the Memos database and uploaded resources in the same recovery manifest. A clean Memos restore passes only when users, memos, tags and resources return and the API retrieves the known private memo.

Does Memos require HTTPS behind a reverse proxy?

Use HTTPS for the public Memos origin and keep port 5230 on the internal route. Apply the Memos setting correctly: use a stable HTTPS origin for browser and API clients. For Memos, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Memos upgrade be tested?

Restore current Memos state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Memos database migrations should be rehearsed against a copy because the entire service state lives in one compact path. Keep the previous Memos image until its data-migration and rollback boundary are understood.