--- title: "Higher Deploy Concurrency, Railpack RFC, Clearer Trial Duration" date: 2025-06-06 number: 0241 url: https://railway.com/changelog/2025-06-05-deploy-concurrency --- # Higher Deploy Concurrency, Railpack RFC, Clearer Trial Duration 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 [Bounties](https://station.railway.com/bounties) in Central Station. If you missed the last couple of changelogs, [Bounties](https://railway.com/changelog/2025-05-23-bounty-hunt#bounty-hunters-rejoice-) is a new way for you to earn Railway credits by answering community questions. To get started, all you need to do is visit [Central Station](https://station.railway.com/bounties), 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. Let’s jump into it! ## Higher Deploy Concurrency [Image: 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 *deploying* over here before Service B could start *building* over there. 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 *why* a specific service is queued. Ok, onward! ## Railpack RFC [Image: Railpack will soon become the default builder on Railway] It’s been several months since we [launched Railpack into beta](https://blog.railway.com/p/introducing-railpack) during [Launch Week 02](https://railway.com/launch-week-02/day-2), and we wanted to let you know that we’re getting closer to making [Railpack](https://railpack.com/) the default builder on Railway. As a reminder, we’re shifting from [Nixpacks](https://nixpacks.com/docs/getting-started) to [Railpack](https://railpack.com/) as the default for these reasons: - **Granular Versioning**: Support for `major.minor.patch` versions of packages (instead of Nix’s approximate versions) - **Smaller Builds**: We’ve been able to reduce image sizes between 38% (Node) and 77% (Python), enabling faster deploys on Railway - **Better caching**: Railpack interfaces directly with [BuildKit](https://github.com/moby/buildkit) 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 *[*Why We’re Moving on From Nix*](https://blog.railway.com/p/introducing-railpack#introducing-railpack)* 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 [Central Station](https://station.railway.com/feedback/feedback-railpack-409fc7d5) thread [here](https://station.railway.com/feedback/feedback-railpack-409fc7d5). We really appreciate it. 🙏 ## Clearer Trial Duration [Image: 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 [Changelog #0234](https://railway.com/changelog/2025-04-18-dashboard-fixes-larger-volume-migration-support#time-limit-on-trial). Then we brought it up again in [Changelog #0235](https://railway.com/changelog/2025-04-25-railpack-elixir-support#time-limit-on-trial-reminder) and [Changelog #0239](https://railway.com/changelog/2025-05-23-bounty-hunt#trial-project-extinction-event). 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. 🎇 ## Fixes and Improvements - 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 [railway.com/new](http://railway.com/new) - We now remove deployments that crashed more than 1 day ago for users experimenting on the Free Trial