a month ago
RAILWAY SUPPORT TICKET — copy everything below this line:
Project ID: 63b3a4d4
Project: pal
Service ID: 5231fdbf
Service: wonderful-spontaneity
Environment ID: 0d6192db
Environment: production
CURRENT HEALTHY DEPLOYMENT
Deployment ID: 97a5d873-be5c-4c38-b0f0-71d24d91b166
Status: SUCCESS
deploymentStopped: false
Running instances: 1
Commit hash: 585eb41d
Repository: psmittyai/pal
This August 27 deployment remains active and continues serving production traffic.
FAILED DEPLOYMENT EXAMPLE
Deployment ID: 75766705-ffab-4ead-81f3-a872bf860595
Status: FAILED
deploymentStopped: true
Instances: []
Snapshot ID: 4fdd1b99-54cc-4f...
CLI metadata: cliCaller: agent_unknown:shell:openclaw, rootDirectory: "", reason: deploy
The deployment targets the same project, service, and production environment as the healthy deployment.
REPRODUCTION
We have reproduced this across 5+ deployment attempts. The original GitHub-triggered deployments failed before completing. We then tested direct "railway up --detach" deployments. Each CLI deployment receives a new/unique snapshot ID, but Railway subsequently marks the deployment FAILED with deploymentStopped: true and instances: []. The currently healthy August 27 deployment remains active. We also tested with build caching disabled (NO_CACHE=1). The behavior did not change.
Additional failed deployment IDs (same pattern):
10a2d68f-5249-4875-9cee-d1be282eea7d — FAILED, snapshotId 24c93ecf-c3e0-49...
f8b6dc93-84cf-4b19-8090-6ce53dc19ff1 — FAILED, snapshotId 95b3d3dd-5fca-4d...
802c3de1-e3cb-49b1-83ba-ceea78a73c8f — FAILED, snapshotId 907d450c-10d9-48...
29d8df94-ebe9-462d-9fe6-2f25e9088417 — FAILED, snapshotId c01c0aeb-4069-41...
IMPORTANT DIAGNOSTIC NOTE
Earlier CLI build-log output appeared to show a successful healthcheck. After inspecting railway status --json, we confirmed those logs were not associated with the failed deployments. The failed deployments have zero instances — they never reached application runtime or a healthcheck. We have no evidence of an application crash, failed healthcheck, Node/dependency failure, or a container starting and terminating.
SOURCE VERIFICATION
Repository root: correct. Local HEAD matched origin/main. HEAD: ad7705286b2dc9afa9ba6af92ad2c223864546ed. Local and committed package.json version: 1.1.0. Working files matched committed versions. No relevant files excluded by .gitignore. No .railwayignore exists. CLI-uploaded deployments do not expose commitHash or repo metadata in deployment meta, unlike the active GitHub deployment. We do not know if this is relevant.
QUESTIONS
Please inspect deployment 75766705-ffab-4ead-81f3-a872bf860595 and tell us:
- Why Railway sets deploymentStopped: true
- Why no container instance is created
- What internal failure/termination reason corresponds to this deployment
- Whether anything in this service/environment configuration prevents CLI snapshot deployments from being promoted
- Whether the absence of Git repository/commit metadata on railway up deployments is expected and relevant
- Whether there is a project/service setting or Railway-side condition that needs to be cleared before another deployment
We have stopped further deployments and application changes so the existing failed deployment evidence remains clean.
1 Replies
a month ago
Every failed deployment is dying at the build step with the error ENV names can not be blank on the generated Dockerfile's line 12. The service has an environment variable whose name starts with a literal $ character, which the builder shell-expands to an empty string during image generation, producing an invalid blank ENV directive. Rename that variable to remove the leading $ (so the name is just the key itself, without the dollar sign) and the builds will proceed past this point. The deploymentStopped: true and empty instances you are seeing are the normal result of a build that never completed, not a separate deployment-promotion issue.
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Solved psmittyai • about 1 month ago