Scaling and HA

velixir has two scaling dimensions: vertical (the plan, which sets each replica's CPU and memory) and horizontal (replica count, optionally autoscaled). Plus an optional high-availability mode that keeps warm-standby replicas ready for failover.

Plans

Plans set per-replica resources. Every app picks one at creation, and you can change it any time on the Scaling tab: the new size applies on your next deploy, and billing switches at the next hour.

Plans run from Free (0.25 vCPU, 256 MB) and Hobby (0.5 vCPU, 512 MB) up to Enterprise (8 vCPU, 32 GB). Each replica is guaranteed part of its plan's CPU and can burst to the full amount when the node has room. The full grid is on the Scaling tab and the pricing page.

The Free plan

Free apps cost nothing and sleep after 15 minutes without a request. The next request wakes them after a few seconds' cold start. A team can have one Free app; it runs a single replica, with no autoscaling or high availability. Use Hobby or above for anything that has to stay awake, such as a bot, a worker, or a webhook receiver with a tight timeout.

Port and health checks

Under Scaling → Runtime:

  • HTTP port - where your app listens (PORT, 8080 by default).
  • HTTP health probe - off by default. While it's off, a deploy is marked healthy as soon as the container starts. Turn it on, with a path your app answers (default /health), and pods only get traffic once they respond, so a broken release fails its deploy instead of going live. Leave it off for background workers with no HTTP endpoint.

Both apply on the next deploy.

Autoscaling

On the Scaling tab, set:

  • Min / max replicas - the bounds the autoscaler operates within.
  • CPU threshold - scale up when sustained CPU exceeds this percentage. Required.
  • Memory threshold - optional. When both are set, K8s scales up if either is exceeded.
  • Sustain for / cool-down - how long load must exceed the threshold before scaling up, and how long to wait before scaling down. The defaults (scale up straight away, wait 300s before scaling down) suit most apps.

We use the standard Kubernetes HPA under the hood. Metrics come from metrics-server inside the cluster - the same data that drives the live charts on the Overview tab.

Slots

Every app has a production slot. Standard plans and above allow more (2 slots in total on Standard, 3 on Pro, up to 10 on Enterprise). Each slot has its own replicas and its own deploy history. Use them to:

  • Stage releases - deploy to staging, test it at staging-<your-app>.velixir.run, then swap it live.
  • Run preview environments - a slot per feature branch, paused when you're done with it.

A staging slot runs a single small replica by default (0.1 vCPU, 128 MB). That's enough for a smoke test of a light app; if yours needs more memory to start, give the slot its own plan on the Slots tab. You can pause a staging slot to stop it and its cost. The live slot can't be paused.

Swap slots rolls the staging slot's release onto the live slot, with new pods warmed up before they take traffic, and moves the release that was live to the staging slot. Swap again to go back.

High availability

On the Scaling tab, tick Enable High Availability. We:

  1. Provision warm-standby replicas alongside your primary, spread across separate worker nodes within EU Central.
  2. Wire the edge so traffic fails over automatically if the primary set goes unhealthy. If a worker node dies, another node keeps serving and your app stays up.

The warm-standby plan is configurable separately, so you can run a cheaper plan on the standby if its only job is to absorb traffic during an outage. Standby replicas are billed at their plan's hourly rate for as long as HA is on. They belong to the live slot, which can't be paused, so turning HA off is how you stop them. HA isn't available on the Free plan.

Failover is automatic. You don't need to flip a switch.