At Railway, we've been polishing up our entry points to the product to make it so that your first day on the platform sets a high bar for the experience of your applications. However, if you are part of an organization's security team, you see the word "entry" and immediately you are on high alert. Ask any CISO, and the questions start darting out in their brain: "Who can enter?" and "What can they do?"

As an organization with standards that we need to enforce ourselves, we're empathetic to the concerns of the modern security leader. It wasn't enough that we had to expose applications on the cloud — now everyone needs to deploy their code on the cloud as well since everyone is a developer now thanks to AI.

Luckily, Railway has developed good answers throughout the last few years working with Fortune 500s and exposing the platform, in a controlled fashion, to their colleagues.

As such, we're rounding up the last six months of effort featuring enhancements we shipped to help organizations have better control over who can access which resources within a Railway workspace, and new capabilities to enforce and restrict permissions within an org.

Our hope is that an enterprising developer or engineering leader can send this article over to a discerning platform lead and diffuse a conversation. (Or at least start a relationship with our Solutions team — here's a link if you want a demo.)

Let's walk through it the way your security team would evaluate us: starting with who's allowed in, then what they're allowed to do, what you can see, what's running underneath, and finally — how to prove all of this to an auditor.

First: lock the front door

The first question any security review asks is about authentication. How do people get in, and how confident are you that they are who they say they are?

Railway now gives you two layers here that work together.

Workspace-wide 2FA enforcement lets Pro workspace admins require two-factor authentication for every member. Once enabled, anyone in your workspace must have 2FA turned on before they can access workspace resources. Members without 2FA can still be invited and join via Trusted Domains, but they'll hit a wall until they enable it. API tokens remain unaffected and continue to work as expected. No more hoping your teammates remembered to turn it on — the platform enforces it for you. (Docs)

But for larger organizations, 2FA enforcement is table stakes. The real question is whether you can route authentication through your corporate identity provider so that access to Railway is governed by the same policies as everything else in your stack.

Enterprise SSO answers that. You can connect Railway to any SAML 2.0 compatible identity provider — Okta, Azure AD, Google Workspace, JumpCloud, whatever your org uses. Once configured, your team members authenticate through your IdP before touching Railway. No separate password, no additional MFA setup, and when someone leaves the company, you revoke access from one place and it cascades everywhere.

You can also enforce SSO across the entire workspace, which means existing members will be required to re-authenticate through your IdP. This isn't optional-if-you-feel-like-it SSO — it's the kind of enforcement that satisfies a compliance checklist.

Railway already supported TOTP-based MFA and passkeys before this. SSO was the missing piece that was blocking teams whose security orgs wouldn't approve a platform without IdP integration. That blocker is gone. (Contact sales for access · Docs)

Then: scope what people can actually do

Authentication answers "who can get in." The next question is always "what can they do once they're inside?"

Not everyone on your team needs full admin access, and Railway gives you granular control to match permissions with responsibilities. There are currently three distinct roles for workspace members, each designed for specific use cases with carefully scoped permissions.

Admins get full administration of the workspace and all projects — service settings, project deletion, billing, member management, role changes. This is for team leads, engineering managers, and anyone who needs complete control.

Members can access all workspace projects and do everything needed to build and deploy applications: create and configure services, manage variables, create volumes, spin up new projects. But they can't delete services, volumes, or projects, and they can't touch workspace membership or billing. This is the role for most developers on your team — enough power to ship, not enough to accidentally blow something up.

Deployers are the most restricted. They can view projects and trigger deployments through commits via the GitHub integration, but they can't use the CLI, can't modify variables or service settings, and can't view logs. This role exists for CI/CD pipelines, automated systems, or team members who need to push code to production but shouldn't have access to production data or configuration.

We're actively working on even more granular controls beyond these three roles. Let us know what you'd want to see in this Central Station thread.

Use “Login with Railway” over Tokens

Locking down human access is one thing. But modern teams run on integrations — CLIs, dashboards, deployment frameworks, monitoring tools — and each one of those is another surface area your security team has to think about. The question shifts from "what can this person do" to "what can this application do on their behalf?"

Login with Railway is our answer to this. Built on OAuth 2.0 and OpenID Connect, it gives third-party applications a secure, standardized way to authenticate users with their Railway account without anyone sharing a password or minting a long-lived token with broad access.

When a user authenticates through a third-party app, they see a consent screen showing exactly what permissions the app is requesting. They can approve or deny, and for workspace or project scopes, they choose specifically which resources to share. The app only gets what the user approved — and only within the boundaries of that user's existing role. A Deployer who authenticates through a third-party CLI still can't modify variables, because the OAuth token inherits the same RBAC constraints as the user who granted it.

Now: see everything that happens

You've locked down who can get in and scoped what they can do. The next thing your security team will ask is: "Can you show me what happened?"

This is where audit logs come in. Previously, if something changed in your workspace and you needed to trace it back — who modified that environment variable, who added that member, who triggered that deployment — you were out of luck. Now you have a full paper trail.

Audit logs capture every significant event in your workspace: which events happened (deployments, configuration changes, member additions), which project and environment were affected, which user made the change, and when. You can filter by event type, environment, project, and custom time ranges to find exactly what you're looking for. And for teams that need to pipe this data into a SIEM or build their own dashboards, audit log data is exportable via the Railway API.

This matters because audit logs aren't just a nice-to-have checkbox — they're the connective tissue that makes all the other security features trustworthy. 2FA enforcement is great, but your security team needs to verify it's actually enabled and that no one downgraded their auth. RBAC is great, but you need a record of who changed someone's role and when. SSO enforcement is great, but you need to see that everyone actually re-authenticated through the IdP.

Audit logs are the evidence layer that sits beneath all of it. Check out the documentation for the full list of supported events, and let us know on this Central Station thread if there are events you'd like us to add.

Under the hood: keep your images patched

So far we've covered people — who gets in, what they do, and how you track it. But there's another axis of security that platform engineers lose sleep over: what's actually running underneath your services.

If you've been in this world long enough, you know the quiet anxiety. That database template you deployed six months ago — is it patched? Is it running a version with a known CVE? You'd check, but there are fifteen other fires to put out today. Multiply that across every image-based service in your workspace and you've got a supply chain problem hiding in plain sight.

Railway now handles this for you. When you deploy a service using a Docker image, Railway can automatically check for new versions and update your service during configurable maintenance windows. Your databases, caches, and other image-based services stay current without someone needing to manually check Docker Hub.

You have full control over the update cadence. Apply updates only on weekends if you want to limit change windows to low-traffic periods. Apply them any day at night if you're comfortable with off-hours updates. Or apply them any time if you want patches as soon as they're available. Before any update lands, Railway automatically creates a backup of all attached volumes — so your data is safe if you need to roll back. And if a specific version causes issues, you can skip it to prevent Railway from updating to that release.

For security teams, this means your organization's infrastructure isn't silently falling behind on critical patches. Railway is watching the registries so your platform engineers don't have to. (Docs)

Finally: prove it to the auditor

At some point in the buying process, the security questionnaire lands in your inbox. 200 questions about encryption standards, data residency, incident response plans, and subprocessor lists. We've been on both sides of this — and we built the Trust Center at trust.railway.com so that the evaluation process doesn't have to be painful.

It's a single destination where your security team can review Railway's security posture and request access to compliance documentation. The full SOC 2 Type II report is available on request — not the summary SOC 3, but the real audit with the auditor's detailed testing results. Penetration test reports are there for teams that need evidence of regular external testing. Our Data Processing Agreement is available for GDPR compliance, and the full subprocessor list gives you transparency into every third-party service that touches your data.

For teams running HIPAA workloads, Business Associate Agreements are available as an add-on to the enterprise plan. When a BAA is in effect, Railway team members can no longer directly access your running workloads. And for European organizations that need to comply with EU DORA, we can provide additional documentation covering disaster recovery procedures, uptime statistics, and IT controls after a click-through NDA.

The Trust Center is powered by SafeBase, so your security team is likely already familiar with the interface from evaluating other vendors. No chasing down PDFs over email, no waiting a week for someone on our side to dig up a certification. Sign in with your Railway account email and it's all there.

The conversation should be easier now

At the start of Railway’s journey, the security conversation around Railway was harder. The features existed in pieces, the compliance story was thinner, and a developer trying to champion the platform internally had fewer artifacts to point to.

That's changed. Between workspace-wide 2FA enforcement, enterprise SSO with IdP integration, role-based access control, comprehensive audit logs, automatic image patching, and a Trust Center backed by SOC 2 Type II — the answer to "who can enter?" and "what can they do?" is now well-documented and enforceable.

If you're the developer who's been eyeing Railway but needed the security story to bring to your platform team — send them this post. If you're the security lead who just received this link — welcome, and we hope we've answered your first round of questions.

For everything else, our Solutions team is here.