2 hours ago
Our existing Docker-based web service repeatedly fails during Initialization before any build or deployment logs appear. This blocks a planned update, while the previous successful deployment still serves HTTP 200. The affected service is selected in this request.
On 13 November 2026 (UTC), the failed attempts finished in approximately 0.4–1.2 seconds, before region assignment. The deployment diagnosis and failure reason/stage/error were empty.
We tested these distinct cases:
- Redeploying the last successful build.
- Reconnecting the existing public image public.ecr.aws/docker/library/nginx:alpine.
- Using the same linux/amd64 image from Docker Hub, pinned by digest, to check whether the problem was specific to ECR.
The ECR and Docker Hub manifests matched this public amd64 digest: sha256:697b0b156c70b91130853fd0675c6be36665939d5f93dce2686be04b4c3f98a8. This comparison was made from our build environment and does not establish Railway registry connectivity.
The Docker Hub attempt failed at about 11:02:35 UTC (606 ms). We restored the original ECR source and startup configuration; the resulting attempt also failed at about 11:03:11 UTC. The old active deployment continued serving the unchanged site.
Could the Railway team inspect the internal initialization error for the attached service and advise how to unblock deployments? Please preserve the active deployment, existing variables and unrelated pending changes. No secrets, customer records or internal resource identifiers are included in this public message.
1 Replies
2 hours ago
These deployments are failing because the environment's configuration has grown too large to process, not because of the image or registry. That is why both the Docker Hub and ECR sources failed in the same way.
The service stores its site as encoded and compressed content in a large number of environment variables, and the start command decodes that content at boot. Storing code, HTML or assets in variables isn't supported. Every deployment has to carry the whole environment's configuration, so this is what blocks new deployments. Retrying with the same configuration will fail the same way.
To deploy again, move that content out of variables and the start command, then remove the encoded variables. You can deploy the files from a connected repository or a built image, keep large files on a volume, or fetch them at runtime from object storage such as Railway Buckets. Then replace the start command with a short one that serves the deployed files. Variables are meant for configuration and secrets.
Status changed to Awaiting User Response Railway • about 2 hours ago