Where Railway is, and where it's going (Summer 2026)

There's a lot of words ahead, but here's the gist of it:

This year of Railway in this current shape brought real product wins, a million+ more users, but reliability stumbles that cost us customer trust.

We're embarking on a focused push built around earning that trust back and polishing the platform we've been describing. A lot of the work is already in, and there’s a lot more to come.

For the remainder of this quarter and next, we’re going to be focused on two key areas. Trust and the core product loop.

On the first part:

• We’re going to be rolling out our second-generation of Metal, our second-generation hardware platform, incorporating two years of learnings of running our own sites
• Bringing 4 new sites of datacenter capacity online
• Improving the backup experience
• Extending our Postgres offering to be more batteries included
• Hardening the edge against DDoS with our own native CDN and network infra
• We’re angling to work on ISO27001 for customers with even more sensitive compliance concerns

We're also going to build out more of the core product:

• Making the agentic Railway story elegant (sandbox primitive, remote MCP server, agents that can create templates) - watch this space
• Improving our frontends story with a real CDN
• Railway self-healing deploys
• A Templates renaissance with better discovery and supporting creators
• Improving the API experience via an SDK
• A more elegant IaC story
• Safer rollouts via feature flagging
• The mobile app hitting GA (We didn’t forget about you Android phone havers)
• Revamping the O11y experience
• Extending AI Guardrails to prevent greater destructive actions

Other highlights, which the Support and Solutions team have been hard at work on:

• A support agent in the Railway dashboard enters beta in Q2. We've also been revamping the response AI.
• Bridging all product feedback directly to the engineer who works on the feature. We call this Priority Boarding 2.
• We are also re-working our demo flow to make the buying experience that much, much, much better for companies. You can go from call to contract in 30 minutes.
• You will see a major investment in AEO for model discoverability (You’re welcome/sorry)
• Q2 2026 is the reliability foundation, Q3 2026 is the product loop maturing on top of it, Q4 2026 and into 2027 is when the production agent-native cloud becomes the default.
• We’re going to be looking into improving our pricing and packaging around the agent flow.

If this summary has your interest piqued, read on below for more info on these topics.

First off, a re-introduction, I’m Angelo, a Solutions Engineer at Railway. Before Railway I worked at Citrix, helping run mission-critical cloud environments for places like Verizon and Lockheed. That's a polite way of saying I spent years inside other people's infrastructure decisions, on calls where my job was to be honest about what the platform did well and what it didn't. A lot of the early docs, customer chats, and support were driven by me. Five years later, we have a wonderful team and more faces who you’ve likely talked to. (And you’ll be seeing more of them.)

Coming up on my fifth(!) year at Railway, I've taken hundreds of calls with teams using us in production, been on thousands of threads, and been party to a lot of product decisions internally. We’ve been sorta consistent about sharing our roadmap, but Railway now, the product is bigger than ever and we’d like to do a better job of cluing you in how we are thinking about the future of the product as we grow to serve the next 100 million developers.

Despite AI, developers are needed now more than ever.

We get excited about what's working: the speed from git push to a live URL and the way the platform handles the parts of a deploy nobody wants to think about. While many people debate the future of development, we’ve been dogfooding a whole new experience internally we can’t wait to show you.

And then there's the other part.

The part where someone tells me, sometimes carefully and sometimes not, that they saw the outage and they're not sure they trust us yet or where someone says they love the platform but they need something Railway doesn't have or solve well yet.

This is that post that speak to the above. It's longer than I wanted it to be.

The rest of the work that we have planned is big, and I'd rather walk you through them than send you a marketing email that says "exciting changes are coming." If you want the short version, scroll back up to the TL;DR. If you want the full picture, walk with me.

When we started Railway, the bet was simple: developers should push code and have it run.

That contract has roots all the way back to Heroku in 2007. Everything we've added is an extension of it.

I am convinced that Railway is the only platform building agent-centric developer ergonomics to meet the needs of real businesses. It seems clear that the models have taken a liking to this as well.

I tend to hammer home that lost decade between roughly 2014 and 2020 took developers away from git push and into Helm charts, IAM bindings, and managed services scattered across three cloud accounts.

