Railway paused builds two days in a row. Can you move your app without moving its database?

Your app may still be serving requests while its hosting dashboard is down. That is a good time to ask a harder question: if you had to deploy the app somewhere else, could it reach the same database without first logging into the broken platform?

Railway reported build interruptions on October 20 and 21, 2026. The second incident also affected its dashboard, API, CLI and support access. These reports do not establish that every running app or database stopped. They do show why a recovery plan needs to account for losing the tools you normally use to deploy and configure your services.

I build Layerbase, a database host. Separating your database from your app host can give you more recovery options. It does not keep a Railway-hosted app online during a Railway outage, and Layerbase can have outages too.

What Railway actually reported

Incident snapshot: October 21, 2026, using Railway's updates through 13:40 UTC (8:40 AM Central). This is a dated account, not a live status feed. Check the linked incident pages for subsequent updates.

Sources: Railway's October 20 build incident and October 21 dashboard/API incident.

The official history also records September 29 deployment/API degradation, September 30 domain routing disruption and October 4 slow attached storage for some US West users. Those were different incidents with different scopes. Their dates alone do not establish a common cause or predict the next failure.

The useful question is what you can do when your normal deployment path is unavailable.

Your running database and its dashboard are different dependencies

A dashboard outage can leave an existing database connection working. If you already have a reachable endpoint and credentials, an app deployed elsewhere may still connect to a Railway database. You do not necessarily have to move the data to move the app.

The difficulty is when the escape route needs a change you cannot make: enabling a public endpoint, retrieving credentials, changing a network rule, restoring a snapshot, or creating a replacement service through an unavailable API.

A database hosted separately can remove some of those dependencies from the app host. A tested external connection lets a replacement app use the same data without copying it during the incident. That is a recovery advantage, not automatic failover. You still need a working destination host, configuration, secrets, routing and a way to stop duplicate workers.

It also creates a new dependency. Two vendors can share an upstream provider, and either vendor can fail independently. Choose separation for the recovery path it enables, not for a promise of zero downtime.

A correction to the old “unmanaged” comparison

Our July Railway database article discussed documentation that called the templates “unmanaged services.” That is not a quote to present as Railway's current position.

The current database documentation source, checked October 21, describes Railway maintaining templates and shipping image security patches. Users turn on backups, point-in-time recovery and high availability; the source describes automatic failover once HA is enabled. It also defines limits on database support and leaves schema, queries and data with the user.

Those capabilities deserve credit. They do not answer a separate question: can you recover while the platform used to operate them is unavailable?

Railway's volume backup documentation describes scheduled and manual backups, with restores restricted to the same project and environment. Keep those backups if they suit your recovery needs. An independently stored export serves a different purpose: restoring somewhere else.

A redeploy-anywhere checklist you can test before an incident

Use one small application as the rehearsal. The target is concrete: start it on a second host, connect to a disposable copy of its data, and complete a real application transaction without opening the original host's dashboard.

1. Keep a portable build. Commit a Dockerfile or document an equivalent reproducible build. Keep a known-good image in a registry the second host can access. Test its start command, port, health check and shutdown behavior outside Railway.
2. Keep configuration recoverable. Store deployment settings and secrets in an independently accessible password manager or secrets system. Document which variables are Railway references and which are actual values. Do not commit credentials or depend on an outage-time dashboard export.
3. Prepare database access. Save the connection details securely. Test access from the replacement host with TLS and appropriate network restrictions. A private Railway hostname is not an external recovery endpoint; configure any required public access before you need it.
4. Keep an off-platform backup. For a small Postgres database, a scheduled logical export to independently controlled storage can provide a portable recovery copy. Run the schedule outside the same app platform, alert on failure, and test a restore. Daily exports can lose up to a day's writes; tighter recovery targets require a suitable continuous-backup or replication design.
5. Prepare traffic switching. Keep DNS access independent of the app dashboard. Lower a relevant DNS TTL before a planned cutover, allowing the previous TTL to expire. A low TTL does not move existing connections or guarantee instant cache turnover. Prepare certificates and test the alternate hostname too.
6. Account for everything that writes. Web servers, queue consumers, cron jobs and webhooks all matter. A second deployment must not silently duplicate billing jobs or write to a different database from the first.

Write down the time the drill takes and the age of the newest successfully restored backup. Those are more useful recovery measurements than “we can always move later.”

Manual Postgres migration when the wizard is unavailable

The Railway migration wizard uses Railway's API to discover services and connection details, then needs access to the source database. It cannot promise a migration while that API is unavailable.

