Railway

Deploy the repo, and let the first build finish. It will start, fail its health check and restart — that is expected until the volume exists, because with no volume there is nowhere durable for the database.

Add a volume mounted at /data. In the service: Settings → Volumes → Add Volume, mount path /data.

This is the step no config file can do for you, and skipping it is the mistake worth avoiding: without it the app still runs, writing the database and every upload into the container filesystem, and loses all of it on the next deploy. It looks like it works right up until it doesn't.

Set the variables in the service's Variables tab:

AUTH_SECRET=<openssl rand -base64 48>
APHEX_SECRET_ENCRYPTION_KEY=<openssl rand -base64 48>
APHEX_ASSET_SIGNING_SECRET=<openssl rand -base64 48>
APHEX_SQLITE_URL=file:/data/aphex.db
APHEX_UPLOADS_DIR=/data/uploads
APHEX_EMBEDDED_WORKER=true

Keep the three secrets somewhere durable — rotating AUTH_SECRET signs everyone out and invalidates every API key.

Generate a domain — Settings → Networking → Generate Domain. Railway exposes it to the container as RAILWAY_PUBLIC_DOMAIN, and the entrypoint derives AUTH_URL and ORIGIN from it, so sign-in works without you setting a URL by hand.

Adding a custom domain later? Set AUTH_URL explicitly then — the derived value keeps following the railway.app hostname, and outgoing email links would keep pointing there.

Sign up at /login. The first account becomes super admin, so do it now, or set APHEX_BOOTSTRAP_EMAIL first to restrict the claim to your address.

Add the database. In the project: New → Database → Add PostgreSQL. Railway provisions it and exposes its connection string to other services in the project.

Point the app at it, in the app service's Variables:

APHEX_DATABASE=postgres
DATABASE_URL=${{Postgres.DATABASE_URL}}

The ${{Postgres.DATABASE_URL}} reference is Railway's own syntax — it resolves to the database service's URL and follows it if the credentials rotate. Use the exact service name shown in your project if you renamed it.

Then remove APHEX_SQLITE_URL. Migrations in drizzle/ apply on container start.

Deal with the media. The volume is now only holding uploads. Either keep it mounted at /data with APHEX_UPLOADS_DIR=/data/uploads — simple, but still pins you to one instance — or move media to a bucket and drop the volume entirely:

S3_ENDPOINT=…
S3_BUCKET=…
S3_ACCESS_KEY_ID=…
S3_SECRET_ACCESS_KEY=…
S3_PUBLIC_URL=…

All four of the first must be set together. With some but not all of them set the app falls back to local disk and logs a warning naming the ones it didn't find — worth reading the boot log after the first deploy, because uploads written to local disk here do not survive the next one.

If you scale past one replica, two things change, and both are quiet when you get them wrong.

The worker moves out of the app. Turn APHEX_EMBEDDED_WORKER off — each replica would otherwise run its own queue loop against the same queue — and replace it, rather than simply removing it:

APHEX_WORKER_SECRET=<openssl rand -base64 48>

That enables POST /api/internal/workers/run (it 404s while the secret is unset, so it is never an unauthenticated surface). Then drive it from a second Railway service on a cron schedule — same repo, Settings → Cron Schedule of * * * * *, with the start command:

curl -fsS -X POST "$AUTH_URL/api/internal/workers/run" \
  -H "Authorization: Bearer $APHEX_WORKER_SECRET"

Switching the embedded worker off without doing this leaves the queue with nothing draining it: scheduled publishes are accepted, report success, and never happen.

Migrations move to a pre-deploy step, so N containers don't race through the same DDL on rollout. That takes both switches, because they are separate code paths: APHEX_DB_AUTO_MIGRATE=false stops the app migrating on boot, and APHEX_SKIP_MIGRATE=true stops the container entrypoint doing it. Set only one and the other still runs.

See Operations → Background jobs.