--- title: "Builder V2 Beta, Static IPs Alpha to All Regions, How We Work (Volume III)" date: 2024-05-24 number: 0187 url: https://railway.com/changelog/2024-05-24-builder-v2-beta --- # Builder V2 Beta, Static IPs Alpha to All Regions, How We Work (Volume III) 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 `us-east4`, `europe-west4`, and `asia-southeast1`). 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. Sound like you’re on the right train? We’re now in service. Let’s go! ## Builder V2 Arrives in Beta [Video: Enable Builder V2 beta by adding a service-level variable] One of the oldest services in our stack is the [Builder](https://docs.railway.app/guides/builds). This service is responsible for building and publishing an [OCI](https://opencontainers.org/)-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 [status page](https://status.railway.app/) :(. With Builder V2, we’ve built builders directly into our orchestration engine! This has some other added benefits: - You can use the private network at build time to run migrations - You can get metrics for builds 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: ```nix RAILWAY_BETA_ENABLE_BUILD_V2=1 ``` Be advised that like any beta feature, Builder V2 currently has some limitations: - Watch patterns are not yet available - The builder is only available in the `us-west1` region If you try it out, please let us know what you think by dropping us some [feedback](https://help.railway.app/feedback). ## Static IPs Alpha to All Regions [Video: Static IPs are now available to Pro users in all regions. Enable via the service settings menu.] [Last week](https://railway.app/changelog/2024-05-17-new-edge-proxy-beta#introducing-static-ips-(alpha)) we announced the availability of Static IPs to Pro plan users in `us-west1`. 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 `Enable Static IPs` toggle in the `Networking` section. Let us know how this works for you by leaving feedback [here](https://help.railway.app/feedback/static-dedicated-i-ps-de0b680b). Onward! ## How We Work (Volume III) [Image: How We Work (Volume III) is the latest look at how we operate at Railway] Back in 2021, Railway Founder [Jake Cooper](https://x.com/justjake) wrote a blogpost called [How We Work](https://blog.railway.app/p/how-we-work) 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.” Last year we published a follow-up with [How We Work (Volume II)](https://blog.railway.app/p/how-we-work-volume-ii) 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 — [How We Work (Volume III)](https://blog.railway.app/p/how-we-work-volume-iii). 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. It’s a good read. And if you find yourself thinking that how we work is how you’d like to work — well, we’d like to meet you. Check out our [Careers](https://railway.app/careers) page where we’re hiring for a number of roles. See ya next week! ✌️ ## Fixes and Improvements - We upgraded Nixpacks to [v1.24.0](https://github.com/railwayapp/nixpacks/releases/tag/v1.24.0) — now with default support for Python 3.11! - We fixed a number of small visual bugs for new users on the Trial plan