We wanted to bring you back, extending the contract for what the work has become: full-stack apps with real databases, multi-region by default, and increasingly, agents in the loop.

The core bets that came out of that:

• The fastest loop wins. Postgres, MySQL, Redis, Mongo, all in the same project, on the same private network, on the same bill. Minimize context switching at all costs.
• Push code, get a URL. Git is the deploy contract. CI/CD is the platform's job, not yours.
• You pay for what you use. Usage-based pricing where the meter stops when traffic stops.
• Multi-region is table stakes. Gone are the days where picking us-east-1 was a death sentence. Pick a region per service; the platform handles routing.
• The agent is a first-class consumer. The MCP server is not a bolted-on integration. The Stripe APP is not marketing, and the agents need better primitives.
• Reliability is a posture, not a feature. We're going to talk about this one a lot in this post.

The sheer number of projects that flowed through Railway (50M+ builds a month, 12,000+ new users a day, while powering production traffic at hundreds of billions of requests) has been motivating in a way that's hard to describe.

The love we've seen for what we've built means a lot. It's nice when customers reach out not because they need something but because they want to tell us what we're doing right. For all this and more, we are thankful. You're the reason we do this.

In the above image, you can see the growth in deployments on the platform. People are shipping at a tremendous pace. (You can see this live over at https://www.railway.com/stats btw)

Throughout the last three months, we've also been building muscle to deliver a more responsive platform that matches the pace at which you actually work. These features will also be getting their own lil launch cadence after.

• After the GCP outage, we completed the cutover to our fully distributed network router, meaning if a single cloud goes down, we can route traffic over backup links between Metal/AWS/GCP.
• We shipped a new builder that is cloud-agnostic, which made our own internal builds dramatically faster as a side effect.
• We shipped real SSH in the CLI and the database UIs, retiring the old SSH proxy and unlocking a class of agent-driven debugging that wasn't possible before.
• We shipped one-click HA Postgres on Patroni in March 2026. In-region replicas, automatic failover, the "managed database that fails over without a ticket" box finally checked.
• We shipped a Stripe APP on their APP protocol for agentic provisioning. An AI agent can now sign you up, pay, and stand up a running Railway stack in one continuous loop.
• We shipped a meaningfully better Template search. There's more to do here (more in a moment).

With each release, we've been improving and battle-hardening the live platform, upgrading where we've seen opportunities. The last year hasn't been without hiccups and challenges though, so let's discuss those.

Where do we start?

We could dismiss the challenges that we faced as “well, the internet is burning” while these developers get online but that isn’t exactly in our company (and personal) values.

There are hundreds of moving parts to a service that thousands of companies trust with their production workloads. On top of that, there are areas where the product needs to match your expectations. Here are three themes we've observed about the platform and the community.

Picture the worst version of a Sunday afternoon.

You push to main on a small fix, your healthcheck doesn't come back and you see the banner you didn't want to see. Each incident has a postmortem on our public status page. Read them. They are honest. But clearly, they are also incidents we should not have had.

Here's how we think about it now.

When a deploy fails because of something upstream of us, you cannot tell the difference between "Vendor is having a bad day" and "Railway is having a bad day." From your seat, it's all Railway. We're the platform you trust to make your app run. If the layer underneath us breaks, that's our problem to absorb, not yours to debug. The accountability is ours even when the root cause isn't, and we've been operating that way harder over the last six months than at any point in the last few years.

Recently, we have been running firedrills on every single point of failure we could identify, from the registry layer to the networking control plane to the third-party integrations we depend on. We have more tabletops to come. As such, we're treating every dependency as if it’s one bad day away from being our problem, and we'd rather know what that looks like before it happens than during.

The comms side has been a parallel investment.

If you've been paying attention, you might have noticed status page updates that land faster (with a whole new status page from the team), postmortems that land sooner, customer-impact summaries that name what happened in plain language. Some of you noticed.

A few of you have told me on threads that our comms have gotten noticeably better. That's the feedback we've been hoping for, and it's the feedback that tells us the investment is doing what it should.

Trust is a leading indicator and a trailing indicator at the same time. We have it to earn back.

If you came to Railway from Heroku, you came for the backend. We're great at that. Push a Rails app, push a Node API, push a Python worker, the platform catches it. Try to push a marketing site that needs to load fast for users in Seoul and Madrid and São Paulo, and the answer has been a polite "have you considered hosting the frontend on Vercel and the backend on us?"

That's a fine pairing pattern.

It's also a tax on customers who'd rather have one platform and one bill.

You can see this in the Station threads. Customers in Asia and South America seeing 5-second TTFBs on a backend that is genuinely fast once the request arrives. Customers fixing performance by switching DNS records from CNAME to A records because the edge layer is still routed through a third party and not co-located with Metal.

These are the same gap, refracted through different teams, and they are workarounds that nobody should have to do.

We’re making a real CDN. It’s in testing now.

The good news is that the end-to-end edge testing suite is already live, and we're validating CDN behavior, WebSockets, SSE, and headers against both staging and production. Railway Websites is soon to arrive and we’re working on plugging that gap.

…and we’re tracking that expansion in our very own Railyard.

Open Claude Code in your terminal.

Ask it to spin up a new Railway service. Most of the time, it works. Ask it to set up a Postgres next to that service and run a migration. Most of the time, that works too. Ask it to open a preview environment with seeded data, run an integration suite against the change, and only ping you if the suite goes green.

We're not there yet.

We've shipped the MCP server. We've shipped the Stripe APP protocol. We've talked about agentic Railway for over a year. The path from where we are today to "the agent can do everything end to end" is real, and it's unfinished. We don't yet have a foundational sandbox primitive, which is what agents need to validate their own work safely. The remote MCP server isn't where it needs to be. The vision is clear. The execution is in progress, and we owe you transparency about that.

You can see the unfinished edges in the threads too.

Coding agents rate-limiting themselves into a block by making too many CLI calls in too short a window (fixed, btw). Another example, customers confused by what "Agent Usage" on their invoice means, because we have not drawn a clean enough boundary between Railway's own AI features (Diagnose with AI, the dashboard support agent) and the agents customers are running themselves.

As we've been learning these lessons, we've also been running experiments and noticing early signals about what helps:

• Builds are no longer slow, and the patterns from that work are starting to show up in customer-facing build times.
• The Stripe APP integration has gotten more customers from "agent-curious" to "agent-running-real-stacks" faster than we expected.
• Customers who set spend alerts on day one almost never have the "your $5 app cost $40" experience. The ones who don't, sometimes do. A recent thread had a Datadog agent left quietly running on a project, turning a $40 to $60 monthly invoice into $544 before the customer noticed. We're going to make alerts more prominent.

We've been absorbing so much over this year thanks to feedback, customer calls, and platform data from all of you. It makes our heads spin sometimes. We're dizzy as you can tell.

When we set out to build Railway as it exists today, the aspiration was simple: developers should push code and have it run. Now, we want to include how most people are writing code, and that is via the agents. We want to give people speed, and the verification they need so they can use Railway wherever they need to use us.

Our plan for the next year is to commit harder to that mission, by going deeper on what we already do and filling in the gaps we've been honest about above.

To that end we have two main paths we're walking down starting now and landing in Q3 2026:

This is the foundation work. It won't all be visible as flashy launches. (But there is a lot here.)

The biggest piece is the Gen2 Metal rollout.

We're moving onto our second-generation hardware platform, including the networking work to support it and the unblocking of the region setup that has been gating it. This is the largest infrastructure investment of the year, and it determines our reliability posture for everything that follows. We’ve spec’ed everything up, better CPU, memory, storage architecture. We can’t wait to talk more about this.

We're also bringing new datacenter capacity online, which is where a lot of our infrastructure investment is going.

There's also internal work that matters even if you never see it directly. Like improving our SOP and restructured how we handled pages, escalation, and the feedback loop from incident to action.

Beyond Q2, the track continues. We're going to be expanding our footprint and our compliance surface as our customers grow into us. Just to flag, these directions are still taking shape and the specifics will sharpen as we get further in:

• Even More datacenter capacity across more regions, building out where we don't have a presence on the map yet.
• A serious push toward ISO27001, for teams whose customers ask for that level of compliance posture.
• Continued Gen2 Metal rollout across the rest of the fleet once the first wave proves out in production.

We’re also going to be taking a look at cleaner deploy logs when something fails. A more readable view of what the platform is doing on your behalf when a deploy is in flight. Which leads us to…

This is the work that makes Railway better at being Railway.

The piece I'm most excited about is the agentic Railway story.

Three connected things:

• A foundational sandbox primitive so an agent has a safe place to validate its own work before promoting to production
• Having the agents be more native within the dashboard or the terminal experience (such as handing over Railway to your existing AI coding tools like Claude, Codex, or Cursor).
• The remote MCP server so the agent doesn't have to be local to drive the platform (live today) and the ability for agents to create templates the same way humans do. (also live today)

We're also shipping the answer to "Railway isn't a great place to host frontends." A real CDN is part of it. Railway Websites is part of it. The end state is that you can ship a Next.js or a TanStack app on Railway and not have to split where you host your code.

The goal here is that you can hand your preferred harness a computer or an MCP, and you can imprint your will on the world via the code you need deployed. That’s the vision we have.

And we're sweating the details that have been asks for a long time: scoped API tokens, a more elegant IaC story, a flagging primitive so you can roll out a change to a percentage of your traffic without bolting on a third vendor.

Beyond Q2, we’re working on a product experience where you can request and build changes directly within the product and flight it out. It’s ambitious but we’re angling to get there.

As we speak, Jared, Lucas, have been making so you can fork a running machine, edit it live, and merge it back into place. But we’re not only looking at big swings, we are holistically looking at a whole other number of quality of life changes.

Other things we're looking at:

• Pricing and packaging around the agent flow that reflects how teams actually use Railway when agents are doing the work, not the shape of pricing pages from 2018.
• A revamped observability experience so that the agent (and you) can ask the platform why something is slow and get a useful answer.
• Extending our AI guardrails so the platform refuses destructive operations the agent shouldn't be making in the first place.
• Templates that aren't just static recipes but production-grade primitives an agent can compose into a real stack.

If this was one of those launch videos, I'd pause the music, click into the Railway dashboard one more time, wink at the camera, and stare out the window for a minute before continuing.

Today we're closing out a year in this shape of Railway, but our eyes are on the road from here through the rest of 2026 and into 2027, and our hands are working to lay those tracks (get it?) as we speak. The journey ahead is one that will see the platform get more reliable, more capable, and more agent-driven, all in service of the same simple bet we made at the start: developers should push code and have it run.

To look more directly at where we're heading from here:

Q2 2026 is about getting the foundation right before anything new gets built on top of it. The fleet, the regions, the backups, the edge, the on-call cadence. The boring, unglamorous infrastructure work that the rest of the year depends on. We are not shipping a banner-worthy thing this quarter. We are shipping the conditions under which the rest of 2026 gets to be ambitious.

Q3 2026 is when the product loop visibly catches up to the story we've been telling. The frontend gap closes. The Templates renaissance lets community creators ship more like first-party teams.

2027 and beyond is where we get to say yes to projects today's roadmap can't fit. There are a few ideas we've been turning over privately (no spoilers) that aren't ready for a public post yet.

We'll write more posts like this one as the year unfolds, including ones that are less about earning trust back and more about the parts that let you ship the work you need to ship, while having it feel tight, refined, and most of all, fun.

For those of you who have been with us from the start, or 2025, or just signed up, thank you. Your feedback, your patience during the rough patches, your willingness to tell us when we screwed up, and (just as importantly) your willingness to tell us when we got something right, are the reasons we push to ship harder, ship honestly, and have fun doing it.

We're going to keep building Railway around you and the community and businesses you've created, and we're committed to earning back the trust we owe you as we do.

For those of you on the fence about whether Railway is the right platform for you, thank you as well. We'd rather you read this post and come back when you're ready than feel sold a story that didn't pan out. Check back in with us as we ship the next two quarters. If you get the itch, we'll be more than happy to have you.

Alright. This is where I hit stop. I've written a lot of words.

Happy Shipping,

Angelo + The Railway Team