A deploy isn't done when the container starts

There is a specific class of deployment bug that is almost impossible to debug after the fact: the deploy reports success, the container is healthy, and yet for a while requests return 502. By the time anyone looks, everything is fine.

The cause is usually the gap between a container being ready and your app actually being reachable at its real URL.

Two different questions

“Is the container up?” is a useful question, and Railyard asks it before a new version is allowed to take traffic. But it isn’t the question your users are asking. They reach your application through its real domain, over HTTPS, and that path has its own moment of catching up after a release.

So a Railyard deploy checks both: the new version has to answer on its own first, and then it has to actually be reachable the way a visitor would reach it, before the deploy is marked done.

What happens if it isn’t

If the new version never becomes healthy, nothing moves: the old version keeps serving, the new container is removed, and the deploy is marked failed with the reason, including the new version’s own log lines so you can see why it didn’t come up.

If the new version is healthy but never becomes reachable at the real URL within a few minutes, Railyard rolls back on its own: the previous version is started again and the deploy is marked failed with the reason, rather than leaving an app half-switched.

The payoff

The point of all this isn’t the deploy itself. A deploy that finishes means the URL works, and an error in your logs afterwards means something is actually wrong with your application, not a leftover from the last release. That’s what makes zero-downtime deploys worth trusting instead of just hoping for.