Autoscaling and failover

Autoscaling

App → Settings → General → Autoscaling. Set a minimum and a maximum number of web replicas; Railyard adds or removes replicas between them based on CPU and p95 response time.

• Target CPU / replica (%) and the p95 target decide when to scale up.
• Replicas share the app’s server, so this helps with CPU-bound or slow-request load, not a full server. It never scales up while the server’s memory is high.
• Leave Max blank to run a fixed number of replicas (no reactive scaling).

API: PATCH /api/applications/:id/autoscale with min, max, cpu, p95_ms.

Scheduled windows

Scheduled windows raise the floor ahead of a known peak, one per line: mon,tue,wed,thu,fri 08:00-18:00 3 (days, start-end, minimum replicas, in the app’s time zone). They only pre-warm while Max is set — the usual CPU/p95 rules still decide the rest, and they just raise the minimum during the window. Dashboard only; not in the API or CLI yet.

Failover

On an app’s Servers tab, add an extra server and tick Fail over automatically: traffic is split across every online server, and if the primary stops answering for a few minutes an extra server becomes primary and the app redeploys there. Railyard prefers an extra server in a different region over one in the same region.

If the server also held the app’s data, Railyard promotes a live standby (see Database servers) and points the app at it as part of failing over. Every domain the app owns is pointed at the new server right away, not just on the next deploy; a custom domain’s own DNS still needs to follow if it isn’t on Railyard’s managed DNS. You’re notified when it happens.

Dashboard only; not in the API or CLI yet.