Memos self-hosting: what the docker run line mounts, and what the calendar tags cost you

Four docker flags, and the ones the quick start leaves out

The entire quick start is a single detached container with four arguments, and each one carries a decision. `--name memos` gives you a stable handle for later stops and logs. `-p 5230:5230` publishes the service on the host. `-v ~/.memos:/var/opt/memos` is the one that decides whether your notes survive: state lives in a directory under your home directory on the host, so deleting the container does not delete the notes, while running the same image without the mount keeps the notes inside the container layer where removing it discards them. The image tag is `neosmemo/memos:stable`.

docker run -d \
  --name memos \
  -p 5230:5230 \
  -v ~/.memos:/var/opt/memos \
  neosmemo/memos:stable

What this command does not contain is the rest of running a service: no reverse proxy, no TLS, no certificate, no environment variables, no database flags. The README does add one line after the command: everything Memos keeps is in `~/.memos`, so back up that one folder. The host port is also published without a host address, which is the widest form of that mapping. None of that is presented as a feature gap so much as a scope decision, since the quick start says other install options are in the deployment guide, but a reader who copies this line onto a public host has decided their own exposure.

Calendar tags and v-prefixed tags both appear, so pin with care

The README documents a calendar scheme: releases are tagged `YY.MM.N`, release candidates `YY.MM.N-rc.K`, and neither carries a `v` prefix. Older releases did use one, since the upgrade note refers to v0.31.0. The three most recent releases are 26.11.0 on 2026-11-01, 26.10.0 on 2026-10-31 and 26.10.0-rc.2 on 2026-10-27. A script that assumes one scheme will fail to resolve a tag under the other, so check the actual tag name on the releases page rather than deriving it.

The Docker tags have their own motion. `stable` follows stable releases and `canary` follows development builds, so `neosmemo/memos:stable` is a moving pointer, not a fixed artifact. The same command run twice a month apart can land on different builds, which is the reason to pin a digest if you care about repeatability. The release list also carries release candidates such as 26.10.0-rc.2, which came before 26.10.0.

Upgrading from before v0.31.0 is a two step operation

The quick start spends a sentence on upgrades and it is the one sentence worth reading twice. If you are on a release from before v0.31.0, the instruction is to run v0.31.0 once first. Older versions are covered by the upgrade requirements kept in store/migration/README.md, which is the file to open before touching a live instance. So a jump from an old tag to a new one is not a single pull, it is an intermediate hop through a specific version.

The store/ directory at the top of the repository is where that migration logic lives, next to the other backend code. A reader planning an upgrade should treat the store/migration file as part of the deploy procedure rather than as developer documentation, because the readme points at it from the operator's section. Nothing in the quick start describes what a failed intermediate migration looks like, so the safe move is to copy the mounted directory before starting rather than to read the error afterwards.

The go.mod is much wider than a capture-first note app

The module file is where the real shape of the project shows. It declares `go 1.27.2`, so building from source needs that toolchain, and then requires drivers for three database families: the MySQL driver, `lib/pq` for Postgres, and `modernc.org/sqlite`. It also requires the AWS SDK v2 including the S3 service client, plus `gofakes3`, a fake S3 implementation that the project uses somewhere in its test setup. The module file lists `cobra` and `viper` for the command line and configuration, and the transport stack includes gRPC, the gRPC gateway, protobuf, and connectrpc.

The part that surprises readers is the tail of the list: a Model Context Protocol Go SDK, an OpenAI Go client at v3, and a Google genai client are all direct requirements. Those are the pieces that make the project larger than a note logger, and they are exactly the parts a self-hoster should look at before deciding which of them an instance actually turns on. The readme's four About bullets say nothing about them, though its Around Memos list does mention an MCP server for connecting AI tools, so the dependency list is the place to see how far that goes.

No title, no folder, no template, and nothing named for export

The readme's capture story is short: a single sentence can be a whole memo, or you can write a longer entry in Markdown. Each memo stays with the day you wrote it in a personal timeline, and tags connect related thoughts across those days. The readme names no folders or templates, so the timeline and tags are the organising tools it describes. Persistence is covered by one line: everything Memos keeps is in `~/.memos`, so back up that one folder. The readme gives no export command or restore procedure, so check the deployment guide at usememos.com/docs/deploy before the first note goes in.

The web clipper writes source-linked Markdown, and its pairing is undocumented here

The browser extension is the part of Memos aimed at capture from elsewhere. It saves pages, selections, and images from the browser straight into Memos as source-linked Markdown, and it exists as a Chrome extension and a Firefox add-on. Source-linked is the useful property: a clipped page keeps the pointer back to where it came from, so a memo assembled from someone else's writing is distinguishable later from your own thought, which matters in a chronological log where every entry otherwise looks alike.

What is not stated is how the extension authenticates against a self-hosted instance. A clipper on a personal machine talking to a container on your own network is a different trust question from an extension talking to a shared host, and the readme gives no token, no URL setting, and no permission model for it. The live demo at demo.usememos.com is the fastest way to see what a clipped entry looks like before committing, and the docs at usememos.com/docs are where the pairing details belong.

A Go service with agents, context and ownership files at the root

The top level of the repository is a good map of what maintainers expect contributors to touch: `cmd/`, `core/`, `internal/`, `server/`, `store/`, `proto/`, `web/`, `markdown/`, `filter/`, `provider/`, `scripts/`, and `docs/`. A `proto/` directory alongside gRPC, the gateway, and connectrpc in the module file means the service surface is defined as an interface, which is what makes an API client and the Web Clipper possible rather than accidental. `provider/` sits next to it, and the S3 client in the module file suggests object storage is part of the design.

Alongside the code sit `AGENTS.md`, `CONTEXT.md`, `CODEOWNERS`, `SECURITY.md`, and a `.golangci.yaml`. Two of these matter to anyone other than a contributor: SECURITY.md is where vulnerability reporting goes, and CODEOWNERS says which areas have owners, which is a fast way to see where review attention sits before filing an issue. Development is active, with the last push landing on 2026-11-02 and 26.11.0 published on 2026-11-01, and the contributing guide is linked from the readme for anyone joining that work.

Editorial conclusion

People who want a private, chronological note log on infrastructure they already control will find the quick start sufficient to try it, and should first read the deployment guide for anything the four flag command leaves out, including TLS. Anyone upgrading an instance older than v0.31.0 must stage through v0.31.0 and read store/migration/README.md first, and anyone pinning a build should pin a digest or a specific tag, since the Docker stable tag moves.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes