Canary-Deploys und Deploy-Fenster

Das sind die Stellschrauben dafür, wann und wie ein Release live geht. Alle findest du auf der App-Seite und in der API; die meisten auch in der CLI.

Canary-Deploys

Ein Standard-Deploy leitet den gesamten Traffic auf das neue Release um, sobald es seinen Readiness-Check besteht. Ein Canary-Deploy lässt das neue Release neben dem aktuellen laufen und schickt ihm zunächst nur einen Teil des Traffics.

Aktivieren: App → Settings → General → Deploy strategy. Wähle Canary und stelle ein:

• Canary share (%): 1–99. Dieser Anteil neuer Besucher erhält das neue Release. Ein Cookie hält jeden Besucher für einen Tag auf der Version, die er zuerst bekommen hat.
• Ramp steps (%): eine optionale aufsteigende Liste, z. B. 5, 25, 50. Jeder Schritt läuft als eigener Canary mit dem gleichen automatischen Rollback unten; sobald der letzte Schritt besteht, schickt Promote ihn auf 100%. Leer lassen für einen einzigen Schritt, den du dann manuell promotest.
• Dwell per step (minutes): leer lassen, um jeden Schritt manuell zu promoten. Sonst geht Railyard nach dieser Anzahl Minuten von selbst zum nächsten Schritt über bzw. promotet den letzten.
• Roll back above 5xx rate (%): steigt die Fehlerrate eines Schritts über diesen Wert, macht Railyard ihn zurück.

Während ein Canary läuft, zeigt die App-Seite ein Banner. Die Deploy-Seite vergleicht die Requests, die 5xx-Rate und die p95-Latenz des Canarys mit dem Rest der App und bietet Promote (schickt 100% an das neue Release oder startet den nächsten Ramp-Schritt) und Roll back.

Wissenswertes:

• Der Release-Befehl, etwa deine Migrationen, läuft bevor der Canary startet — Migrationen müssen also mit beiden Versionen funktionieren.
• Worker und zusätzliche Server bleiben bis zum Promote auf dem aktuellen Release.
• Der erste Deploy einer App, ein Deploy während des Maintenance-Modus, eine reine Worker-App und eine App mit Datenvolume nutzen immer einen Standard-Deploy.

API: PATCH /api/applications/:id/deploy_strategy (deploy_strategy, canary_percent, canary_steps_text — kommagetrennt, z. B. "5, 25, 50" — canary_promote_after_minutes, canary_max_error_rate), dann POST /api/deploys/:id/canary/promote oder DELETE /api/deploys/:id/canary. Für Canarys gibt es noch keinen CLI-Befehl.

Deploy-Fenster

Ein Deploy-Fenster legt die Tage, Stunden und die Zeitzone fest, in denen eine App deployen darf. Einstellbar unter Settings → General → Deploy window.

• Pushes und Auto-Deploys außerhalb des Fensters warten und gehen als ein einziger Deploy raus, sobald das Fenster öffnet.
• Ein manueller Deploy außerhalb des Fensters fragt erst nach, du kannst aber trotzdem deployen.
• Ein Rollback außerhalb des Fensters deployt trotzdem, mit einer Warnung auf der Bestätigungsseite.
• Ein Fenster, das endet bevor es beginnt, läuft über Nacht (22:00–02:00). Alle Tage abwählen erlaubt Deploys zu jeder Zeit.

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 mit days, start, end und time_zone. "days": [] entfernt das Fenster.

Geplante Deploys

Wähle einen Zeitpunkt, und der Deploy startet dann. Der Zeitpunkt muss innerhalb des Deploy-Fensters liegen, falls die App eines hat. Du kannst einen geplanten, wartenden oder laufenden Deploy abbrechen.

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

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

Deploy-Notizen

Füge einem manuellen Deploy oder einem Rollback eine Notiz von bis zu 500 Zeichen hinzu. Sie erscheint in den Deploy-Listen, auf der Deploy-Seite, im Aktivitätsprotokoll, in Benachrichtigungen und in deploy.*-Webhooks. Ein wiederholter Deploy behält seine Notiz.

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

Rollbacks bringen die Variablen zurück

Ein Rollback deployt den Commit dieses Releases erneut und setzt die Variablen zurück, mit denen es lief. Die Bestätigungsseite listet die zurückgesetzten Variablen auf und warnt, falls sich ein Secret seitdem geändert hat. Um nur den Code zurückzurollen und die heutigen Variablen zu behalten:

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

Releases, die deployt wurden bevor Railyard eine Kopie ihrer Variablen aufbewahrte, können nur ihren Code zurückrollen.

Einen Branch, Tag oder Commit einmalig deployen

Deploy options… auf der App-Seite, railyard deploy my-app --ref v2.1.0, oder ref in der API deployt einmalig einen anderen Branch, Tag oder Commit. Der Branch, dem die App folgt, ändert sich dabei nicht.

Strikte Git-Pushes

Bei git push railyard main (siehe CLI) wartet ein Push standardmäßig auf den Build. Ein fehlgeschlagener Build lehnt den Push ab, sodass der Branch auf seinem alten Commit bleibt. Abschaltbar unter Settings → General oder mit railyard git:strict my-app off.