Deploy and Host Databasement on Railway

Built for an LLM agent to deploy and use. There is no registration page to open: the admin account and an API token are created from generated variables on first boot, and the contract below lists every address, variable name and one script that checks health and calls the authenticated API.

Databasement is an open source, self-hosted database backup manager. You register MySQL, MariaDB, PostgreSQL, MongoDB, Redis or SQLite servers, schedule backups, send the dumps to S3-compatible storage, SFTP or a local volume, and restore a snapshot onto any registered server from a web UI or a REST API.

About Hosting Databasement

This template runs one service: the official davidcrty/databasement v1.10.10 image, pinned by digest, with a volume on /data. The volume holds the SQLite application database (users, servers, schedules, snapshot records) and the local backup storage, so they survive redeploys. The image's web server, queue worker and scheduler run together in this one container.

Upstream makes the first visitor to /register the administrator, which on a public Railway domain means anyone who finds the URL first. This template closes that: on first boot, while the user table is empty, it creates the admin user admin@databasement.example.com with the password in DATABASEMENT_ADMIN_PASSWORD, and registers DATABASEMENT_API_TOKEN as an API token for that user. The account is created on the first boot only, so changing the password variable later does not change the password; change it in the dashboard instead. The application key is derived from DATABASEMENT_APP_SECRET, so encrypted server credentials stay readable after every redeploy. The image's fixed port is moved to Railway's injected PORT so the healthcheck and the public domain reach it.

Backups are written to the volume by default. For off-site copies add an S3-compatible volume in the dashboard (Volumes, then Add) and point a schedule at it.

Agent contract

Public URL: DATABASEMENT_PUBLIC_URL (https:// plus the service's RAILWAY_PUBLIC_DOMAIN). The dashboard is at /, the REST API under /api/v1.
Private URL: http://databasement.railway.internal:8080, exposed as DATABASEMENT_PRIVATE_URL.
Credentials: DATABASEMENT_ADMIN_PASSWORD (password of the admin user admin@databasement.example.com), DATABASEMENT_API_TOKEN (API token for that user), DATABASEMENT_APP_SECRET (server-side key material; clients never send it).
Auth: API calls send Authorization: Bearer DATABASEMENT_API_TOKEN and Accept: application/json. The dashboard signs in with the admin email and password.
Health: GET /health returns 200 without credentials.
API: GET|POST /api/v1/database-servers, GET /api/v1/database-servers/{id}/test-connection, POST /api/v1/database-servers/{id}/backup, POST /api/v1/database-servers/{id}/restore, GET|POST /api/v1/backup-schedules, GET /api/v1/jobs.

# run with DATABASEMENT_PUBLIC_URL and DATABASEMENT_API_TOKEN set
U="$DATABASEMENT_PUBLIC_URL"
curl -s -o /dev/null -w "health: %{http_code}\n" "$U/health"
curl -s -o /dev/null -w "no token: %{http_code}\n" -H "Accept: application/json" "$U/api/v1/database-servers"
curl -s -o /dev/null -w "with token: %{http_code}\n" -H "Accept: application/json" -H "Authorization: Bearer $DATABASEMENT_API_TOKEN" "$U/api/v1/database-servers"
curl -s -H "Accept: application/json" -H "Authorization: Bearer $DATABASEMENT_API_TOKEN" "$U/api/v1/database-servers" | sed -n 's/.*"data":\(\[[^]]*\]\).*/servers: \1/p'
curl -s -o /dev/null -w "register closed: %{http_code}\n" "$U/register"

A fresh deploy prints health: 200, no token: 401, with token: 200, servers: [] and register closed: 401.

Why Deploy Databasement 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 Databasement 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 - generated admin password and API token, contract block and one working script; no registration page.
No claimable admin - the first-visitor-becomes-admin hole is closed before the URL is public.
State survives redeploys - users, schedules, snapshot records and local backups live on one volume, and credentials stay decryptable.
A working port - the image's fixed port is moved to Railway's injected port, so the healthcheck passes.
Backups next to your databases - register the Postgres, MySQL or MongoDB services in the same Railway project over the private network.

Common Use Cases

Scheduled backups for Railway databases - dump Postgres, MySQL, MariaDB or MongoDB services on a cron schedule with retention rules.
Restore into staging - pull a production snapshot onto another server with one API call.
Off-site copies - ship dumps to S3-compatible storage or SFTP.

Dependencies for Databasement Hosting

One Railway volume on /data, created by the template.

Deployment Dependencies

Implementation Details

Variable	Purpose
`DATABASEMENT_ADMIN_PASSWORD`	Password of the admin user, read on the first boot only. Generated per deploy.
`DATABASEMENT_API_TOKEN`	API token registered for the admin user at boot. Generated per deploy.
`DATABASEMENT_APP_SECRET`	Source of the Laravel application key. Generated per deploy; do not change after first boot.
`APP_URL`	Public base URL used for links and redirects.
`DATABASEMENT_PUBLIC_URL`	HTTPS address for clients outside Railway.
`DATABASEMENT_PRIVATE_URL`	Address on the private network, for services in the same project.

The start command points SQLite at /data/database.sqlite, sets the web server to listen on PORT, derives APP_KEY, hands the volume to the image's unprivileged user, runs migrations, creates the admin and token if missing, then runs the image's own start script.