# Upgrade
URL: https://usememos.com/docs/operations/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 [#before-every-upgrade]

1. Back up the database and attachments — see [Backup & Restore](/docs/operations/backup-restore).
2. Read the [changelog](/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.

## API reference support window [#api-reference-support-window]

The online API reference publishes the current `main` schema and the two newest
minor release series. When a new minor series is added, the oldest rendered
reference is retired. Historical OpenAPI YAML snapshots remain in the website
repository for reproducibility, but they are not maintained as supported online
documentation.

If your instance falls outside this window, upgrade it before developing or
debugging an integration against the current API reference.

## Upgrading to 0.30 [#upgrading-to-030]

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]

```bash
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](/docs/deploy/docker).

## Docker Compose [#docker-compose]

```bash
docker compose pull
docker compose up -d
```

## Binary [#binary]

1. Stop the service (`systemctl stop memos` or your supervisor's equivalent).
2. Replace the binary with the new release from [GitHub releases](https://github.com/usememos/memos/releases).
3. Start the service and watch the logs for migration output.

See the [Binary guide](/docs/deploy/binary) for service setup.

## Pinning versions [#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 [#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 [#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.