Upgrading a Signet instance

Who this is for: operators replacing a self-hosted Signet binary against an existing database.

Never run two versions against one database. Drain the old version completely before the new one connects, including in rolling, canary or blue/green deployments.

Tell what you are running

Read build.date at /certification.json for this binary's UTC build day, in YYYY-MM-DD form. The field is unknown if the build timestamp is unavailable or invalid; a build outside a Git checkout still carries its build day when the build clock is available. For the exact build, open the admin dashboard behind your admin key and read the short Git hash in the Build row. That hash is unknown when the binary was built without usable Git metadata. The signet binary does not currently support --version.

Replace the process

1. Keep the previous binary and take a pre-upgrade database snapshot before starting the new binary.
2. Stop the old process, then start the new binary against the same database with the same server secret (secret at the top level of the config, or SIGNET_SECRET).

With [database] migrate = true, Signet applies pending migrations while opening the database pool, before the server binds or serves its first request. This setting defaults to true for both PostgreSQL and SQLite. If you set it to false because an external migration job owns the schema, apply the new binary's migrations before starting it.

Migration 0031, session-token hashing, is stop-the-world: it rewrites every session token into its digest in place, with no dual-read path. A process from before migration 0031 rejects every existing session after that migration commits, and sessions it creates in that window are written in the clear and unreadable by the new code.

Check the replacement

1. Read /certification.json again and check that build.date moved to the new binary's build day. Two binaries built on the same UTC day share that date; use the admin dashboard's hash to distinguish them.
2. Check that /health returns HTTP 200.
3. Complete a sign-in through your application.
4. Run signetctl stats against the instance to inspect users, active sessions, sign-ins, delivery and rate-limit counters.

Keep a way back

Starting an older binary does not undo a migration; no down-migrations ship. If a new migration has applied, restore the pre-upgrade database snapshot before starting the previous binary. If an old process served across migration 0031, the recovery is: drain every old instance, then run migration 0031 again. The rerun skips tokens already stored as digests and hashes the stranded plaintext tokens, so the cookies users still carry work again.

Read what changed

Use your build day at signetauth.dev/changelog to read what changed since that build.

Signet Cloud

Hosted Signet Cloud customers do nothing: the operator upgrades the instance. The public build day shows the move when the replacement was built on a different UTC day; the admin dashboard's hash distinguishes builds made on the same day.