Services and environments: Railway's two-dimensional structure

Lesson 1 already introduced this: a web app, an API, a worker, a database — each a separate service within one project, independently deployable and independently configurable.

An environment (Production, Staging, or any custom name a team creates) is a complete, parallel copy of every service in the project, with its own independent configuration, variables, and — critically — its own database with its own actual data. This is a different, fuller isolation than Vercel's Preview/Production environment-variable scoping (Vercel's own domain) — Railway's environments aren't just different variable values for the same running services, they're genuinely separate, independently-running deployments of every service at once.

A change to one service's environment variable in Staging has zero effect on Production's copy of that same service — this is deliberate, and it's what lets a team test a risky database migration, a new third-party API integration, or a config change against a fully separate Staging copy (including its own separate database) before it ever touches real production data.

Beyond manually-created environments like Staging, Railway can automatically spin up a full, temporary environment for each open pull request — conceptually close to Vercel's own automatic preview deployments, but for an entire multi-service project at once, not just one frontend app. Every service in the project gets its own PR-scoped copy, torn down automatically once the PR closes.

A developer who sets an environment variable while viewing the Staging environment, then wonders why Production's service doesn't see it, has simply set the variable on the wrong axis — this is the single most common early confusion with Railway's dashboard, and understanding the services × environments grid explicitly (rather than thinking of "my project" as one flat thing) is the direct fix.