Greetings Passengers, welcome to the two-hundred-and-forty-first Railway Changelog!

We’re happy to have you aboard — we think you’ll enjoy this week’s drop as you’ll be getting higher deploy concurrency for free depending on your service architecture. 

Before we get into that — and some other nice things — we wanted to let you know that there are some really attractive open 

If you missed the last couple of changelogs, 

 is a new way for you to earn Railway credits by answering community questions.

To get started, all you need to do is visit 

, log in, configure your payout workspace, and get to solving or creating.

With that said, it’s time to get this show on the road. 

We’ve unlocked higher deploy concurrency in certain scenarios by splitting out our build and deploy queue

Let’s talk a little bit about what goes on under the hood when a container deploys on Railway. 

Previously, there was a single “build and deploy” queue managing, well, builds and deploys. 

The issue with this is that when you have some concurrency in your Railway project, like if you’re deploying several services at once, you would sometimes be waiting for Service A to finish 

That was annoying because “building” and “deploying” are in reality two separate actions.

So this week we split the single queue in two — here are the benefits:

Unblocks subsequent concurrent container builds if a deployment has finished building and started deploying

Prevents deploys that don't include a container build step from being queued by deploys that do have one

As a result, you get higher service deployment concurrency for free in some cases (depending on your service architecture) — and most immediately you’ll notice some nice new details in the interface (see image above) letting you know 

Railpack will soon become the default builder on Railway

, and we wanted to let you know that we’re getting closer to making 

 versions of packages (instead of Nix’s approximate versions)

: We’ve been able to reduce image sizes between 38% (Node) and 77% (Python), enabling faster deploys on Railway

 to control the layers and filesystem, resulting in more cache hits (with sharable caches across environments)

( If you want to read more about how Railpack works, check out 

 by Railway Product Engineer Jake “JR” Runzer. )

So as we begin to plan for a Railpack-first world, we wanted to take the opportunity to receive ALL your comments and feedback, no matter how small. 

We really, really want to know what you think — so you might see (or have seen) a couple emails asking about your experience with Railpack as well.

If you have something to tell us about Railpack, please add your feedback to the 

We made it more clear when the free trial period is ending for new Railway users

We first mentioned that we’d be limiting Trial periods to 30 days in 

If you missed those, the tl;dr is that new Railway users are now limited to 30 days before they need to upgrade and that doing this is the precursor to us unveiling a shiny new free plan.

This week, by popular demand, we’ve added some indicators in the UI to make it easier to understand when exactly your trial plan is ending. (Again this is only relevant if you’re a brand new user.)

That’s it for this week! Hope you have a wonderful weekend. 🎇

We introduced some new advanced DDoS protections 

(Nope, sorry, we won’t expand on this, but we promise that yes we do trust you in a general sense…)

We made some performance improvements to the canvas multiplayer capabilities

We made a small improvement to template performance when using 

We now remove deployments that crashed more than 1 day ago for users experimenting on the Free Trial

https://res.cloudinary.com/railway/image/upload/v1749262810/2025-06-06_poht20.png

Higher Deploy Concurrency, Railpack RFC, Clearer Trial Duration

Changelog #0241