Multiple projects vs multiple environments

Anonymous
PRO

a month ago

Project id: 0a0167c4-ee3b-429a-850c-016d9d25246f

I’m deploying a web app and I want to set up two environments: staging and production. My goal is to use staging to test changes from PRs before promoting them to production. I’m using GitLab pipelines, so the idea is:
• On PR creation → deploy to staging
• On PR approval/merge → deploy to production

I’m working with a monorepo (frontend + backend), so I’m manually creating empty services to start with, as advised in the documentation.

The issue: I noticed I can’t create services with the same name in different environments, which makes me wonder what environments are meant for. I see I can sync between environments, but that’s not what I want. I need two isolated deployments that can have the same service names but different code versions.

So my questions are:
1. Is this expected behaviour?
2. Should I be creating two separate projects instead of relying on environments?
3. What’s the intended workflow for staging/production pipelines like mine?

Thanks in advance for the help!

$10 Bounty

2 Replies

lr19-boy
FREE

a month ago

  1. Yes — in GitLab, environments are scoped to a project, and services within those environments (if using the Review Apps model or similar) are identified by their names. You cannot have two services with the same name in different environments within the same project unless they are versioned or namespaced differently

  2. Not necessarily.
    You can still keep it in a single project and structure your environments and deploy targets with distinct names for services and/or namespaces (especially if you're deploying to Kubernetes or a similar orchestrator). The best practice here is to have:

    • One project

    • Multiple environments

    • Services namespaced or suffixed by environment

  3. Use environment variables, Kubernetes namespaces, or infrastructure provisioning to distinguish between staging and production.


phoenixauro
HOBBYTop 10% Contributor

a month ago

1. Is this expected behaviour?

Yes. Within a single Railway project, environment contexts (Production, Staging, PR, etc.) are coupled. This means service names and their metadata are shared across environments—even if the environment is empty initially—so you can’t reuse the same service name in two environments independently.

2. Should I be creating two separate projects instead of relying on environments?

I would rely on environments.

3.What’s the intended workflow for staging/production pipelines like mine?

Railway natively supports the env-based GitOps CI/CD flow that you're after:

  • PR Creates Preview Environment

Enable PR environments in the projects Settings → Environments. A fresh, isolated environment spins up on each PR and is destroyed after merge/close. You can test things here.

  • Promote to Production

Merging from “pr” into “main” triggers production deployments automatically or via Railway/GitLab pipeline.


Anonymous
PRO

a month ago

I don't think I can enable PR environments as I'm using GitLab, and it's not integrated with Railway. That's one of the reasons I want to do everything from the GitLab pipeline.
I guess the best solution is to add suffixes to the service names, like backend-staging and backend-production. It's a bit weird, but I can live with that.


Multiple projects vs multiple environments - Railway Help Station