Skip to main content

Upgrading

Your data lives in a named volume and survives upgrades and restarts.
There is no migration step for you to run. npm start runs prisma migrate deploy before the server comes up, so every deploy applies whatever is pending. The Docker image and the Railway start command both do this.
npm run dev applies no migrations. Only start does. If you are running from source in development, run npx prisma migrate deploy yourself after pulling schema changes.

Backups

The database is the instance. Every account, every brain dump, every resume document, every application, every profile photo — photos are stored as data URIs in the owning row rather than in a file store, so there is no second thing to back up.
On a managed database, use whatever that platform gives you. Railway’s Postgres has its own backup facility.
A dump is the whole instance in one file, in the clear. It contains everyone’s career history. Store it accordingly, and do not leave it in a repository or a shared drive.

Restoring

Then start the app. It applies any migrations the dump predates on the way up.

After an upgrade

Ask, rather than clicking around:
Is anything broken on this instance?
admin_health checks database reachability and response time, whether every migration finished, whether email is configured and whether the last send succeeded, whether Stripe is still calling the webhook, when an assistant last made a tool call, and how many errors were recorded in the last 24 hours. Each check comes back ok, warn or down with a plain-language summary. The migration check is the one that matters after an upgrade: a half-applied migration is the failure mode that is invisible until somebody hits the screen that needs it. Health and errors →