I have a production worker service that remains online and healthy, but I’m unable to deploy an updated release because repeated CLI deployments fail during Railway’s Snapshot code initialization stage, before any build starts.

Project / service

Project: virtuous-freedom

Environment: production

Service: small-moves-workbench-worker

Railway CLI: 5.41.2

Builder: Railpack

Node: 22 via RAILPACK_NODE_VERSION

Three failed deployment attempts

09e5dad4-865e-4075-86e0-e296d03329d5

85a56d10-9c59-4aa9-99ff-74d61d24cf18

5bbf38cf-81a7-42c4-bb90-d2d463a621e6

The earlier attempts eventually reported:

Deployment failed during the initialization process

Initialization > Snapshot code

Failed to create code snapshot. Please review your last commit, or try again.

Build, Deploy, and Post-deploy never started.

On the latest attempt I used railway up --detach --verbose against the existing production worker service.

The CLI:

indexed successfully;

compressed successfully;

produced a 3,206,658 byte upload payload;

reached the upload phase;

timed out after approximately 90 seconds with operation timed out;

nevertheless created deployment 5bbf38cf-81a7-42c4-bb90-d2d463a621e6;

that deployment did not acquire an associated build.

I also compared the source tree against a sibling service/worktree that deployed successfully via CLI recently. The successful source tree is actually slightly larger and produced a Railway code snapshot of about 3.2 MB. Both use the same .gitignore and .railwayignore.

The failing worker source contains no node_modules, build output, large binary assets, databases, or nested worktrees, so I haven’t found an obvious source-size or archive-structure explanation.

This appears to be failing during Railway’s upload/code-snapshot materialization rather than during application compilation or runtime.

Impact: the currently deployed production worker remains online, but deployment of the updated worker release is blocked. I’ve stopped making further deployment attempts to avoid creating more failed initialization records.

Could someone help determine why these uploads are failing to become code snapshots? In particular, I’d be interested to know whether Railway is fully receiving the archive before the CLI timeout, or whether there is a server-side snapshot/materialization failure affecting this service.

I can provide the verbose CLI output or additional deployment metadata if useful.