Updating

Update

oms update

It looks up the latest release, downloads the binary for your platform with the release’s SHA256SUMS, and refuses on a checksum mismatch. It then runs the new binary to check it reports the expected version, and only then swaps it in place of the running one. The swap is a rename in the same directory, so an interrupted update leaves the old binary untouched.

updating oms 0.2.0 → 0.3.0 (x86_64-unknown-linux-gnu)
checksum ok; replaced /home/you/.local/bin/oms

Then finish the update yourself — oms update deliberately does neither step:

Apply any new migrations. The server never changes its database on its own; this command is the only thing that does:
Terminal window
```
oms database migrate
```
It connects as the Postgres superuser. If oms init started PostgreSQL in Docker for you, that password was generated and lives in the container:
Terminal window
```
POSTGRES_PASSWORD="$(docker exec oms-postgres printenv POSTGRES_PASSWORD)" oms database migrate
```
Restart the server, so it runs the new binary. A running server keeps executing the old one until then.

Check without installing

oms update --check

Prints whether a newer release exists, and changes nothing.

A specific version, or a rollback

oms update --version v0.2.0

Installs exactly that release — older ones included. Note that migrations only go forward: rolling the binary back does not undo oms database migrate.

Built from source?

oms update refuses to replace a binary built from a checkout (one under a cargo target/ directory). Update it the way you built it:

git pull
(cd cockpit && npm ci && npm run build)
cargo build --release

Reinstalling instead

The installer works for updates too, and always installs the latest release:

curl -fsSL https://openoms.dev/install.sh | sh