Render

Render can host the Fabro server by pulling the pre-built image published to GHCR. The repo ships a render.yaml blueprint that provisions the service and a persistent disk for /storage in one click, so your runs, checkpoints, and sessions survive redeploys.

​

One-click deploy

The button opens Render’s blueprint flow pointed at this repo. render.yaml instructs Render to build Dockerfile.deploy, which is a thin wrapper that pulls ghcr.io/fabro-sh/fabro:nightly — no Rust compilation on Render’s builder, so deploys complete in seconds. The blueprint declares:

• A web service (Docker runtime) on Render’s starter plan
• A 1 GB persistent disk mounted at /storage
• A health check on /health

​

First-deploy checklist

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

​

1. Confirm the disk is attached

Fabro writes all persistent state — run history, checkpoints, sessions, the default token, and JWT keys — under /storage. The blueprint provisions a 1 GB disk at that path automatically. Verify in Service → Disks that fabro-storage is present and mounted at /storage. Grow the size later from the same page if needed.

​

2. Confirm the target port

Render sets $PORT automatically and expects the container to bind to it. The Fabro image honors $PORT and falls back to 32276, so Render’s default HTTP routing works without any manual port configuration.

​

3. Set required environment variables

Add variables in Service → Environment as needed. The Server Configuration reference has the full list; the minimum useful set: No .env file is auto-loaded inside the container; everything comes from Render’s environment.

​

Accessing your Fabro server

Once the deploy is healthy, Render exposes a *.onrender.com 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 Service → Logs in the Render dashboard, or open Service → Shell and run cat /var/fabro/dev-token.
2. Point your local CLI at the server — add the Render URL to ~/.fabro/settings.toml:
   ~/.fabro/settings.toml

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

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

​

Redeploys and updates

Render re-pulls the GHCR image on every deploy. Dockerfile.deploy references the :nightly tag by default, so redeploying picks up the latest nightly automatically. To pin a specific version, edit Dockerfile.deploy to reference ghcr.io/fabro-sh/fabro:<version> and redeploy. The /storage disk survives redeploys, so runs and checkpoints persist.

​

Caveats

• Disk is load-bearing. /storage holds the dev token and JWT signing keys in addition to runs and checkpoints. Do not detach or resize it destructively once the service is in use.
• Single replica. Fabro’s server currently assumes one process owns /storage. Don’t scale the service to multiple instances.
• Architecture. Render runs x86_64 (amd64) containers. The :nightly tag is multi-arch, but the arm64 variant is not currently usable — stay on amd64, which is Render’s default.

​

Next steps