Deploy and Host Backrest on Railway

Built for an LLM agent to deploy and use. The deploy form has no fields. Backrest, the web UI and API that schedules and runs restic backups, comes up with the admin login already created from a generated password, a volume that keeps its configuration, history and a default repository folder across redeploys, and a public HTTPS address. The contract below lists every address, variable name and one script that registers a restic repository and lists its snapshots.

Backrest here is the official garethgeorge/backrest image, version 1.14.1, a self-hosted orchestrator around the restic backup tool. You point it at a restic repository (a local folder, S3, Backblaze B2, SFTP or anything rclone supports), add plans with schedules and retention, and it runs backups, prunes, checks and restores, with a UI to browse snapshots.

About Hosting Backrest

This template runs one service from a wrapper image pinned by digest. The wrapper makes Backrest listen on Railway's port, writes the admin user into its config before the first request (so there is no first-visit "create a user" screen that whoever finds the URL first could claim), and keeps everything on the single volume mounted at /var/lib/backrest: configuration, task history, the restic cache and a repos/ folder for local repositories. The admin user is admin and its password is BACKREST_ADMIN_PASSWORD, generated at deploy time; changing the variable and redeploying changes the password.

Backrest backs up files that the Backrest process can read. On Railway that means data in this service's own volume, or data pulled over the network. To back up another Railway service's volume, run a restic or database dump job that writes into a repository on S3 or B2, and use this Backrest to schedule, prune, verify and restore from that repository. Use an object-storage repository for anything you cannot lose: a local repository on the same volume protects against deleted files, not against losing the volume.

Agent contract

Public URL: BACKREST_PUBLIC_URL (https:// plus the service's RAILWAY_PUBLIC_DOMAIN)
Private URL: http://backrest.railway.internal:8080
Credentials: BACKREST_ADMIN_PASSWORD (generated, 32 characters); the user name is admin
Auth: HTTP basic auth with user admin and password $BACKREST_ADMIN_PASSWORD on every /v1.Backrest/* call (JSON over HTTP POST, Content-Type: application/json)
Health: GET / returns 200 without authentication; API calls without credentials return 401

# needs: BACKREST_PUBLIC_URL and BACKREST_ADMIN_PASSWORD from the backrest service variables
API="$BACKREST_PUBLIC_URL/v1.Backrest"
AUTH="admin:$BACKREST_ADMIN_PASSWORD"
REPO_PW=$(head -c 16 /dev/urandom | od -An -tx1 | tr -d ' \n')
curl -s -o /dev/null -w "health: %{http_code}\n" "$BACKREST_PUBLIC_URL/"
curl -s -o /dev/null -w "no auth: %{http_code}\n" -X POST -H 'Content-Type: application/json' -d '{}' "$API/GetConfig"
curl -s -u "$AUTH" -X POST -H 'Content-Type: application/json' -d '{"repo":{"id":"local","uri":"/var/lib/backrest/repos/local","password":"'"$REPO_PW"'"}}' "$API/AddRepo" | head -c 300; echo
curl -s -u "$AUTH" -X POST -H 'Content-Type: application/json' -d '{}' "$API/GetConfig" | head -c 300; echo
curl -s -w "list snapshots: %{http_code}\n" -u "$AUTH" -X POST -H 'Content-Type: application/json' -d '{"repoId":"local"}' "$API/ListSnapshots"

A fresh deploy prints health: 200, then no auth: 401, then the configuration with the new repository local (its id, uri and the user admin), the configuration read back, and list snapshots: 200 with an empty list because nothing has been backed up yet. The script creates a restic repository inside the volume at /var/lib/backrest/repos/local and stores its generated password in Backrest's configuration; running it twice fails the second time because the repository id already exists.

Why Deploy Backrest on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Backrest on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Agent-ready - no deployer fields, a contract block and one working add-repository-and-list-snapshots script.
Login pre-set - the admin user exists before the first request, with a generated password; no setup screen to claim.
Persistent - a volume at /var/lib/backrest holds config, history, cache and local repositories, write-tested at every boot, and the image is pinned by digest.
Health-checked - Railway restarts the service if the UI stops answering.

Common Use Cases

Scheduled restic backups with a UI - plans, retention rules, prune and integrity checks without writing cron jobs.
Backups to S3 or Backblaze B2 - one place to define repositories, see snapshots and restore files.
Backup control plane for other services - agents and scripts manage repositories and plans through the JSON API.
Restore drills - browse a snapshot and restore a file or folder from the web UI.

Dependencies for Backrest Hosting

None. Object-storage credentials (S3, B2) are only needed when you add a remote repository.

Deployment Dependencies

Implementation Details

Variable	Purpose
`BACKREST_ADMIN_PASSWORD`	Generated password of the `admin` user. Changing it and redeploying rotates the login.
`BACKREST_PUBLIC_URL`	HTTPS address of the service.

Backrest listens on Railway's PORT (8080). Add BACKREST_ADMIN_USER as a variable to use a user name other than admin.