A manual export can bypass discovery if you already have working database credentials and a reachable source endpoint. It cannot recover an unreachable database by itself. If the source is private-only and you cannot enable public access, wait for recovery or restore a previously exported backup elsewhere. Railway documents external access through its TCP proxy.

For a small database with an acceptable maintenance window:

1. Rehearse against an empty disposable destination first. Check PostgreSQL versions, extensions and application permissions. Use a pg_dump client at least as new as the source server; use a compatible target version and restore client.
2. Configure two local libpq service entries, railway_source and recovery_target, with the actual host, port, database, user and provider-required TLS settings. Keep passwords in a protected password file or secret store. The target must be a new, empty database.
3. For the final migration, stop all source writers, including background jobs, before taking the final dump. Keep them stopped through verification and cutover.

set -euo pipefail
umask 077
backup_file="railway-cutover-$(date -u +%Y%m%dT%H%M%SZ).dump"

pg_dump --dbname='service=railway_source' \
  --format=custom --file="$backup_file"

pg_restore --list "$backup_file" > "$backup_file.contents"

pg_restore --dbname='service=recovery_target' \
  --no-owner --no-privileges --exit-on-error \
  "$backup_file"

The PostgreSQL export documentation explains that a dump is a consistent snapshot, not ongoing replication. Later source writes are absent. A single-database dump also does not carry cluster-wide roles. The restore options above omit source ownership and grants: recreate the intended application role and permissions explicitly. If restore fails, investigate and retry into a fresh empty destination, not a partially populated one.

Check critical row counts, sequences, extensions, permissions and representative queries. Deploy the application with the target connection details, test it, and only then resume writes on the target. Retain the source without writers until you are confident in the cutover. Once the target accepts new writes, switching back to the old database would discard them unless you reconcile the changes.

For a large database or a near-zero-downtime requirement, this maintenance-window recipe is not enough. Plan and rehearse replication and cutover instead. The existing Railway migration guide covers the wizard and engine choices; the write-freeze sequence above is the conservative path for this manual migration.

The tradeoffs of keeping the database elsewhere

Latency becomes visible. Moving a chatty app's database across an ocean is a poor resilience trade. Put compute near the database, measure representative requests, and consider pooling and fewer round trips. Layerbase's shared region is US East; that may be the wrong fit for your workload.

Private-network savings change. Railway recommends private networking to avoid unnecessary egress. Public traffic leaving Railway for an external database or export destination can incur service egress, currently listed at $0.05/GB. The other provider's transfer policy also matters. Check Railway's cost-control guidance and pricing, rather than assuming a private-network hop and a cross-provider connection cost the same.

Operations cross two accounts. Credentials, incidents, support and billing now span providers. A separate database is useful when you can operate and test the resulting recovery path. It is not an improvement merely because the architecture diagram has more boxes.

For a prototype with tolerable downtime, a latency-sensitive application using Railway's private network, or a team with a tested Railway recovery setup, staying together may be the better choice. Start with independent backups and a restore drill if splitting the stack would introduce more work than you can maintain.

Keep the app where you like deploying it

You can keep the app on Railway and move only its database. If that fits your workload, start the Railway migration. Start free to evaluate Layerbase, or use Solo at $5/month to pin one database always-on when you launch. Solo includes two databases, but only one stays pinned; it is not HA or an uptime SLA. Compare the limits in our always-on Postgres guide before choosing.

The practical gain is being able to redeploy the application elsewhere without performing an emergency data migration. Build and test that route while the platforms you depend on are healthy.

FAQ

Will moving my database keep my Railway app online during an outage?

No. An external database does not make unavailable app compute or routing work. It can let a replacement app connect to the same database, provided you prepared and tested that deployment path.

Can I keep the application on Railway?

Yes. Use the external database connection details, TLS settings and suitable connection limits. Measure latency and egress before cutting over; a working connection is not proof the new layout meets your performance target.

Are Railway backups enough?

That depends on your recovery goal. Platform backups are valuable, but an independently stored, tested export gives you a route to another provider. Neither a backup schedule nor a successful file upload proves that you can restore the application.

Can I use the migration wizard during the outage?

Only if the required Railway API operations and source database access work. The manual Postgres route avoids API discovery, but still needs a reachable database or an existing backup. It does not bypass a source networking outage.

What about MySQL and Redis?

The same recovery principle applies, but the data-copy procedure differs. MySQL needs a tested engine-appropriate export, including any required routines, triggers and events; check consistency requirements for your table engines. Redis used only as a disposable cache may be rebuilt. Redis used for queues, sessions or durable state needs a plan that preserves the relevant data, expiry behavior and in-flight work. Do not substitute a Postgres dump command for either migration.