a month ago
Summary: Every push to our staging branch causes this service to create two deployments ~11 seconds apart:
a correct git deployment (carries commitHash + branch + its own image), and
a no-commit "phantom" deployment with no commit metadata and a different image digest — which supersedes the git build and becomes active.
A sibling service in the same project, deploying from the same monorepo and branch (web-staging), receives exactly one git-tracked deployment for the identical push. The two services' configs are byte-identical: each has a single repoTrigger (same repo @ staging) and source = {image: null, repo: }.
Concrete evidence (same repo, same pushes):
Push ad09bb3: api-staging → deployment 8e394f65 (commit ad09bb3, image df003c6…) plus 141ce12e (no commit, image de111de7…, went active). web-staging → single deployment 4bf0f838 (commit ad09bb3).
Push 6c8ed70: api-staging → 51600321 (commit 6c8ed70) plus 37f51223 (no commit). web-staging → single 82f56fd1 (commit 6c8ed70).
The phantom's image digest is unique on each push, so it's a second build pipeline, not a redeploy of one cached image.
Pattern present since at least 2026-07-07.
What we've ruled out / tried: Only one repoTrigger exists (verified via GraphQL repoTriggers). serviceInstance.source has no image source. Dashboard Source → Disconnect + reconnect to the repo did NOT clear it (the very next push still produced the pair). A manual railway redeploy --from-source does produce a stable single git deployment — only push-triggered builds spawn the phantom.
Likely origin: this service previously received manual railway up CLI uploads (early July); we suspect a residual/duplicate deploy pipeline from that.
Ask: Please identify and remove the hidden/duplicate build pipeline on this service that emits these no-commit deployments, so a push produces a single git-tracked deployment like every other service.
1 Replies
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Our audit logs show every "phantom" deployment on api-staging is created by a project token named "github-actions-deploy" (source: CLI), while the git-tracked deployment comes from the native repo trigger (source: GitHub). A GitHub Actions workflow in your repo is running a CLI deploy on api-staging on every push, in parallel with the native webhook, which is why you see pairs. Your repoTriggers check was correct - there is only one native trigger - but the second pipeline is not a trigger; it is an external CLI invocation via that token. You can remove or disable the Actions workflow step, or revoke the token from your project's Settings > Tokens page, to get back to a single deployment per push.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • about 1 month ago