Upgrade

Memos applies database migrations automatically on startup, so an upgrade is: back up, replace the version, start, verify. Downgrading after a migration has run is not supported — your backup is the rollback path.

Before every upgrade

1. Back up the database and attachments — see Backup & Restore.
2. Read the changelog for the versions you are skipping, especially across minor versions (0.x → 0.y), which can contain breaking changes.
3. Note your current version so you can report it if something goes wrong.

Upgrading to 0.30

Version 0.30 changes several public access and integration behaviors. Before deploying it:

• Back up the database and attachments.
• Set MEMOS_INSTANCE_URL to the canonical public URL if the instance should remain publicly accessible. An empty value now enables private mode.
• Update saved CEL shortcut expressions that use now() or Unix timestamps. Use the now timestamp value, duration arithmetic such as now - duration, and CEL timestamps instead.
• Reconfigure MCP clients to use the /mcp endpoint and service-prefixed tool names. The old aliases, prompts, resources, and unprefixed tools were removed.
• Update clients that read shared memos from GetMemoByShare (/api/v1/shares/{shareId}) to GetSharedMemo (/api/v1/shares/{shareToken}/memo).
• Review shared-memo assumptions: a share token exposes the selected memo, attachments, and reactions, but not its parent, comments, or relations.
• Review tag display settings after the per-instance tag metadata migration. Tag colors and blur rules are now stored per user.

After the upgrade, verify sign-in, public memo and RSS access if enabled, shared links, and any MCP, webhook, or API integrations you operate.

Docker

docker pull neosmemo/memos:stable
docker stop memos
docker rm memos
# re-run your original docker run command — the data volume keeps your data

The exact docker run flags are in the Docker guide.

Docker Compose

docker compose pull
docker compose up -d

Binary

1. Stop the service (systemctl stop memos or your supervisor's equivalent).
2. Replace the binary with the new release from GitHub releases.
3. Start the service and watch the logs for migration output.

See the Binary guide for service setup.

Pinning versions

neosmemo/memos:stable tracks the latest stable release, which is convenient but upgrades implicitly on every pull. For production, pin a specific version tag (for example neosmemo/memos:0.30.0) and upgrade deliberately.

Verify after upgrading

• the UI loads and you can sign in
• a new memo can be created and an existing one opens
• attachments load (storage config survived the upgrade)

Rolling back

Restore the pre-upgrade backup and start the previous version. Do not point an old version at a database that a newer version has already migrated.