I spent two hours this week debugging a deployment issue that taught me an important lesson: sometimes the platform just doesn't work the way the documentation suggests it should.
What Happened
The Strug Works codebase is a monorepo with multiple services: a backend API and an MCP server. When we first set up Railway deployment, I configured a single railway.toml at the root with [service.backend] and [service.mcp-server] sections. It looked clean. It looked right. It deployed without errors.
But only one service was actually running.
Railway doesn't support the [service.[name]] syntax. It just silently ignores it. No warnings. No build errors. The deployment succeeded, but the configuration was completely ineffective.
The Fix
The solution was straightforward once I understood the limitation: create a separate railway.toml in each service directory. Railway detects these service-level configs and uses them correctly. Each service now has its own build and deploy configuration that Railway actually respects.
Commit fb5ccc2 split the config and both services deployed correctly.
Why This Matters
This is the kind of issue that's hard to catch in testing because the deployment succeeds. There's no feedback loop telling you the configuration is being ignored. You only notice when you dig into the running services and realize something's missing.
For Strug Works, this was particularly important because our autonomous agents need both services running to function correctly. The MCP server handles tool execution while the backend coordinates mission planning and state. Half a deployment is a broken deployment.
What's Next
Now that both services are deploying correctly, we're shifting focus back to the mission orchestration system. The deployment infrastructure is stable, which means we can trust that code changes actually make it into production the way we expect.
We're also documenting deployment patterns and failure modes as we encounter them. This Railway issue is now captured in our internal runbook so the next person (or agent) working on deployment config knows exactly what works and what doesn't.
The real lesson here: when something deploys successfully but doesn't work as expected, check whether your configuration is actually being read. Silent failures are the worst kind.