Railway Environments: What Is Isolated and What Is Not (2026)

Railway's documentation for isolating staging from production contains one sentence that most people building on Railway have not read: "every service with a public domain is reachable from the internet regardless of environment."

Your staging environment is not behind a wall. It is a second production, with a different URL and usually worse data hygiene.

What an environment actually contains

When you create a second environment, Railway gives you two options in the + New Environment dropdown or under Settings, Environments:

Duplicate is what nearly everyone picks, because a staging environment that structurally matches production is the entire point.

Worth knowing if you inherited an older project: Railway deprecated forked environments in January 2024 in favour of isolated environments with Sync. Environments forked before that change still exist and still behave the old way, so a project older than that may not match the current docs.

The four things that are isolated

The private network detail is the one that trips people up in a good way. The internal DNS name is identical in both environments, so postgres.railway.internal works unchanged in staging and production and resolves to that environment's instance. Your code and your reference variables stay the same; only the environment they run in changes what they point at.

The two things that are not

Railway's isolation guide is unusually direct about this. "Two things are shared across environments and need their own handling: project membership (addressed with Environment RBAC) and public networking (every service with a public domain is reachable from the internet regardless of environment)."

Public networking

Duplicate production and the copy inherits its service configuration, which includes public domains. Railway generates a new *.up.railway.app domain for the staging copy. That domain is live, indexable, and reachable by anyone who finds it.

Nothing about it says "staging" to a scanner. It runs the same code, exposes the same endpoints, and answers the same requests. If your production app has an admin route protected by an environment variable check, and staging's copy of that variable is a placeholder someone set to true while debugging, the admin route is open on a public URL.

We see this constantly in scans: the production domain is clean and a forgotten preview or staging domain on the same platform answers with a stack trace. The environment boundary protected the data. It did nothing about the front door.

Project membership

On most plans, adding someone to a Railway project adds them to all of its environments. They can read production's variables because they can read the project.

Environment RBAC changes that, and it is an Enterprise feature. Marking production restricted means "non-admin members and deployers can see the environment exists but cannot view its variables, logs, metrics, services, or configuration." Useful, but only if you're on a plan that has it. Below that, treat every project member as a production secret holder, because they are.

Sealed variables and the sync boundary

Sealed variables are the one place Railway deliberately breaks the copy. Per the isolation guide, "sealed values are excluded from environment duplication, PR environments, environment sync diffs, and external integrations," so "production secrets never leak into staging through a sync."

That is the right behaviour, and it produces a confusing symptom. Duplicate production to create staging, deploy, and the service crashes at boot because STRIPE_SECRET_KEY is not merely wrong, it is absent. The variable name does not exist, so there is no fallback and no obvious clue.

The general rule Railway's guide states is worth adopting even outside Railway: keep credentials environment-scoped. Same variable name, different value per environment, production keys only ever in production.

Rotating after the October 2026 incident: one environment at a time

On October 21, 2026, Railway disclosed that an unauthorized third party may have accessed encrypted environment variables and decrypted some of them. Its preliminary report puts the scope at "at most 1.85% of all workspaces", about 100,000, and still recommends that every customer who signed up before October 21 rotate the keys they store on Railway. One of the two risk buckets it names is "Environments with a high amount of AI keys from vendors."

The unit there is the environment, and that matters because of the isolation table above. Railway's guide says it plainly: "Every variable value is scoped to one environment." So rotation is per environment too, and the copies you forgot about don't update themselves.

Here's what that means in a project where staging was duplicated from production:

• Unsealed secrets were copied verbatim. If staging got production's OPENAI_API_KEY on the day you duplicated it, staging still holds that exact string. Revoke the old key at the provider (Railway's advice is to revoke, not just replace) and staging will start failing. Good. That failure is the tell that staging was running on a production key. Give it a test or low-limit key, not the new production one.
• Staging's database has its own password. A duplicated environment gets its own Postgres service with its own credentials, so clicking Regenerate on production's database leaves staging's password exactly as it was. Railway's PostgreSQL rotation guide applies to each database service separately.
• Public database access is the multiplier. The same guide warns that with Public Access on, the credential "is usable from anywhere on the internet through the TCP proxy until you rotate", and the preliminary report's first recommendation is to remove public network access to databases. A staging database with a TCP proxy is on the internet like any other staging service with a public domain.
• Sealed doesn't mean skipped. The disclosure doesn't say sealed variables were treated differently, so roll them too. Sealing kept them out of the staging copy; it doesn't tell you whether production's sealed value was in scope.

The practical order: switch to each environment in turn (railway environment staging), run railway variables, and work down the list. The Railway environment variables guide covers editing and redeploying each value once you've issued a new one at the provider.

Setting up staging without copying production's problems

railway environment                 # interactive picker
railway environment staging         # switch directly
railway variables                   # list what this environment resolves to
railway run npm start               # run locally against this environment's variables

railway run is the fastest way to catch a variable that only exists in production. Run it against staging and watch what fails to start.

A ten-minute audit

For the mechanics of adding and scoping variables in the first place, the Railway environment variables guide covers the dashboard and CLI paths. If you have PR environments turned on, what they copy from production covers the ephemeral case, which has a different default base and a different failure mode.