Canary deploys and deploy windows

These are the controls for when and how a release goes live. All of them are on the app page and in the API; most are also in the CLI.

Canary deploys

A standard deploy moves all traffic to the new release once it passes its readiness check. A canary deploy runs the new release next to the current one and sends it only part of the traffic first.

Turn it on: app → Settings → General → Deploy strategy. Choose Canary and set:

• Canary share (%): 1–99. That share of new visitors gets the new release. A cookie keeps each visitor on the version they got first, for a day.
• Ramp steps (%): an optional ascending list, e.g. 5, 25, 50. Each step runs as its own canary with the same automatic rollback below; once the last step clears, promote sends it to 100%. Leave it blank for one step, then promote by hand.
• Dwell per step (minutes): leave it blank to promote each step by hand. Otherwise Railyard advances to the next step, or promotes the last one, on its own after that many minutes.
• Roll back above 5xx rate (%): if a step’s error rate goes above this, Railyard rolls it back.

While a canary is live, the app page shows a banner. The deploy page compares the canary’s requests, 5xx rate and p95 latency with the rest of the app and has Promote (sends 100% to the new release, or starts the next ramp step) and Roll back.

Things to know:

• The release command, such as your migrations, runs before the canary starts, so migrations must work with both versions.
• Workers and any extra servers keep the current release until you promote.
• The first deploy of an app, a deploy during maintenance mode, a worker-only app and an app with a data volume always use a standard deploy.

API: PATCH /api/applications/:id/deploy_strategy (deploy_strategy, canary_percent, canary_steps_text — comma-separated, e.g. "5, 25, 50" — canary_promote_after_minutes, canary_max_error_rate), then POST /api/deploys/:id/canary/promote or DELETE /api/deploys/:id/canary. There is no CLI command for canaries yet.

Deploy windows

A deploy window sets the days, hours and time zone an app is allowed to deploy in. Set it under Settings → General → Deploy window.

• Pushes and auto-deploys outside the window wait, and go out as one deploy when the window opens.
• A manual deploy outside the window asks first, and you can deploy anyway.
• A rollback outside the window deploys anyway, with a warning on the confirm page.
• A window that ends before it starts runs overnight (22:00–02:00). Untick every day to allow deploys at any time.

railyard deploy-window my-app mon,tue,wed,thu,fri 09:00 17:00 America/Toronto
railyard deploy-window my-app off
railyard deploy my-app --anyway          # outside the window

API: PATCH /api/applications/:id/deploy_window with days, start, end and time_zone. "days": [] removes the window.

Scheduled deploys

Pick a time and the deploy starts then. The time has to fall inside the deploy window, if the app has one. You can cancel a scheduled, queued or running deploy.

railyard deploy my-app --at 2026-10-02T14:00:00Z --message "pricing page"
railyard deploy:cancel 482

API: POST /api/applications/:id/deploys with at (ISO 8601), and POST /api/deploys/:id/cancel.

Deploy notes

Add a note of up to 500 characters to a manual deploy or a rollback. It shows in the deploy lists, on the deploy page, in the activity log, in notifications and in deploy.* webhooks. A retried deploy keeps its note.

railyard deploy my-app --message "hotfix for checkout"

Rollbacks bring the variables back

Rolling back redeploys that release’s commit and puts back the variables it ran with. The confirm page lists the variables that change back and warns if a secret changed since. To roll back the code and keep today’s variables:

railyard rollback my-app 471 --code-only --message "roll back, keep new keys"

Releases deployed before Railyard kept a copy of their variables can only roll back their code.

Deploy a branch, tag or commit once

Deploy options… on the app page, railyard deploy my-app --ref v2.1.0, or ref in the API deploys another branch, tag or commit once. The branch the app tracks doesn’t change.

Strict git pushes

With git push railyard main (see CLI), a push waits for the build by default. A build that fails rejects the push, so the branch keeps its old commit. Turn this off in Settings → General or with railyard git:strict my-app off.