Resize and scale

An Egg is sized on a sliding scale, not picked from a fixed menu of plans. You choose how many vCPUs and how much memory the Egg gets, and you scale the two independently. A background worker that needs plenty of CPU but little memory, and an in-memory cache that needs the opposite, are both a natural fit. The resizer is a Resize button in the Egg's action row that opens a slider panel.

What it costs

Pricing is a flat sliding scale: £12 per vCPU per month plus £6 per GB of memory per month. There is no plan fee on top. A database Egg (Postgres, Redis) also carries a persistent volume, billed at £0.50 per GB of disk per month on top of its compute. As you drag the sliders, the monthly price updates live so you can see the new figure before you commit. Egress is unmetered on every size, so scaling up never adds a bandwidth bill.

2 vCPU x £12 = £24
4 GB   x £6  = £24
---------------------
Total        £48 / month

Resize an Egg

1. Open the Egg in the dashboard and choose Resize in the action row to open the slider panel.
2. Drag the vCPU and memory sliders to the new figures. On a database Egg there is also a Storage slider to grow the disk. The monthly price updates live as you move them.
3. Review the new price, then choose Apply resize.
4. Ruust recreates the container at the new size. Watch the Egg return to hatched.

A web Egg rolls with no downtime: a fresh container starts and takes over before the old one drains. A database Egg has to bounce instead (it stops the old container before starting the new one, a brief pause), because its data lives on a single host-local volume that two containers cannot share. Either way the Egg keeps its data and its configuration.

If the current host has room for the new size, the resize happens in place. If the host cannot fit the larger size, a web Egg simply re-places onto another host in the same region. A database Egg cannot just move (its data is on a host-local volume), so Ruust migrates it: it snapshots the data, restores it on a roomier host in the same region, verifies it, then cuts over, applying the new size as it lands. An Egg never leaves its region, so a resize never crosses from London (eu-west) to Virginia (us-east).

Growing a database Egg's disk

A database Egg's disk is grow-only: the Storage slider starts at the current size and only goes up, because shrinking a live volume would throw away data that no longer fits. Growing it reserves more room (billed from the new size) and is hard-enforced as a per-volume quota on hosts whose filesystem supports it. To reduce a database Egg's disk, create a smaller Egg and import into it.

Environment variables

Resizing does not touch your environment variables. They stay set on the Egg and are re-applied to the recreated container, available at both build and run time, encrypted at rest and never printed in logs. You do not need to redeploy to resize, and you do not lose any configuration by doing so.

Replicas

Alongside size, you can run more than one copy of an Egg. Set the replica count and Ruust runs that many identical containers behind the Egg URL, spreading requests across them. The count is a fixed number that you set by hand. There is no autoscaling: Ruust will not add or remove replicas for you in response to load. Each replica is billed at the Egg size, so two replicas of a £48 Egg cost £96.

No cold starts

An Egg is a long-running server that is always on, so resizing and scaling do not introduce cold starts. Server-side rendering, background work and websockets keep working straight after a resize. The only pause is the brief blip whilst the container is recreated, and requests resume as soon as the Egg is hatched again.