a month ago
Hello Railway team,
I am experiencing a reproducible failure when deploying local code with Railway CLI 5.27.0.
Three CLI deployment attempts created remote deployment records but all failed during:
Initialization > Snapshot code
Error:
Failed to create code snapshot. Please review your last commit, or try again.
If this error persists, please reach out to the Railway team.
Failed deployment IDs:
49973b05-91a9-4694-b1b0-c36a918e18d4
createdAt: 2026-07-18T23:04:03.955Z
00840f5a-9ba2-418a-bf0b-2d60cee2f057
createdAt: 2026-07-18T23:28:18.461Z
3e0feb3e-606a-4a04-b192-50b9ad268dc6
createdAt: 2026-07-19T00:15:57.965Z
Each deployment remained INITIALIZING and failed at Snapshot code after approximately 15 minutes. Build, deploy and post-deploy never started.
The CLI output from the last attempt was:
Indexing...
railway up
service:
environment:
bytes: 2212758
Uploading...
error sending request for url (.../up...)
Caused by:
0: client error (SendRequest)
1: connection error
2: An existing connection was forcibly closed by the remote host. (Windows os error 10054)
The third attempt used a clean disposable directory created from:
- git archive of HEAD 5ef6898
- overlay of exactly two modified source/test files
- no .git directory
- 828 files
- railway.json present
- Dockerfile.private-read-api present
Therefore the same failure occurs independently of an uncommitted working tree or repository metadata.
The previous successful deployment remains online:
That deployment correctly resolved:
configFile=/railway.json
builder=DOCKERFILE
dockerfilePath=Dockerfile.private-read-api
healthcheckPath=/__bill/health/live
Could a Railway team member inspect the upload/code-snapshot backend
for the three failed deployment IDs?
Please do not trigger a redeploy automatically. The previous successful
deployment remains online.
3 Replies
a month ago
Your workspace's Hobby subscription is currently in an INACTIVE state, which is the most likely reason the upload is being rejected at the snapshot stage (the "connection forcibly closed" error is the server-side rejection surfacing as a network error in the CLI). You can check and resolve your subscription status at your workspace billing page, and once the subscription is active, railway up should complete normally.
Status changed to Awaiting User Response Railway • about 1 month ago
Railway
Your workspace's Hobby subscription is currently in an INACTIVE state, which is the most likely reason the upload is being rejected at the snapshot stage (the "connection forcibly closed" error is the server-side rejection surfacing as a network error in the CLI). You can check and resolve your subscription status at [your workspace billing page](https://railway.com/workspace/billing), and once the subscription is active, `railway up` should complete normally.
a month ago
Thanks, but the workspace is currently on an active Trial plan, not an inactive Hobby subscription.
The billing page shows:
- Trial plan
- 30 days or $4.99 remaining
- $5.00 credits available
- only $0.0081 consumed
Railway's documentation states that Trial users can deploy code, including Limited Trial users.
Could a human Railway team member please verify whether this workspace is being incorrectly classified as having an inactive subscription in the upload/code-snapshot backend?
I do not want to upgrade to Hobby merely to work around a potentially incorrect subscription flag.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Hi, thanks for the detailed report, and apologies for the earlier automated reply. It was wrong: your workspace is on an active trial, and there is no billing or subscription check on the CLI upload path at all. Nothing about your plan is blocking these deploys.
We checked the backend for your three failed deployment IDs. The root cause is on our side: the service that receives the CLI upload and stores the code snapshot was intermittently timing out while writing to our storage backend during your attempts. When that happens the connection is dropped mid-upload, which surfaces on Windows as error 10054, and the deployment sits at "Snapshot code" until it fails. Your local setup, uncommitted files, and repo metadata are not a factor, which matches what you proved with the clean-directory test.
The issue is intermittent rather than a full outage, so retrying railway up should succeed, and we have not triggered any redeploy on our end as you requested. We're escalating the elevated timeout rate to our platform team. Sorry for the trouble here, and let us know if a retry still fails for you.
Status changed to Awaiting User Response Railway • about 1 month ago
24 days 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 • 24 days ago