Railway

Railway can host the Fabro server by pulling the pre-built image published to GHCR. A single deploy button spins up a container, and a Railway Volume keeps your runs, checkpoints, and sessions across redeploys.

​

One-click deploy

The button launches Railway’s template flow, which deploys the pre-built ghcr.io/fabro-sh/fabro:nightly image directly from GHCR — no Rust compilation on Railway’s builder, so deploys complete in seconds.

​

First-deploy checklist

The template covers the build; a few pieces still need to be wired up after the first deploy.

​

1. Attach a Volume for /storage

Fabro writes all persistent state — run history, checkpoints, sessions, the default token, and JWT keys — under /storage. Railway containers have ephemeral filesystems, so without a Volume that directory is wiped on every redeploy. In the Railway dashboard: Service → Settings → Volumes → New Volume, mount path /storage. 10 GB is a reasonable starting size; grow as needed.

​

2. Confirm the target port

Railway sets $PORT automatically and expects the container to bind to it. The Fabro image honors $PORT and falls back to 32276, and it exposes 32276, so Railway’s default HTTP routing works without any manual port configuration. If you override the port in Service → Settings → Networking → Target Port, match the value to $PORT.

​

3. Set bootstrap environment variables

Add variables in Service → Variables as needed. The Server Configuration reference has the full list. Railway process env is for bootstrap values only: Do not put optional integration secrets in Railway variables for server runtime. After the server is running, add LLM provider keys, Slack, Daytona, Brave Search, GITHUB_TOKEN, and GitHub App secrets to the server vault with fabro secret set, fabro provider login, or fabro install. No .env file is auto-loaded inside the container; bootstrap variables come from Railway’s environment.

​

Accessing your Fabro server

Once the deploy is healthy, Railway exposes a *.up.railway.app URL (or your custom domain). Two things to grab:

1. The dev token — on first boot, Fabro writes one to /var/fabro/dev-token and logs it. Find it in the Railway deploy logs or run railway run cat /var/fabro/dev-token from the Railway CLI.
2. Point your local CLI at the server — add the Railway URL to ~/.fabro/settings.toml:
   ~/.fabro/settings.toml

   [cli.target]
   type = "http"
   url = "https://<your-service>.up.railway.app/api/v1"
   
   Then commands like fabro model list --server <url> will hit your Railway instance.

See Server Operations for the full auth and CLI-pointing story.

​

Redeploys and updates

Railway re-pulls the GHCR image on every deploy. The template uses the :nightly tag by default, so redeploying picks up the latest nightly automatically. To pin a specific version, change the image in Service → Settings → Source to ghcr.io/fabro-sh/fabro:<version> and redeploy. The /storage Volume survives redeploys, so runs and checkpoints persist.

​

Caveats

• Volume is load-bearing. Without a Volume mounted at /storage, a redeploy silently wipes all state — including the dev token and JWT signing keys. Attach it before submitting any real runs.
• Single replica. Fabro’s server currently assumes one process owns /storage. Don’t scale the service to multiple replicas.
• Architecture. Railway runs x86_64 (amd64) containers by default. The :nightly tag is multi-arch, but the arm64 variant is not currently usable — stay on amd64, which is Railway’s default.

​

Next steps