6 hours ago
Repeated build failures (3 times within 1 hour) on Metal builder builder-fvdcqb,
service "Wads", deployment 9ac5f900.
Error each time: "failed to solve: secret X not found", occurring consistently
at the "Install mise packages: Python" step (~500ms after loading
railpack-plan.json).
The name X changed on every attempt and matched whatever environment variable
had just been modified at build time: "Wads", then "context canceled", then
"redeploy" — this suggests a BuildKit session drop mid secret-resolution,
rather than an actually missing variable.
Railway's own diagnostic confirmed that the exact same commit had already
been built and published successfully in a previous deployment.
No custom Dockerfile, standard Railpack build (Python, pip).
Workaround: switching the builder from Railpack to Nixpacks (deprecated)
allowed the build to succeed. Happy to switch back to Railpack and help
test once this is fixed, since Nixpacks isn't meant to be a long-term option.
1 Replies
Status changed to Awaiting Railway Response Railway • about 6 hours ago
6 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 6 hours ago
2 hours ago
Hi, based on the behavior described, this looks more like an intermittent Railpack/BuildKit secret-mount issue than a genuinely missing application environment variable.
The fact that the same commit previously built successfully, the reported secret name changes between failures, and Nixpacks works suggests the issue may be related to the build process rather than the application's configuration.
I'd recommend the following checks:
- Retry the exact same commit using a GitHub-triggered deployment instead of
railway up, if applicable. - Compare the results using Railpack and a Dockerfile-based build.
- Check whether the failure occurs during dependency installation or another BuildKit stage.
- Collect the failed deployment IDs, builder details, UTC timestamps, and relevant build logs for Railway support.
As a temporary workaround, use the previously successful Nixpacks configuration or a Dockerfile while investigating the Railpack failure.
I would avoid creating environment variables matching the changing secret names, since those names may be internal to the build process.
If you can share the relevant build-log section with sensitive values removed, I can help narrow down the failing stage and suggest a more targeted fix.
Disclosure: AI assistance was used to prepare this analysis. I have not reproduced the issue in the affected project.