The change set is still marked as applying, but the apply attempt behind it is no longer running. No new deployment was created from it. Your current portal configuration already contains HUB_ASSET_0 through HUB_ASSET_26 and HUB_ASSET_PARTS. The pending set adds or changes HUB_ASSET_0 through HUB_ASSET_29 and replaces the start command. Because some asset variables already exist, don't assume this attempt changed nothing. Please don't retry or restage it either.

The Bun Function itself is a supported way to deploy, and so is its encoded start command. Splitting public assets across numbered environment variables is not supported. Every apply carries the whole environment's configuration, so a large set of asset chunks can stop applies from finishing. The pending set can't be fixed by clearing or restaging it, and the same changes would get stuck again.

Moving the assets into your file-based Docker deployment is the right fix. You can ship them from a connected repository or a published image, keep large files on a volume, or fetch them from object storage. Once the service runs the Docker deployment, the obsolete HUB_ASSET_* variables can be removed so only regular configuration and secrets stay in variables. We haven't confirmed the exact order for applying this switch while the current change set is still marked as applying.

Thank you. The corrected file-based package is ready, and the account holder has authorized me to deploy it to the existing portal service. The public API still reports APPLYING with lastAppliedError=null and appliedAt=null.

Please have Railway engineering confirm whether this old workflow is fully stopped and whether a direct CLI upload (railway up) to the same service can safely create a new Docker deployment while the marker remains. Can you clear the stale marker and confirm the safe source/start-command migration and asset-variable cleanup sequence? We need an actionable recovery path that preserves the healthy services and existing URL.

We re-checked the change set: the apply attempt behind it is no longer running, and it is still marked as applying with 32 pending changes, the new Function start command plus HUB_ASSET_0 through HUB_ASSET_29 and HUB_ASSET_PARTS. Your live portal is still the Bun Function, and its current variables already include HUB_ASSET_0 through HUB_ASSET_26 and HUB_ASSET_PARTS, so some of these writes have landed even though no deployment was created and no error was recorded.

We can't clear that marker from our side. It can be settled automatically some time after the attempt stopped, but we can't give a time for that, and clearing it would not fix the cause. Please don't retry or restage it, because each attempt writes more asset data into the environment and makes the next apply fail sooner.

We have not verified whether a railway up upload to the same service creates a new deployment while the marker is still there, so we can't confirm it as a safe path.

The fix that stays the same in every case is getting the assets out of variables. Ship them inside your file-based Docker build from a connected repository or a published image, keep large files on a volume, or fetch them from object storage. Then remove the obsolete HUB_ASSET_* variables so that only regular configuration and secrets stay in variables, such as PORT, PUBLIC_ORIGIN and JSON_SECRET_KEY. The service's existing domain belongs to the service, not to the variables you're removing.

Recovery update: the same portal service is now running the file-based Docker release successfully. We disconnected the legacy Function source, corrected its start command, and uploaded only the deployment folder with the Railway CLI. The new deployment is SUCCESS, the public health endpoint reports the expected release, and both private gateway services remain online. We then removed all 28 obsolete HUB_ASSET_* variables with an explicit variable-only environment patch and skipDeploys=true; that patch is COMMITTED and saved variables now contain only normal configuration and secrets. No old asset payload was retried or restaged. The old 32-change workflow still appears as APPLYING in environment status. Replacing the current staged input with an empty patch did not clear that historical marker. Please retire the stale workflow without replaying it; the old start command and asset variables must not be restored. The live hub is available, so this is now a stale status cleanup request rather than an outage.