Environment Sync / EnvironmentConfig — minimal patch for creating an existing Service in another environment
buselco
HOBBYOP

4 hours ago

Hello Railway Support,

we need clarification on the exact semantics of Environment Sync / staged EnvironmentConfig for an existing project-level Service.

Current topology:

  • one project-level Service already has a Service Instance in Environment A;
  • the same Service has no Service Instance in Environment B;
  • Environment Sync from A → B stages this Service as:

services[existingServiceId]:

isCreated: true

build: {...}

deploy: {...}

variables: {...}

We need to create the missing Service Instance in Environment B without:

  • deploying it,
  • attaching a repository or image source,
  • copying application variables,
  • creating domains,
  • creating volumes.

We intend to commit staged configuration with:

environmentPatchCommitStaged(skipDeploys: true)

or the equivalent Railway UI no-deploy action.

Could you please confirm:

  1. Is the following minimal staged EnvironmentConfig entry valid and sufficient to create the missing environment-specific Service Instance?

services[existingServiceId]:

isCreated: true

when committed with skipDeploys: true?

  1. If isCreated: true alone is not sufficient, which build/deploy fields are mandatory for Service Instance creation?

The Sync-generated entry currently contains these fields:

  • build.buildEnvironment = V3
  • build.builder = DOCKERFILE
  • build.dockerfilePath = /Dockerfile
  • deploy.ipv6EgressEnabled = false
  • deploy.multiRegionConfig.sfo.numReplicas = 1
  • deploy.runtime = V2
  • deploy.useLegacyStacker = false

Which of these, if any, are structurally required for creation of the Service Instance rather than merely optional build/runtime overrides?

  1. We also observed that a separate serviceInstanceUpdate attempt on a source-less Service in a disposable persistent/non-fork test project returned:

HTTP 400

Problem processing request

Does serviceInstanceUpdate in a non-fork environment attempt to apply configuration across other non-fork environments, and can the absence of that Service Instance in another environment cause this error?

We are specifically trying to understand the supported minimal provider configuration for creating an environment-specific instance of an existing Service without triggering a deployment.

Thank you.

$10 Bounty

0 Replies

Status changed to Awaiting Railway Response Railway • about 4 hours ago


Railway
BOT

4 hours ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • about 4 hours ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...