Stop and start a cluster
Stop cluster and Start cluster are in the Danger Zone of the cluster’s Settings → General, and in the cluster’s ⋯ menu on the clusters list and the cluster overview. Stop is offered while the cluster is running and Start while it is stopped. Both open a dialog where you type the cluster name to confirm.What a stop does
It depends on the provider:
The state snapshot. On the terminating providers Ankra first captures an encrypted etcd snapshot, for k3s and kubeadm clusters, and stores it in your backup vault, or in an Ankra-managed default vault when you have registered none. The virtual machines are terminated only once the snapshot is stored. The capture runs as a Cluster State Snapshot operation; if it fails, the cluster stays running and nothing is torn down.
Preserve cluster state (recommended) is ticked in the dialog. Untick it (CLI
--preserve-state=false) to tear down without a snapshot: Secrets, ConfigMaps, custom resources and the bindings between claims and volumes are then lost, and only what Ankra deploys from its own configuration comes back. A forced stop (CLI --force) never captures.
Pause instead of tearing down. On k3s clusters on Hetzner, UpCloud and DigitalOcean, choose Pause instead of Tear down (default) (CLI --mode pause). The servers are powered off and kept with their disks, so etcd, local data and node identities survive, and a start powers them back on. The trade-off is cost: these providers bill a powered-off server in full, so a pause saves no compute cost. Pause takes no snapshot and cannot be combined with --force.
A stop never deletes the cloud block volumes behind PersistentVolumes, forced or not; they keep billing while the cluster is stopped. Only terminating the cluster deletes them - see Persistent volumes.
What a start does
Start cluster re-provisions the saved topology: Everything (control plane and workers) or Control plane only. Ankra creates fresh virtual machines with new IPs and installs Kubernetes. When a snapshot was captured, Restore the cluster state captured at stop is ticked: the first control plane resets etcd from it, so your Secrets, ConfigMaps, custom resources and persistent volume claims come back, and StatefulSets reattach their existing cloud disks. A kubeadm control plane also gets its certificate authorities back, so existing tokens and kubeconfigs stay valid. Untick it (CLI--restore-state=false) to start a fresh cluster.
Stacks and add-ons configured in Ankra are reconciled either way. A snapshot that was never restored is kept for 90 days; a restored one is kept for 7 more days.
On Scaleway and AWS EC2, and after a pause, a start powers the existing servers back on - see AWS clusters.
From the CLI
Stop and start are per-provider commands:ovh, upcloud, digitalocean, scaleway, aws, proxmox and morpheus. See the CLI reference.
Schedule stops and starts
Park a cluster overnight
The Power schedules card on Settings → General has a Park overnight button. Choose the days (Weekdays (Mon-Fri) or Every day), the Stop at and Start at times (19:00 and 07:00 by default), the timezone and what happens When stopping, then Create schedules. It creates one stop schedule and one start schedule.Add a schedule
1
Open the dialog
On the Power schedules card, click Add schedule.
2
Choose the action
Pick Stop or Start. Each schedule does one thing; create a pair to stop and start the cluster.
3
Choose what a stop does
For a stop, pick under When stopping:
- Delete resources - deletes the cloud instances, as a manual stop does. On the providers that capture state, keep Preserve cluster state (recommended) ticked so the next start restores it.
- Scale down to 0 - deletes only the worker servers and creates new ones at the next start. The control plane and etcd, cloud volumes and addresses are kept and keep billing. Data on the workers’ own disks is lost at every stop, so if the cluster has volumes that keep data there (local-path, hostPath, local PVs) you must tick the acknowledgement.
- Pause - k3s on Hetzner, UpCloud and DigitalOcean only. Powers the servers off and keeps them; they keep billing.
4
Choose when
Under Schedule type, choose One-off and set Run at, or Repeated and pick a Cadence: Every day, Weekdays (Mon-Fri), Weekends (Sat-Sun) with a Time, or Custom cron with a 5-field cron expression. Repeated schedules run in the Timezone you pick, which defaults to your browser’s.
5
Save
Leave Schedule enabled on and click Add schedule. The card shows the next run.
0 19 * * 1-5 in Europe/Stockholm fires at 19:00 Stockholm time, Monday to Friday.
Read the schedule list
Each row shows the action, its next run, when it last fired and the outcome of the last run, with a toggle, Edit and Delete:How schedules run
- A scheduled stop behaves like Stop cluster, with the mode and state choice the schedule carries.
- A stop is skipped if the cluster is already stopped or being deprovisioned. A start fires only when the cluster is stopped.
- If the cluster is busy or the action fails transiently, the schedule retries every 5 minutes for up to 24 hours, then records
failed. A repeated schedule still fires at its next occurrence. - Turning off the toggle keeps the schedule but it never fires; turning it on again arms it for its next occurrence. Disabling or editing a schedule always wins over a retry in flight.
Manage schedules from the CLI
ankra cluster power-schedules works on the active cluster (ankra cluster select):
update replaces the schedule’s action, timing and enabled flag, so restate them; omitting --stop-mode or --preserve-state keeps the current choice. A scale_to_zero stop on a cluster with node-local volumes needs --accept-node-local-data-loss when you are not answering the prompt. See the CLI reference.
Next steps
- Cloud Cost - see what your clusters cost and what parking them saves.
- Cluster Settings - the rest of the cluster’s lifecycle, including terminating it.