8 days ago
An existing single-replica service using node:22-bookworm-slim remains healthy, but two new deployments on 27 September around 21:05 and 21:07 UTC were marked Failed after roughly 1–2 seconds.
The dashboard shows Initialization at 00:00; Deploy, Network and Post-deploy never start. Both the dashboard and logs API return no build/runtime logs. The diagnosis panel only says the agent usage limit has been reached, so it does not expose the underlying error. Trial credit remains available.
The candidate starts and passes its tests locally. A smaller code transfer failed in the same way. The existing image, region, replica count, volume and healthcheck settings were retained. We restored the last verified start configuration and kept the previous healthy deployment running.
The affected service is attached through the service selector. Could Railway staff check the underlying initialization/validation error for its two latest failed deployments, or suggest another way to retrieve that error without the diagnostic agent? Please do not restart production or change the plan/billing. No credentials, environment values or user data are included here.
2 Replies
8 days ago
Both deployments failed before initialization. The variable set being saved to each deployment was over the size limit, so the deployment stopped before any build or container started, and that is why there are no logs.
Compared with your last successful deployment on 25 September, this service now has 52 new variables: a MAZECHAT_V070_000 to MAZECHAT_V070_048 series, two *_BOOT variables, and VIDEO_ENABLED, plus a changed MAZECHAT_RELEASE_ID. The added chunk and boot variables are what push the snapshot over the limit, and a smaller transfer still stored through variables would hit the same wall. Remove the MAZECHAT_V070_* and *_BOOT variables from the service's variables, then ship the code in the image or source instead of in environment variables. Your running deployment stays untouched until a new one succeeds.
Status changed to Awaiting User Response Railway • 8 days ago
8 days ago
Confirmed: removing obsolete code-bundle payloads brought deployment snapshots under the size limit. The updated release now starts and passes its startup checks and isolated public application tests. The prior verified encrypted release remains available for rollback. Thank you for identifying the initialization failure. We will move the source delivery out of variables as a separate maintenance improvement.
Status changed to Awaiting Railway Response Railway • 8 days ago
Status changed to Solved Railway • 8 days ago