Deploy Databasus

Deploy and Host Databasus on Railway

Databasus is an open-source backup tool for PostgreSQL, MySQL, MariaDB and MongoDB. It replaces the cron jobs and pg_dump scripts most teams call a backup strategy with one web interface that schedules dumps, enforces retention, ships files to storage you control, and — the part almost nobody does by hand — restores them to prove they work.

Self-host Databasus on Railway and the template gives you one service, databasus, with a persistent volume and a companion object-storage bucket. The service runs the interface and scheduler and carries an embedded PostgreSQL cluster on the volume for its metadata, so there is no separate database to operate. The databasus-backups bucket is Railway-managed object storage, and its endpoint, bucket, region and keys arrive as variables ready to register as a backup destination. Your databases stay where they are: Databasus dials out over Railway's private network, the public internet, or an SSH tunnel.

Getting Started with Databasus on Railway

Open the generated URL and sign in with the email admin and the value of DATABASUS_ADMIN_PASSWORD, which Railway generates at deploy time and shows in the Variables tab. There is no registration step to race and no shipped default to change: the account already has your password and self-service signup is off, so the instance is closed from the first request.

Create a workspace first: it groups databases, storage destinations and notifiers, and nothing else can be added until one exists. Then add a storage destination under the cloud icon in the sidebar. Choose S3, fill the form from the DATABASUS_S3_* variables — bucket, region, access key, secret key, endpoint — leave virtual-hosted style off, and press Test connection. Databasus keeps storage credentials encrypted in its own database rather than reading the environment, which is why this is a paste step.

Now add the database you want protected. Enter host, port, user, password and database name, pick the engine version, and set SSL mode to Require for a Railway-managed PostgreSQL — its certificate fails verify-ca and verify-full. Test the connection, choose a schedule and retention policy, point it at the storage you just created and press Make backup right now. A row with status, size and duration appears in the Backups tab within seconds; that is your proof the deployment works.

About Hosting Databasus

Backups look solved until the day they matter. A dump that ran is not a dump that restores, and a retention rule in a cron comment is not one that is enforced. Databasus closes both gaps, and self-hosting keeps credentials and files on infrastructure you control.

• Logical and physical backups. Native dumps for all four engines, plus full and incremental physical backups for PostgreSQL.
• Point-in-time recovery. Continuous WAL streaming, so you restore to a moment rather than to last night.
• Restore verification. A real restore into a throwaway container, reporting every table with its row count.
• Retention that is enforced. Fixed periods, fixed counts, or grandfather-father-son tiers, plus per-backup and total size caps.
• Storage you choose. Local disk, S3 and compatibles, R2, Azure Blob, Google Drive, FTP, SFTP, NAS or Rclone.
• AES-256-GCM encryption at rest, plus notifications to email, Slack, Discord, Teams, Mattermost or a webhook.
• Workspaces and roles, with audit logs and optional OpenTelemetry export.

The Railway architecture is small on purpose. databasus is the only container: interface, scheduler, and an embedded PostgreSQL 17 cluster at /databasus-data/pgdata holding metadata, the encryption key and any local-storage backups. Backups belong in the databasus-backups bucket in production, because a volume is finite and a bucket is not.

Why Deploy Databasus on Railway

Railway removes the server work around a tool whose job is reliability.

• One service, one volume, no database or queue to operate
• Private networking reaches any database in the same project by hostname
• Managed object storage included, so backups live off the volume
• Persistent storage for the metadata database and encryption key
• HTTPS and a public domain provisioned automatically

Common Use Cases

• Protecting a Railway PostgreSQL in the same project, reached at postgres.railway.internal with no public exposure.
• Consolidating backups across engines and providers from one interface.
• Meeting a low RPO with WAL streaming and point-in-time recovery instead of a nightly dump.
• Proving compliance with GFS tiers, audit logs, encrypted off-site copies and verification reports.

Dependencies for Databasus

• gridalpha/databasus-railway — the deployed image, one layer over the official databasus/databasus:latest from github.com/databasus/databasus. The layer sets the admin password before the web server starts and closes self-service signup, neither of which upstream exposes as a setting.
• Volume at /databasus-data — embedded PostgreSQL cluster, AES key, local-storage backups. Lose it and existing backups cannot be decrypted.
• databasus-backups bucket — Railway-managed object storage for backup files.

Environment Variables Reference

Deployment Dependencies

• Image: databasus/databasus · Source: github.com/databasus/databasus, Apache-2.0 · Docs: databasus.com/installation

Hardware Requirements for Self-Hosting Databasus

Dump size drives everything. Once backups go to the bucket the volume holds only metadata, but compression and staging still need working space, and parallel restore benefits from extra cores.

Self-Hosting Databasus with Docker

The smallest deployment is one container with a persistent directory:

docker run -d \
  --name databasus \
  -p 4005:4005 \
  -v ./databasus-data:/databasus-data \
  --restart unless-stopped \
  databasus/databasus:latest

The image is also on GHCR as ghcr.io/databasus/databasus:latest. To reset a password, the binary does it from the command line:

docker exec -it databasus ./main --new-password="YourNewSecurePassword" --email="admin"

A Helm chart is published at oci://ghcr.io/databasus/charts/databasus. The Railway template replaces all of it with a Deploy button.

Is Databasus Free to Self-Host?

Databasus is free and open source under Apache 2.0, with no paid tier, seat limits or feature gates — every capability above is in the build this template deploys. On Railway you pay only for infrastructure: one small service, a 5 GB volume, and object storage metered by what the backups occupy.

FAQ

What is Databasus? An open-source, self-hosted backup tool for PostgreSQL, MySQL, MariaDB and MongoDB. It schedules logical and physical backups, streams WAL for point-in-time recovery, enforces retention, encrypts files at rest and verifies that backups restore.

What does this Railway template deploy? One service running Databasus on a persistent volume, plus a Railway-managed object storage bucket for backup files. The admin password is generated at deploy time and self-service signup is disabled, so the instance is not claimable by whoever finds the URL.

Why does it need a volume if backups go to object storage? The volume holds the metadata database and the AES-256 key that encrypts your backups. Lose it and existing backups cannot be decrypted, so copy that key somewhere safe after setup.

How do I back up a Railway PostgreSQL database with Databasus? Add it using its private hostname, usually postgres.railway.internal, port 5432, with the credentials from that service's variables, and set SSL mode to Require.

Does restore verification work on Railway? The verification agent runs each test restore in a Docker container, so it needs a Docker host you supply; the agent binary downloads from the running instance. Scheduled backups, retention, WAL streaming, restores and notifications all work without it.

Can I use my own S3 bucket or Cloudflare R2 instead? Yes. Add any S3-compatible destination with its own endpoint, or use Google Drive, Azure Blob, FTP, SFTP, NAS or Rclone. The included bucket is a convenience, not a requirement.