Yes, the variable payload is what is stopping this. Your environment holds several sets of numbered chunks that carry encoded application code, and a start command that decodes and runs them. Storing code in environment variables is not a supported way to ship code on Railway. Once an environment holds that much encoded data, applying staged changes cannot finish.

The pending change still shows as applying, but the attempt to apply it has already stopped and is not running. The variable writes in that changeset are already in your saved configuration, so do not retry, restage, or re-submit it. Each attempt adds more data and makes the next apply fail sooner. Your current deployment is not affected by the stalled apply. The stuck status does not have to clear before you migrate.

To get the environment applying again, move the code out of variables and deliver it another way. You can deploy from a connected repo, build and deploy an image, keep large files on a volume, or fetch them at runtime from object storage. After that, set a short start command that runs the deployed files. Then remove every encoded chunk set and its metadata variables, and leave your regular configuration and secrets as they are.

Thank you. I understand the code-in-variables pattern is unsupported and I will not retry, restage or resubmit the current apply. I have not changed or restarted the live service.

I still need platform-level clarification before the migration: can you confirm whether every write in the stalled changeset has finished, and whether the stale APPLYING workflow/marker can be safely cleared? Is the supported route to replace the start command and delete the encoded chunk sets in a single new configuration change after the code files/image are ready, despite the existing APPLYING marker?

Please have a Railway engineer verify the safe sequence for this environment, especially the risk of partially saved configuration being used by any restart. We are preparing a file/image-based code delivery, not asking Railway to rewrite the application. Please preserve the current live deployment, service, persistent volume/database and unrelated configuration/secrets. No cleanup or deletion has been attempted.

The saved configuration for telegram-bot already has the stalled changeset's variable writes. The committed variables include CIRCE_LIVE_BOOT_25, CIRCE_LIVE_BOOT_26, CIRCE_LIVE_BOOT_PARTS and CIRCE_LIVE_BOOT_SHA256. The saved start command also already decodes the CIRCE_LIVE_BOOT_* set. So the change is not half-written on the configuration side. What never ran is the deployment step. Your running deployment is still the 15:02 UTC release, but any new deployment of this service would start from the saved configuration as it is now.

The change still shows as applying, but its apply process has ended and nothing is running behind it. Automatic reconciliation can later mark a stalled apply like this as failed. We can't give a time for when that will happen, and clearing that status doesn't fix the underlying size problem.

The environment holds three encoded chunk sets, APP_SOURCE_*, CIRCE_LIVE_BOOT_* and CIRCE_PATCH_*, each with its own parts and checksum variables. Taken together they are what keeps the environment from applying. Once your repo or image delivery is ready, the order is: switch the source and start command to the deployed files, and remove all three chunk sets and their metadata in that same change. Keep your regular configuration and secrets. Removing the encoded data is what lets the environment apply again. We can't promise how a change submitted while the old one still shows as applying will behave until that status has settled.

I still need help with the platform-side blocker. The latest automated answer says the apply process has ended, but also says it cannot confirm how a replacement change will behave until the APPLYING status settles. Please route this thread to a Railway engineer to verify or clear the stale apply marker and confirm the safe migration sequence. We will move code to supported file/image delivery and remove the encoded variables in the same change; we are not retrying the existing changeset. Please preserve the running deployment, service and persistent volume/database. No configuration cleanup or restart has been performed.