a month ago
We have an existing source-less staging service with zero deployments. Dockerfile, private volume and runtime settings are configured. We need its first deployment to use one reviewed Git commit, with auto-deploy disabled throughout source attachment and later operation. We cannot first deploy a mutable branch and then disable automation.
Authenticated live API introspection exposes environmentStageChanges; EnvironmentConfig source.repo, nullable source.branch and source.commitSha; environmentPatchCommitStaged(skipDeploys); serviceInstanceAutoDeployUpdate(enabled); serviceInstanceAutoDeployStatus; and serviceInstanceDeployV2(commitSha). Current source-less status is enabled=false, canEnable=false, reason=NO_REPO.
Please confirm the supported sequence:
- Can we stage source.repo with branch=null and commitSha=the full reviewed SHA, then commit with skipDeploys=true, without creating an initial deployment or any Git-push deployment trigger?
- Does disabling auto-deploy while source is absent persist through first source attachment, or does disable only remove existing triggers?
- If that sequence is unsupported, what official API/CLI sequence attaches the repository with auto-deploy disabled from the outset, targeting only this existing staging service?
- After safe attachment, does serviceInstanceDeployV2(commitSha) fetch the exact repository commit and record its actual resolved SHA as deployment meta.commitHash? We need platform provenance, not a manually assigned label.
Please identify any defaults that populate a branch or re-enable triggers, and the read-only fields that prove the final state. Railway CLI up tarball uploads lack the Git-source metadata required by our present release contract.
This is a pre-deployment capability question, not an outage. No failed deployment or application logs exist. We have not attached a source or experimented on the database. No credentials or private repository details are included.
Reviewed sources: https://docs.railway.com/deployments/github-autodeploys ; https://docs.railway.com/integrations/api/manage-services ; https://docs.railway.com/cli/up ; https://backboard.railway.com/schema/environment.schema.json .
1 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 30 days ago
a month ago
I think there are two separate requirements here, and it is important not to mix them: binding the GitHub source and deploying a specific Git commit.
For the pinned commit itself, I would not rely on EnvironmentConfig.source.commitSha as the supported deployment contract. The public Railway API explicitly supports deploying an exact commit through:
serviceInstanceDeployV2(..., commitSha: "<full SHA>")
Railway documents that the SHA is validated against the connected GitHub repository. If the commit does not exist in that repository, Railway returns "Commit not found" and does not create a deployment. So this is the mechanism I would use for the actual reviewed release.
The difficult part is your requirement that attaching the repository must create absolutely zero deployments/builds and must never temporarily enable push autodeploy.
I would not assume that:
serviceInstanceAutoDeployUpdate(enabled: false)
while the service is still in NO_REPO state is guaranteed to survive the repository attachment. Likewise, environmentPatchCommitStaged(skipDeploys: true) should be treated as "do not deploy because of this staged configuration commit", not as a guarantee that GitHub deployment triggers cannot be created when the source is connected.
The safest sequence I would use is:
-
Keep the existing service source-less until the reviewed SHA is known.
-
Connect the GitHub repository using the supported source connection API.
-
Immediately read back:
serviceInstanceAutoDeployStatus- the configured source
- deployment triggers for that service
- deployment history / latest deployment
-
Confirm that autodeploy is disabled and that no GitHub push trigger exists. If a trigger exists, remove or disable it.
-
Only after the source state is verified, call:
serviceInstanceDeployV2(commitSha: "<40-character-reviewed-SHA>")
- Read the resulting deployment back and verify its Git commit metadata rather than supplying your own release label as provenance.
However, there is an important limitation: if your contract requires a deterministic guarantee that no deployment record and no build can be created even momentarily during source attachment, steps 2–4 are not enough, because they still contain a possible race.
I cannot find a documented public Railway API operation that atomically performs:
connect repository + disable autodeploy + suppress initial deployment
as one transaction.
So for that strict requirement, I would ask Railway staff to explicitly confirm whether such a pre-deployment attachment contract exists before relying on undocumented/introspected fields.
In other words: exact-SHA deployment is supported. The part that still needs authoritative confirmation is whether repository attachment itself can be guaranteed to be completely deployment-free from the first instant.
I would also avoid railway up for this workflow, since your requirement is Git-backed platform provenance rather than a source archive upload.