Having looked into this, the issue appears to be in your application code or configuration rather than the Railway platform itself, which puts it outside what Railway support can resolve directly.

This is exactly the kind of problem the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

Thank you, but I still need assistance from a Railway support engineer.

The conclusion that this is application code/configuration does not appear consistent with the deployment evidence.

The affected deployment completes SNAPSHOT_CODE, Railpack detects Python, and then BUILD_IMAGE terminates within seconds with only:

scheduling build on Metal builder "builder-rysztn"

repeated twice.

There is no Python traceback, dependency-resolution error, configuration error, pip error, application startup error, or other diagnostic output.

More importantly, the source is bit-identical to commit 6fd72f4, which successfully built earlier using the same Railpack version, Python version, service configuration, and builder.

We also reproduced the same silent pre-build failure across 16+ deployment attempts.

Before categorizing this as an application issue, could a Railway engineer please review the internal BUILD_IMAGE / Metal-builder records for deployment:

0f60c94f-a353-4978-ae98-7c4e3e174183

Service:

eff8518d-9b0f-473b-8e9d-ac01713a37e8

Specifically, please identify what application or configuration error Railway believes caused BUILD_IMAGE to terminate. If there is an application-level error, please provide the actual diagnostic/error record so we can correct it.

We do not want to make the thread public until Railway engineering has reviewed this evidence.

This still looks like an application-level problem, so Railway support can't take it further, but the community can. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

Additional technical context — what we need help solving

We are looking for help identifying why new deployments of this service are failing during Railway's BUILD_IMAGE stage even though the currently deployed version is healthy.

Current production status

Existing production deployment is ONLINE and healthy.

/health returns HTTP 200.

We do not want to disturb that working deployment while troubleshooting.

Failure behavior

We have experienced 16+ consecutive failed deployment attempts.

SNAPSHOT_CODE completes successfully.

Railpack detects the application as Python.

Python 3.13.15 is resolved.

Railpack version is 0.38.0.

BUILD_IMAGE then fails within only a few seconds.

There is no pip install output, Python traceback, dependency-resolution error, syntax error, or application startup error.

The only build-log output is:

scheduling build on Metal builder "builder-rysztn"

followed by the same scheduling message again.

Important comparison

The same application source/configuration successfully built earlier. The currently running production deployment was built successfully from known-good commit 6fd72f4.

We have also tested deployment attempts using source matching that known-good state, but the new builds still terminate during BUILD_IMAGE.

What we need from the community

We are specifically trying to determine:

What can cause Railway BUILD_IMAGE to fail before normal Railpack build output appears?

Is there a Railpack/Railway configuration or repository artifact that could cause this silent failure?

What diagnostic should we run next to distinguish an application/repository problem from a builder problem?

Is there a safe way to force a clean Railpack build/rebuild without jeopardizing the currently healthy production deployment?

Please do not suggest destructive production changes without explaining the impact first. This is a live production service, and the existing deployment is healthy.

Our immediate objective is simply to restore the ability to successfully build and deploy the existing backend again. Once that is working, we have a small production configuration update waiting to be deployed.

If you need a particular Railway configuration file, build-plan output, requirements file, deployment metadata, or command output to diagnose this, tell us exactly what you need and we'll provide it.