Once an app is running, its dashboard is where you watch and change it. The control plane keeps the app converged to the spec you set, and the dashboard is the window onto that — plus the controls to change the spec.
Read the dashboard
- Status pill —
provisioning→active, orsuspended/deleting. - Topology — the same diagram from the create flow, now drawn from your app’s desired spec, with each node carrying its per-node size (CPU/RAM/volume/region) and its live power state. It’s the desired and the observed, folded into one picture.
- Observed — the actual Fly resources behind it: machines, their power state, worker counts, and volumes, refreshed by the control plane’s reconcile and drift sweep.
- Connect — the endpoints and daemon token to wire your app up.
- Plan — the authoritative monthly price for the current shape.
Resize
The Scale form changes your spec; submitting it appends a new desired version and the control plane reconciles your app toward it (a clean stop → re-size → start, so subscriptions reconnect and resync).
- Compute — pick a new CPU kind, vCPU count, and RAM. vCPU count drives the daemon’s IVM worker threads, and RAM holds your live and pinned materializations — the provisioning axes that actually move the engine. Any combination snaps to the nearest available machine size.
- Volume — grows online and never shrinks (the floor is your current size).
- Read followers — every app gets a follower-count picker and a separate follower size, so you scale the write master and the read fleet independently.
- Follower regions — choose a Fly region for every follower. Adding followers in new regions keeps the same app, backup lineage, public endpoint, and affinity flow.
Scale from one follower to a regional fleet
New Rindle Cloud apps always start with a separate replicator and follower, so growing from 1→N followers is an ordinary scale operation. New followers restore from the replicator’s existing canonical backup and then tail the live stream; the write master and app endpoints do not change.
Changing an existing follower’s region replaces that follower and its attached Volume, because Fly Volumes cannot move between regions. The control plane removes that follower, recreates it in the selected region, and restores it from the same lineage. Keep another follower live when re-regioning if reads must remain uninterrupted.
Suspend & reactivate
If a payment fails, an app is suspended: its machines are scaled down, but your data — the volumes — is left intact. The dashboard shows a reactivate control; reactivating re-charges the current shape (a downsize while suspended lowers it) and re-provisions the machines against the surviving volumes. It’s the “pay your way back” path — nothing is destroyed by a suspension.
Billing
Billing is usage-based, not a fixed up-front plan. The create and resize forms show the authoritative monthly figure for the shape you choose — compute plus storage — and that’s the figure your dashboard’s Plan line reflects. Egress and object-storage usage that an up-front price can’t predict are billed separately. A resize re-prices before the shape change is applied, so the bill always matches the running spec.
If you’d rather run it yourself, every provisionable profile is also available self-hosted under one flat company license — sized by your team, not by usage or cores — the same engine and the same contract, operated by you instead of for you.
Next steps
- Connect your app — point your API server and frontend at the app.
- The deployment menu — every profile and what each one is for.
- Run the daemon — what Rindle Cloud operates on your behalf.
- Is Rindle for you? — where the single-ordering-master model fits.