While everyone else is dressing up in costumes and pretending to be something they're not, we're helping your team members prove they are 

 who they say they are — with enterprise Single Sign-On (SSO).  If you've been waiting to bring Railway to your workplace (BTW 

) because of SSO requirements, that blocker is now gone. And if you're already using Railway at scale, you now have more control over who can do what in your workspaces.

We're also making Magic Config even smarter with intelligent defaults and Dockerfile selection, and we’re updating your projects’ build environment.

SSO is a hard requirement for larger teams and enterprises. Managing authentication through an external Identity Provider (like Okta, Azure AD, or Google Workspace) streamlines the entire employee lifecycle. When someone joins your company, they get access to everything they need in one go. When they leave, you can revoke access across all systems from a single place. 

Railway already supported team workspaces with role-based access control, multi-factor authentication with TOTP, and passkeys. But if your security team requires everyone to authenticate through your corporate IdP, you were out of luck.

With SSO, you can now connect Railway to any SAML 2.0 compatible identity provider. Bring Okta, Azure AD, Google Workspace, JumpCloud, or any other IdP of your choice. Once configured, your team members authenticate through your IdP before accessing Railway — no separate password to manage, no additional MFA setup.

. When you enable SSO enforcement, existing team members will be required to re-authenticate using your IdP. This ensures everyone in your workspace is authenticated the same way, meeting your security and compliance requirements.

SSO is available as part of Railway's enterprise offering. To request access, 

. You can also learn more details about the 

We've been shipping enterprise features for a while now — SOC 2 Type II, HIPAA compliance, SSO, RBAC — but if you weren't already knee-deep in Railway, you wouldn't know where to find any of it. 

So to sum up our collective investment for organizational adoption we built a proper 

. It's not a new feature, it's just a single place that shows what Railway offers for teams with serious security, compliance, and support requirements. All the certifications, all the enterprise capabilities, all the ways to get in touch with our team in one spot.

If you've been trying to explain to your CTO or security team why Railway can handle production workloads, or you're comparing platforms and need to see what we actually offer beyond the developer experience, this page should make that conversation a lot easier.

Magic Config keeps getting smarter. This week, we're shipping two major improvements that make service configuration even more seamless. It’s currently 

You can now select Dockerfile as your builder directly in your service settings, and if you have multiple Dockerfiles in your project (like 

), you can specify exactly which one to use.

Previously, if you wanted to use a specific Dockerfile, you'd have to structure your project in a particular way or rename files to make Railway pick the right one. Now, you have explicit control — just point to the Dockerfile you want, and Railway will use it.

Suggested variables are pre-filled when possible

Magic Config already detected which environment variables your code needs and surfaced them for you to configure. Now, we're taking it a step further: we pre-fill defaults when we can.

Previously, Magic Config would suggest the variables your code needed, but you still had to manually figure out what values to use and type them in yourself. Now, Railway not only tells you what you need — it fills in the values too.

Magic Config detects variables that need specific types of values — like database connection strings, secret keys, or API tokens — it now automatically generates appropriate default values for you. 

If your application needs a secret key, Magic Config will set a value like 

 which automatically generates a 32-character hex-based secret.

, it can pre-fill the connection string for your Railway database using reference variables.

This is another step toward Railway understanding your application's requirements and configuring everything automatically. Connect your repo, and let Magic Config handle the setup.

Try it out out and share your feedback in 

Build times matter. Every second your build takes is a second you're waiting to see your code in production, waiting to test that fix, or waiting to ship that feature. It’s the step that we do before deploying your app. 

That’s why we're rolling out a brand new 

powered by our own infrastructure, that should make your builds significantly faster. 

 have been using Metal Builders as the default for the past couple of weeks (surprise! you've been beta testing)

 are being gradually migrated to Metal Builders automatically

 can opt-in to Metal Builders right now in your service settings

, so no matter where your services are deployed, you can get the speed boost.

Service Settings → Build → Enable Metal Builders

. If you opt-in and run into any issues, you can easily roll back to the standard builders — we've made it simple to switch back while we continue refining the experience.

Previously, all builds ran on our standard virtualized build environment. It worked well, but there's a performance ceiling when you're running on virtualized infrastructure. Metal Builders run on bare-metal servers, giving you more consistent performance and faster build times without the overhead of virtualization layers.

Eventually, Metal Builders will become the default for everyone on Railway. For now, we're taking a measured approach to ensure stability and gather feedback before making them the standard.

Try them out and let us know what you think in 

We improved template configuration by exposing auto-update settings for services that deploy from Docker images. Template creators can now enable automatic image updates, which will cause services to redeploy when a new image version is published. This feature was already available in service settings for all users — we've now made it accessible for templates as well

We shipped support for browser local message drafts in Central Station. You can now draft messages without worrying about losing your work if you accidentally navigate away or close your tab.

We improved template services to support both HTTP and TCP proxies simultaneously. Previously, you had to choose one or the other, which limited flexibility for services that needed both types of connections.

We shipped support for QuickTime video attachments for 

. Previously, if you recorded a video on macOS using the built-in screen recorder, you'd have to convert it to MP4 before uploading it to Railway. Now, you can upload 

We fixed a bug where deleted templates would stick around in the frontend. Previously, users were confused when they tried to deploy templates that no longer existed. Templates now properly disappear once they're deleted.

We fixed a bug where environment sync would fail when trying to sync over the disabled serverless setting. Previously, this setting wouldn't carry over during environment syncs, causing deployments to behave unexpectedly.

We fixed a bug where opening service settings for a deploying service from a template would crash the frontend. This was particularly frustrating when trying to configure a service mid-deployment — now the UI stays stable throughout the process.

https://res.cloudinary.com/railway/image/upload/v1761790805/2025-10-31_wc1mj7.png

Enterprise SSO, More Magic Config, Metal Builders

Changelog #0262