Hey there, welcome to the Railway Changelog. 

Please make yourself comfortable as our train is about to depart on its special Friday service. 

This is a big week for your builds — we’re going to tell you all about the all-new Builder (available today in beta) and the enormous benefits that are coming shortly down the line.

We’re also widening the release from last week of Static IPs (hello 

Finally, we’ll be pulling back the curtain on how we operate at Railway with the third installment of How We Work — it’s a good one.

Enable Builder V2 beta by adding a service-level variable

One of the oldest services in our stack is the 

. This service is responsible for building and publishing an 

-compliant image that Railway can then deploy to a target.

The biggest issue with the Builder today is that it’s aged into a second-class citizen in our stack. We’ve designed an algorithm to steer compute around our nodes, but the builders have until now existed outside our node mesh, on a completely different orchestration engine.

Due to their stateless nature, we’ve automatically scaled up and down the compute as required. While this works the vast, vast majority of times, once in a blue moon, a torrent of builds come through and well, Google’s Autoscaling Groups just can’t keep up. It results in “stuck builds” which means builds sometimes get delayed. You might’ve seen this before on our 

With Builder V2, we’ve built builders directly into our orchestration engine! 

You can use the private network at build time to run migrations

In the future this opens us up to do even more cool stuff:

Intelligent routing based on caching layers (aka all PHP deploys can re-use static layers), resulting in even quicker build times

Builds can happen on the same machine the code actually runs on meaning “Zero Second” publishing is possible (since we don’t have to push to a remote registry)

All in all, this means faster, more reliable builds for you. 😎

We’d love you to try the Builder V2 beta. 

To get started, set the following service-level variable:

Be advised that like any beta feature, Builder V2 currently has some limitations:

If you try it out, please let us know what you think by dropping us some 

Static IPs are now available to Pro users in all regions. Enable via the service settings menu.

 we announced the availability of Static IPs to Pro plan users in 

This week we’ve rolled-out Static IPs to all regions.

To enable Static IPs, you’ll need to visit your service-level settings and look for the 

Let us know how this works for you by leaving feedback 

How We Work (Volume III) is the latest look at how we operate at Railway

 to talk about how we manage async work, how we’ve deleted nearly every meeting from our calendar, and how we’ve tuned the mechanics of our org to value “real work” over “meta work.” 

 covering some of the fundamental principles that make us different from a lot of other companies — leverage, autonomy, craft, and alignment.

That brings us to a new blogpost, hot off the press today — 

In the previous two posts, we've told you a lot about why you might want to work at Railway. In this blogpost, we're gonna tell you about why you might not. 

And if you find yourself thinking that how we work is how you’d like to work — well, we’d like to meet you. 

 page where we’re hiring for a number of roles. 

 — now with default support for Python 3.11!

We fixed a number of small visual bugs for new users on the Trial plan

https://res.cloudinary.com/railway/image/upload/v1716596069/2024-0524_sugzfn.png

Builder V2 Beta, Static IPs Alpha to All Regions, How We Work (Volume III)

Changelog #0187