Railway app outage: where to host your projects instead

Railway has experienced at least five major platform incidents since November 2025. If the Railway app has been down for you recently, this article covers the outage history, the root cause, and a reliable alternative for teams running production workloads.

As of May 19, 2026, Railway experienced a platform-wide outage and reported that the incident was caused by Google Cloud incorrectly suspending their production account as part of an automated action, taking their API, control plane, and databases offline for approximately 8 hours.

This was not an isolated event. Since November 2025, Railway has published postmortems for at least five major incidents, each causing disruption to developers, engineering teams, and businesses running production workloads on the platform.

You can check the current Railway app status at status.railway.com.

At 22:20 UTC on May 19, Google Cloud placed Railway's production account into a suspended status as part of an automated action, removing their cloud overflow virtual machines, CloudSQL database instance, and API. When the API went down and the routing cache expired, all workloads went down, not just those running on GCP, but workloads on Railway Metal too.

In their postmortem, Railway reported that their API was intentionally kept on GCP after the Metal migration to avoid a circular dependency, and that an automated account suspension was outside their risk model.

Railway's December 2025 changelog had stated that 100% of workloads had moved to bare-metal. The May 2026 outage revealed that while customer workloads ran on Metal hardware, the API and database managing those workloads were still hosted on GCP. Railway's February 2026 postmortem had already identified the underlying pattern: one failure cascading into a much bigger one because systems were too tightly coupled with too large a blast radius.

Railway has published postmortems for the following major incidents, all sourced directly from blog.railway.com:

• November 20, 2025: GitHub webhook surge. A surge in GitHub webhook events overwhelmed Railway's deployment task queue, stalling deployments across all tiers for approximately two hours.
• December 16, 2025: Fleet-wide resource exhaustion. Attackers exploited a Next.js vulnerability to deploy a cryptominer across customer workloads, causing fleet-wide CPU starvation and a Major Outage lasting approximately four hours. EU West (Amsterdam) was disproportionately affected.
• February 18-21, 2026: DDoS and Cloudflare BGP outage. Nine waves of DDoS attacks over four days, compounded by an upstream fiber cut and a separate Cloudflare BGP outage, causing intermittent disruption across all regions.
• March 30, 2026: Authenticated user data served to wrong users. A configuration update accidentally enabled CDN caching on domains that had it disabled, potentially serving authenticated data to the wrong users for 52 minutes.
• May 19-20, 2026: GCP account suspension. Full platform outage lasting approximately 8 hours, affecting the dashboard, API, all deployments, and all databases.

Across X, Hacker News, and Reddit, several consistent concerns emerged from the May 2026 outage and the incidents preceding it.

Developers reported worker crashes, partial outages, and build delays in the days before the full platform went down, with some noting this was their second or third major outage in a few months. Engineers questioned the gap between Railway's bare-metal positioning and the reality of a GCP-dependent control plane, noting that owning physical hardware does not eliminate cloud provider risk if the system managing that hardware runs on a single cloud account.

A specific pain point was the inability to access database backups during the outage. With the dashboard and API both offline, users had no way to retrieve their own data during the incident window.

The March 2026 caching incident, in which authenticated user data was served to other users, prompted additional concerns around GDPR compliance, with some developers noting Railway's status as a data processor and the potential reporting obligations that follow. Agency and freelance developers noted that repeated incidents put their own reputations at risk with clients, making Railway difficult to justify for anything beyond non-critical workloads.

One benefit of using Northflank is that the control plane is kept separate from the rest of the workloads, which means that even if the control plane goes down, your workloads will still be fine.

Northflank is a developer platform that abstracts the complexity of Kubernetes infrastructure, giving teams a consistent interface to deploy services, databases, CI/CD pipelines, background workers, scheduled jobs, preview environments, and GPU workloads across multiple cloud providers. It provides secrets management, autoscaling, observability, and release flows, with full support for multi-cloud, BYOC, and on-premises deployments.

The following covers how Northflank is structured differently across infrastructure, data ownership, resilience, and uptime.

Northflank's Bring Your Own Cloud (BYOC) model provisions and manages Kubernetes clusters inside your own cloud account across AWS, GCP, Azure, Oracle, CoreWeave, and Civo, with support for on-premises and bare-metal infrastructure via Bring Your Own Kubernetes (BYOK). Workloads, databases, volumes, and secrets run inside your VPC. Northflank does not access workload data or secrets.

