Deploy and Host Railway MySQL backups into bucket

Railway MySQL backup into bucket is a scheduled job that dumps a Railway MySQL service straight into a Railway bucket. It streams mysqldump through gzip with no temp files, refuses to store an empty or truncated dump, verifies the stored size, files each backup under a folder named after the database, and prunes old copies. Nothing leaves Railway.

About Hosting

The job runs as a Railway cron service next to your database. On each run it wakes the database if it is sleeping, connects over the private network, and pipes the dump into your bucket as a multipart upload. A run only succeeds when mysqldump exits cleanly, the dump ends with MySQL's completion trailer, and the object in the bucket matches the bytes sent. Anything else aborts the upload and shows up as a failed deployment with the error in the logs. There is no always-on process and no third-party cloud account: the template provisions the bucket and wires its credentials in through variable references, so you only point it at your database.

Common Use Cases

Nightly off-database copies of a production MySQL service, kept for a rolling 30 days
Point-in-time snapshots before a migration or a risky deploy
Backing up several MySQL services in one project, each into its own folder
Restorable exports for refreshing local development or staging databases
Replacing an external S3 backup pipeline with storage inside your Railway project

Dependencies for Railway MySQL backup into bucket Hosting

A Railway MySQL service (the official mysql image, 8.x or 9.x) in the same project
A Railway bucket (created by this template)

Implementation Details

After deploying, open the mysql-backup service's Variables tab. The database variables default to a service named MySQL; if yours is named differently, change MySQL in each reference:

Variable	Default	Purpose
`BACKUP_DATABASE_HOST`	`${{MySQL.MYSQLHOST}}`	Private-network host
`BACKUP_DATABASE_PORT`	`${{MySQL.MYSQLPORT}}`	Port
`BACKUP_DATABASE_USER`	`${{MySQL.MYSQLUSER}}`	User
`BACKUP_DATABASE_PASSWORD`	`${{MySQL.MYSQLPASSWORD}}`	Passed via an option file, never on the command line
`BACKUP_DATABASE_NAME`	`${{MySQL.MYSQL_DATABASE}}`	Schema to dump; empty dumps every non-system schema
`BACKUP_SOURCE_NAME`	`${{MySQL.RAILWAY_SERVICE_NAME}}`	Folder inside the bucket
`BACKUP_RETENTION_DAYS`	`30`	Delete older backups in that folder; `0` keeps everything

The BUCKET_* variables reference the template's bucket and need no changes.

Set the service's Cron Schedule (Settings tab) if it is not already set; 0 5 * * * runs daily at 05:00 UTC. The container runs once per schedule and exits.

Backups land at //-.sql.gz, for example MySQL/railway-2026-09-15T05-00-00Z.sql.gz. To restore:

aws --endpoint-url "$AWS_ENDPOINT_URL" s3 cp "s3://$AWS_S3_BUCKET_NAME/MySQL/railway-2026-09-15T05-00-00Z.sql.gz" .
gunzip -c railway-2026-09-15T05-00-00Z.sql.gz | mysql --host=... --port=... --user=... -p

Dumps use --databases, so they carry CREATE DATABASE and USE and restore into a fresh server without extra flags. Source: https://github.com/davidahill/railway-mysql-backup

Why Deploy 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 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.