13 days ago
Subject: V3 rollout Service: (68c85c3c-7fd4-4caf-bc5e-6c1e0cb2cf96) Project: 866cea16-b5ef-42a3-a5ea-6d6381a05b64 Environment: production Timeline: - Service deploys via CLI only (railway up), never GitHub — intentional - Worked fine until ~11:05 AM UTC Aug 8, when buildEnvironment V3 enforcement began - First: 20+ failed deployments with "Failed to create code snapshot" error - Root cause: railway.json specified NIXPACKS (deprecated in V3) - Fix applied: changed builder to RAILPACK, removed nixpacks.toml, pinned Node via package.json - New issue: snapshot now hangs indefinitely instead (SNAPSHOT_CODE pending, no error, 12+ minutes) Current state: - Most recent deployment (36c8e085-811e-4e67-ae12-c7178e13b9d7) sat at SNAPSHOT_CODE with no logs for 12+ minutes before failing - Build logs empty entire time (snapshot never started creating build logs) - Service undeployable via CLI; production still serving last successful deploy Key question: What changed in V3's snapshot handling for CLI-only (sourceless) deployments around 11:05 AM UTC today? The builder fix removed the config conflict, but exposed what looks like a deeper V3 issue specific to CLI uploads with no GitHub source.
1 Replies
13 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 13 days ago
13 days ago
The Nixpacks/Railpack change and the current hang are two different stages.
SNAPSHOT_CODE happens before Railpack (or any builder) starts. Railway's current railway up docs describe the client flow as scan/compress/upload first, then the platform builds the uploaded source. That matches your empty build logs: changing builder, pinning Node, or removing nixpacks.toml can fix config validation, but it cannot fix a 12-minute remote snapshot timeout.
Railway has diagnosed the same CLI-only/no-Git symptom before as an intermittent timeout in the service that receives the CLI upload and stores the code snapshot—not a repo, billing, or builder problem:
https://station.railway.com/questions/repeated-cli-uploads-fail-at-snapshot-co-a352aaf1
I would do exactly one diagnostic upload, not another retry storm:
railway up . --path-as-root \
--service 68c85c3c-7fd4-4caf-bc5e-6c1e0cb2cf96 \
--environment production \
--detach --verboseThe flags are documented here: https://docs.railway.com/cli/up
If the CLI completes the upload/queues the deployment and the dashboard then remains in SNAPSHOT_CODE with no build logs, that isolates the failure to Railway's snapshot backend. Keep the failed deployment ID and UTC window and ask Railway to inspect snapshot-storage timeouts for that ID. I would stop repeated deploys meanwhile; they will not change the uploaded source and may just add more queued failures.
For an urgent CLI-only workaround that bypasses source snapshotting, build and push a Docker image yourself and temporarily connect the service to that image source. Railway documents railway service source connect --image <registry/image:tag> here:
https://docs.railway.com/cli/service
I cannot find a public Railway changelog documenting a new V3 contract for sourceless CLI uploads at 11:05 UTC, so only Railway can confirm the exact rollout change. The observed stage boundary and the prior employee diagnosis point to a platform-side upload/snapshot regression, not Railpack or your application.