Deploy and Host Databasus on Railway

Built for an LLM agent to deploy and use. The deploy form has no fields to fill: the administrator account is created at first boot from a generated password, and registration is closed before the service is reachable. Databasus is an open-source, self-hosted database backup tool: schedule backups of PostgreSQL, MySQL, MariaDB and MongoDB to S3, Google Drive, SFTP, Cloudflare R2 and other storages from one web UI, with retention, notifications and one-click restore.

About Hosting Databasus

This template runs one service, databasus (the web UI, the API and an embedded PostgreSQL that holds Databasus's own settings, on one public domain), with a volume at /databasus-data holding that metadata, the encryption secret key and any local backups, so your schedules, storages and backup history survive redeploys.

Locked down from boot. Upstream leaves registration open and the first account to register becomes the instance administrator, so on a public domain whoever finds it first owns your backups. The wrapper registers the administrator ADMIN_EMAIL with the generated ADMIN_PASSWORD the moment the app answers, then turns external registration off, and only then opens the public port; nothing public reaches a half-set-up instance. A redeploy finds the administrator again and logs already exists. Databasus listens on a fixed port 4005 and ignores Railway's injected PORT, so the wrapper relays PORT to it and the healthcheck reaches the app. Upstream is Databasus v3.70.0, pinned by digest.

Using it. Open https://YOUR_DOMAIN, sign in as ADMIN_EMAIL with ADMIN_PASSWORD, add a database (any host Databasus can reach, including your other Railway databases over the private network), add a storage, and set a schedule. Keep the volume's secret.key: it encrypts the stored database and storage credentials.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the generated domain of the databasus service); API base /api/v1
Private URL: http://databasus.railway.internal:4005 (the app's own port; the public port 8080 is a relay to it)
Credentials: the variables ADMIN_EMAIL and ADMIN_PASSWORD on the databasus service
Auth: POST /api/v1/sessions with {"email":"$ADMIN_EMAIL","password":"$ADMIN_PASSWORD"} returns {"token"}; send it as Authorization: Bearer $TOKEN. A write without a token answers 401 and with a wrong token 401. A signup by anyone else answers 403 registration_closed.
Health: GET /api/v1/system/health returns 200

#!/bin/sh
# needs: RAILWAY_PUBLIC_DOMAIN, ADMIN_EMAIL, ADMIN_PASSWORD (variables of the databasus service); also curl and jq.
B="https://$RAILWAY_PUBLIC_DOMAIN/api/v1"
J="Content-Type: application/json"
curl -s -o /dev/null -w "health: %{http_code}\n" "$B/system/health"
TOKEN=$(curl -s -X POST -H "$J" -d "{\"email\":\"$ADMIN_EMAIL\",\"password\":\"$ADMIN_PASSWORD\"}" "$B/sessions" | jq -r '.token // empty')
if [ -n "$TOKEN" ]; then echo "login: ok"; else echo "login: FAILED"; fi
R='{"name":"agent contract check"}'
curl -s -o /dev/null -w "write with token: %{http_code}\n" -X POST -H "$J" -H "Authorization: Bearer $TOKEN" -d "$R" "$B/workspaces"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST -H "$J" -d "$R" "$B/workspaces"
curl -s -o /dev/null -w "write with wrong key: %{http_code}\n" -X POST -H "$J" -H "Authorization: Bearer ${TOKEN}x" -d "$R" "$B/workspaces"
curl -s -o /dev/null -w "read without key: %{http_code}\n" "$B/workspaces"
curl -s -o /dev/null -w "read with token: %{http_code}\n" -H "Authorization: Bearer $TOKEN" "$B/workspaces"
curl -s -o /dev/null -w "signup by stranger: %{http_code}\n" -X POST -H "$J" -d '{"email":"stranger@example.com","password":"stranger-pass-12","name":"stranger"}' "$B/users"

A fresh deploy prints health: 200, login: ok, write with token: 201, write without key: 401, write with wrong key: 401, read without key: 401, read with token: 200 and signup by stranger: 403.

Why Deploy Databasus 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 Databasus 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 script that proves login, a write, the refusal of a write without a token and the refusal of a stranger's signup.
Locked from boot - open registration is closed before the port opens, and the administrator exists before anyone else can claim the instance.
Data survives redeploys - settings, schedules, secret key and local backups sit on a volume and the administrator is found again, not recreated.
Pinned - the upstream image is pinned by digest and the wrapper by tag and digest.
No per-database pricing - back up as many PostgreSQL, MySQL, MariaDB and MongoDB databases as you like.

Common Use Cases

Postgres backups to S3 - scheduled dumps of your Railway PostgreSQL databases to S3, R2 or Google Drive, with retention.
MySQL, MariaDB and MongoDB backups - one backup UI for every database engine you run.
Agent-managed backups - an LLM agent registers databases and storages through the API and checks backup status.
Restore drills - restore a chosen backup into a database with one click.

Dependencies for Databasus Hosting

The databasus service with its volume, created by the template. A storage (S3, R2, Google Drive, SFTP or local) and the databases to back up are added in the UI.

Deploy Databasus | (Just Updated) Postgres, MySQL and MongoDB Backup to S3 with Web UI, Signups Locked, Admin Preset