docs/RAILWAY.md

Deploying on Railway

Railway is the sturdier of the two targets: no port/app_port coupling, cheap volumes, and no always-on/idle-GC surprises. There is no free always-on tier.

Steps

1. Create a project and point a service at this repo (or railway init + railway up). railway.json selects the Dockerfile builder.

2. Set variables:

   railway variables --set OPENCODE_SERVER_PASSWORD="$(openssl rand -base64 24)"
   railway variables --set OPENCODE_API_KEY=...        # and/or ANTHROPIC_API_KEY, etc.
   

3. Attach a volume with mount path /data. Without it, every redeploy wipes sessions, provider logins and uncommitted code. entrypoint.sh picks /data up automatically and logs which mode it chose.

4. Generate a domain (Settings → Networking → Generate Domain) and open it.

$PORT is injected by Railway and used automatically — do not hardcode a port.

Do not set a healthcheck path

Every route requires basic auth, so /api/health returns 401 to an unauthenticated prober and Railway would mark the deploy failed. Leave healthcheckPath unset and let Railway consider the service live once the process is listening.

Getting your code in

There is no repo in the container. From the app's terminal:

git clone https://github.com/you/your-repo.git

For pushes, add a deploy key or use a PAT. Anything outside /data is lost on redeploy.

Restarts kill in-flight runs

A redeploy or crash takes the container with it, including any agent run in progress. Session state survives if it lives on the volume; the interrupted run does not.