How to back up a Railway Postgres database to Windows

Railway's PostgreSQL template runs Postgres in a service with a volume, and Railway offers backups of that volume depending on your plan. Those live inside Railway, and they go with the project. A pg_dump file on your own disk survives a deleted project, an account problem or a move to another host. Railway's own docs recommend keeping copies outside Railway too.

Step 1: Find the public connection string

Open your Postgres service in the Railway dashboard → Variables. You'll see two URLs:

• DATABASE_URL uses Railway's private network (postgres.railway.internal). It only works from other services in the same project.
• DATABASE_PUBLIC_URL goes through Railway's TCP proxy, something like postgresql://postgres:…@shuttle.proxy.rlwy.net:43125/railway. Use this one from your PC.

The proxy port is a random high number, not 5432. If there's no public URL, enable the TCP proxy under the service's Settings → Networking.

Step 2: Back it up

Take the pieces from DATABASE_PUBLIC_URL:

$env:PGPASSWORD = 'the-password-from-the-url'   # for a one-off test only
& 'C:\Program Files\PostgreSQL\18\bin\pg_dump.exe' -h shuttle.proxy.rlwy.net -p 43125 -U postgres `
    -F c -f "D:\Backups\railway-$(Get-Date -Format yyyyMMdd-HHmm).dump" railway
Remove-Item Env:PGPASSWORD

The default database is called railway. Use client tools at least as new as the Postgres version your template runs (check with SELECT version();).

Alternative: the Railway CLI tunnel

With the Railway CLI installed and the project linked, railway connect postgres --tunnel-only opens a local tunnel to the database. Point pg_dump at the local port it prints. This avoids the public proxy entirely, but the CLI has to be signed in and running at backup time, so it suits one-off dumps better than schedules.

Step 3: Schedule it

Use the script from the main Windows guide:

$Database  = 'railway'
$PgHost    = 'shuttle.proxy.rlwy.net'
$Port      = 43125
$User      = 'postgres'

and in pgpass.conf:

shuttle.proxy.rlwy.net:43125:railway:postgres:YOUR_PASSWORD

If you regenerate the TCP proxy or rotate the database password in Railway, the host, port or password changes. Update the script and the password file, or the next backup fails. The log will say could not connect or password authentication failed.

When the proxy misbehaves

Some users report that the public proxy occasionally drops long-running connections. If dumps of a large database fail partway, try in this order: regenerate the proxy (Settings → Networking), use the CLI tunnel, or run pg_dump from a small service inside the same Railway project over the private URL and ship the file out to storage.

Restoring

& "$bin\createdb.exe" -h localhost -U postgres railway_copy
& "$bin\pg_restore.exe" -h localhost -U postgres -d railway_copy --no-owner --no-privileges D:\Backups\railway-20261014-0200.dump

To restore into Railway, run the same pg_restore against DATABASE_PUBLIC_URL's host and port. See restoring a .dump file on Windows.

How PostgresBackup handles Railway

Paste DATABASE_PUBLIC_URL into PostgresBackup's connection string box. It splits out the proxy host, port, user and database for you. Create a nightly job and the background service handles the rest. If Railway changes the proxy address, Backup History shows the failed run, and you only need to update the server entry once.