25 days ago
Hi Railway team,
We have a recurring issue with Metal Build Environment (MBE) being
re-enabled automatically on our production services, despite explicit
configuration to disable it. This has caused multiple production
incidents on our platform.
ENVIRONMENT CONTEXT
- Stack: PHP 8.4 + Symfony 7 + Nginx + Supervisord (custom Dockerfile)
- Build method: Custom Dockerfile per service
WHAT WE'VE IMPLEMENTED TO PREVENT MBE
1. railway.toml at backend/ and frontend/ Root Directories with
explicit configuration:
[build]
builder = "DOCKERFILE"
dockerfilePath = "Dockerfile"
[deploy]
startCommand = "..."
restartPolicyType = "ON_FAILURE"
restartPolicyMaxRetries = 3
We deliberately do NOT include buildEnvironment = "V3" anywhere.
2. Manual UI toggle: "Use Metal Build Environment" set to OFF on
every service Settings → Source → Build.
3. Custom post-deploy smoke check workflow on GitHub Actions that
detects vendor/ being empty (the symptom of MBE ignoring our
Dockerfile) by curling our OAuth endpoint and grepping for
"Symfony Runtime is missing" in the response body.
THE PROBLEM
Despite all of the above, MBE re-enables itself on our services
periodically. We've experienced this on multiple deploys, including
one production incident on April 26, 2026.
When MBE activates:
- Railway ignores our backend/Dockerfile (which contains
"composer install --no-dev" + nginx + Supervisord setup)
- The container starts but vendor/ is empty
- Symfony fatal error: "Symfony Runtime is missing"
- All endpoints return 500
- Production downtime until manual toggle OFF + redeploy
WORKAROUND WE CURRENTLY USE
When MBE re-activates:
1. Settings → Source → Build → toggle "Use Metal Build Environment" OFF
2. Manual redeploy
3. Verify build logs show "Building image" (not "scheduling build on
Metal builder")
This requires manual intervention every few deploys. Not acceptable
for a production system.
REQUEST
We need a permanent way to disable MBE at the project or service
level that cannot be auto-overridden by Railway's gradual rollout
process. Options we'd accept:
a) An environment variable like DISABLE_METAL_BUILD=true that
guarantees MBE never activates on a service.
b) A project-level setting that opts the entire project out of MBE
rollouts (similar to a "stay on V1 builder" flag).
c) A guarantee that the UI toggle "Use Metal Build Environment = OFF"
is permanent and not re-evaluated on each deploy or rollout phase.
d) An updated railway.toml syntax with an explicit "disable MBE"
directive that survives Railway-side overrides.
We want to use Railway long-term and the platform has been excellent
overall. But repeated production incidents from a beta feature being
forced on without notice is a significant operational risk for us.
Could you please provide:
1. A definitive way to disable MBE permanently on our services, OR
2. A clear timeline for when MBE will respect the UI toggle and
railway.toml without auto-overriding.
Happy to provide service IDs, build logs, or any debug info you need.
Thanks,
3 Replies
Status changed to Open Railway • 25 days ago
25 days ago
Hello,
We are rolling out metal builders to everyone and soon this would be the only way to build.
From what I see it builds using backend/Dockerfile (you can see this in the build log),
so it is unlikely that the result image is different. You may want to build it with docker build
and run a container.
25 days ago
Hi,
We tested the Dockerfile build locally with the exact same Dockerfile
in our repo. The resulting container has /app/vendor/ correctly
populated (13,195 files, including autoload_runtime.php at 985 bytes).
So the Dockerfile is fine. When our Railway deploys crash with
"Symfony Runtime is missing", it means /app/vendor/ is empty in the
final image, which contradicts what the Dockerfile produces.
This points to Metal Build silently bypassing our Dockerfile and using
a different build path that produces an empty vendor/.
Could you escalate to engineering with our service IDs to investigate
why Metal Build is not respecting the Dockerfile?
Thanks,
25 days ago
Hi,
I really wanted to thank you for everything Railway has been over the
past months — the platform has been a genuine pleasure to work with.
The DX, the deploy speed, the dashboard, the simplicity of going from
GitHub to production — it's all been excellent and a big reason why
I built Sobrus Inside on Railway in the first place.
Unfortunately, Metal Build has been a deal-breaker for us.
Initially, I could disable it manually every time it re-activated.
That was already painful (multiple incidents, manual intervention
on every deploy across 8 services), but I was willing to live with
it.
Now the toggle no longer responds at all. The build cache is locked.
We've tried:
- railway.toml with builder = "DOCKERFILE" pinned explicitly
- NO_CACHE=1 environment variable
- DEPS_CACHE_BUST bump
- Duplicating the service to get a fresh state
- Switching builder to Dockerfile in the UI
None of it works. Every deploy still produces a container with an
empty /app/vendor/, even though our Dockerfile (verified locally and
in GitHub Actions) builds a full vendor/ with 13,195 files.
We've also confirmed via threads from other users that this is a
known platform-side issue you're aware of, and that the resolution
timeline is not in our hands.
So I'm going to migrate off Railway. Sad about it, because everything
else about the platform is great.
Thanks for everything,