You can connect multiple cloud providers simultaneously. If one provider restricts or suspends an account, workloads on other providers remain unaffected. This is structurally different from a shared-platform model where all customers are routed through a single provider account.

Because workloads and databases run inside your own VPC, you retain access to your data independently of the platform. A provider action against Northflank's own accounts does not affect workloads or data in your environment.

Northflank supports active-active architectures across clouds, with cross-cloud disaster recovery and automated failover. Teams can deploy identical workloads across different providers using the same templates and pipelines.

For software vendors selling to enterprises with strict data residency requirements, Northflank supports customer VPC deployments, deploying your product directly into your customers' own cloud environments.

For teams who prefer a fully managed experience, Northflank operates its own managed cloud across multiple global regions with zero infrastructure setup required. Northflank operates at 99.99% historical uptime, contractually guaranteed under enterprise SLAs with service credits if not met. Northflank is SOC 2 Type 2 compliant.

The right platform depends on your infrastructure requirements, compliance needs, and how much control you need over where your workloads run.

Northflank offers a free tier with always-on compute (no sleeping), two free services, one free database, and two free cron jobs. Compute is charged at $0.01667/vCPU/hour and $0.00833/GB RAM/hour, with BYOC available self-serve on pay-as-you-go plans. Use the Northflank pricing calculator to estimate costs for your workloads.

Railway's plans start at $5/month on Hobby and $20/month on Pro, both with minimum spend requirements. Compute is charged at $0.00000772/vCPU/sec and $0.00000386/GB/sec (the equivalent of $0.02779/vCPU/hour and $0.01390/GB RAM/hour). BYOC is locked behind an Enterprise contract requiring a sales call.

Overall, Northflank's compute rates are lower, BYOC is available self-serve on pay-as-you-go plans, and the free tier includes always-on compute.

Check status.railway.com for the current Railway app status. The status page reports live incidents across all Railway components including the dashboard, API, deployments, builds, and edge network. For incidents that may not yet be acknowledged on the official page, Railway also posts real-time updates on their X account at @Railway.

Google Cloud incorrectly placed Railway's production account into a suspended status as part of an automated action. This removed their API, control plane, and CloudSQL database. Because Railway's edge proxies depend on a GCP-hosted control plane API to populate routing tables, the outage cascaded beyond GCP to affect all workloads including those on Railway Metal, leaving the full platform unavailable for approximately 8 hours.

Railway published postmortems for at least five major incidents between November 2025 and May 2026: a GitHub webhook surge, a Next.js exploit causing fleet-wide resource exhaustion, a multi-day DDoS and Cloudflare BGP outage, a data caching security incident in which authenticated user data was served to wrong users, and the GCP account suspension.

Railway supports BYOC on its Enterprise plan, but it is locked behind a sales contract and not available on self-serve or pay-as-you-go plans. Railway does not support running workloads across multiple cloud providers simultaneously.

That depends on your requirements. Northflank supports BYOC self-serve on pay-as-you-go and enterprise plans, with deployment into your own AWS, GCP, Azure, Oracle, CoreWeave, or Civo accounts, as well as bare-metal and on-premises infrastructure via Bring Your Own Kubernetes (BYOK). For teams who prefer a fully managed experience, Northflank also operates its own managed cloud across multiple global regions at 99.99% historical uptime, contractually guaranteed under enterprise SLAs.

• 6 best Railway alternatives in 2026: Pricing, flexibility and BYOC: covers Railway's limitations and how other platforms compare on BYOC support, deployment visibility, pricing, and uptime.
• Railway vs Render: a direct comparison covering infrastructure, pricing, worker support, and production readiness.
• Top alternatives to Railway preview environments in 2026: covers platforms that support full-stack preview environments with database forking, teardown scheduling, and BYOC deployment.
• What is the best global PaaS with multi-region deployments?: covers multi-region architecture patterns and how platforms compare on region coverage and BYOC flexibility.
• Bring Your Own Cloud app hosting: covers how BYOC works, what it means to deploy into your own cloud account, and how to evaluate platforms that support it.
• Best PaaS that runs in your own cloud account: a breakdown of platforms that support deploying into your own VPC, for teams who need infrastructure control without managing Kubernetes directly.
• Best multi-cloud management platforms: covers platforms that support running workloads across multiple cloud providers simultaneously.
• Multi-cloud vs hybrid cloud: explains the architectural differences between multi-cloud and hybrid cloud and when each approach makes sense.