Deploys and rollbacks

What happens during a deploy

1. Build. With a repository, Railyard builds an image on a dedicated build server if your team has one, otherwise on the app’s own server or a temporary build server Railyard starts for the job. With an image:// source, it pulls the image instead; nothing is built. See Build methods.
2. Release command. If the app has one set, it runs once against the new image before anything takes traffic. This is where migrations belong. If it fails, the deploy stops there and the app keeps running its old version.
3. Health check. The new container starts next to the one already running. It has to come up and, if the app has a health check path set, answer it within the configured timeout.
4. Traffic switch. Only once the new container passes does traffic move to it. A standard deploy moves all of it at once; a canary deploy sends it a share first. See Canary deploys and deploy windows.
5. Old version stops. The previous container is kept running until the new one is confirmed, then removed. This is what makes deploys zero-downtime: there’s no moment where the app has no working container answering.

If something fails

If the build, the release command or the health check fails, Railyard leaves the previous version running and marks the deploy failed. A bad deploy never takes your app down. The deploy page explains what failed and links to a fix; see Troubleshooting failed deploys.

Rolling back

Rolling back redeploys an earlier successful release’s commit (or image) and puts back the variables it ran with. The confirm page lists which variables change back and warns if a secret changed since that release. To keep today’s variables and only restore the code, choose code-only (or pass it as a flag/parameter).

• Dashboard: on the app’s Releases & deploys tab, choose Roll back to v<n> next to an earlier successful release.
• CLI: railyard releases my-app lists releases to roll back to; railyard rollback my-app <version> [--code-only].
• API: POST /api/applications/:id/deploys with rollback_to (the id of an earlier succeeded deploy) and optionally "restore_config": false.

A rollback is itself a deploy: it goes through the same build-or-pull, release command, health check and traffic switch as any other deploy, and respects the app’s deploy window unless you override it. Releases deployed before Railyard started keeping a copy of their variables can only roll back their code.

Release history

Every successful deploy with a commit is numbered as a release (v1, v2, …). The app’s Releases & deploys tab lists them, with older deploys a click away; railyard deploys --app my-app and GET /api/deploys?application_id=:id show full history from the CLI and API. Each deploy keeps its log, trigger, commit and any note.

See also

• Canary deploys and deploy windows — partial-traffic releases, scheduled and windowed deploys, deploy notes.
• Build methods — which builder runs and how builds fit your servers.
• Troubleshooting failed deploys — what each failure reason means and how to fix it.