> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Suspend and resume machines
> Pause machines to stop billing while preserving data for later
Suspend a machine to stop paying for compute while keeping your data safe. When you suspend a machine, Akua takes a snapshot of the disk, deletes the cloud server (billing stops), and stores the snapshot. Resume creates a new server from the snapshot; your machine comes back with the same hostname, Kubernetes identity, and local data intact.
This page covers machine-level suspend and resume. For cluster-level suspension (pausing the Kubernetes control plane when you have no attached compute), see [Cluster suspension](/clusters#cluster-suspension).
## Cost comparison
| State | 40 GB disk cost (Hetzner) | Notes |
| ------------------------ | ------------------------- | -------------------------------- |
| **Running** (cx23) | \~€4.11/month | Full compute and storage |
| **Suspended** (snapshot) | \~€0.40/month | Storage only (about 90% savings) |
| **Deleted** | €0/month | Data permanently removed |
Suspend is the middle ground between running (expensive) and deleting (permanent data loss).
## How to suspend
1. Go to your cluster's **Machines** tab.
2. Click the menu on the machine you want to suspend.
3. Choose **Suspend machine**.
4. Confirm in the dialog.
Akua then:
1. Gracefully shuts down the server.
2. Creates a snapshot of the full disk.
3. Deletes the cloud server (billing stops).
4. Shows the machine in the **Suspended Machines** section.
The machine shows a **Suspending** status while this process runs (typically 1–3 minutes depending on disk size). Pods running on the machine are terminated during suspend. Stateless workloads reschedule to other nodes; stateful workloads using local storage wait until the machine resumes.
## How to resume
1. Find the machine in the **Suspended Machines** section.
2. Click **Resume**.
Akua then:
1. Creates a new server from the snapshot.
2. Waits for it to boot.
3. Deletes the snapshot (data is now on the new server).
4. The machine rejoins your cluster automatically.
Resume typically takes 1–2 minutes. The machine comes back with the same hostname and Kubernetes node identity.
## What's preserved
| Data type | Preserved | How |
| -------------------------------------- | --------- | ------------------------------------------------------------------ |
| Local storage (local-path-provisioner) | Yes | Disk data is in the snapshot |
| LINSTOR/DRBD volumes | Yes | DRBD replicas on other nodes stay intact and auto-resync on return |
| Kubernetes node identity | Yes | Same hostname from snapshot; kubelet reconnects |
| PersistentVolume bindings | Yes | Node affinity uses hostname label, which matches on resume |
| Running pods | No | Pods are evicted on suspend and rescheduled on resume |
## Provider differences
Different cloud providers handle billing on stopped servers differently. Akua abstracts this: the suspend and resume API is the same regardless of provider.
| Provider | What happens on suspend |
| ----------------------------------------- | -------------------------------------------------------------------------- |
| Hetzner, DigitalOcean, Vultr, Linode, OVH | Snapshot disk and delete server (these providers bill for stopped servers) |
| AWS, GCP, Azure | Stop instance (compute billing stops automatically) |
You don't need to know which approach your provider uses. Akua picks the right strategy.
## Public IP changes on resume
On Hetzner and other snapshot-delete providers, your machine gets a new public IP address every time it resumes. This happens because Akua deletes the cloud server to stop billing and provisions a brand-new server from the snapshot on resume. The Machine ID stays the same, but the underlying cloud resource is recycled.
Providers with a true stop state (AWS, GCP, Azure) do not have this limitation. Their instances retain the same IP across stop and start cycles.
The machine's `provider_resource.identity_kind` field reflects this: `recyclable` for providers where the cloud resource is replaced on suspend, `persistent` for providers where it is merely stopped. See [Machines: provider resource identity](/compute/machines#provider-resource-identity) for field details.
### Providers affected
| Behavior | Providers |
| ------------------------------------------ | ----------------------------------------- |
| IP changes on resume (snapshot and delete) | Hetzner, DigitalOcean, Vultr, Linode, OVH |
| IP stable across stop and start | AWS, GCP, Azure |
### If you need a stable public IP
Three approaches, in order of simplicity:
1. **Floating IP (Hetzner)**: attach a Hetzner Floating IP to your machine. This is a static IPv4/IPv6 address you own independently of any server. After each resume, re-attach the Floating IP to the new server in the [Hetzner Cloud Console](https://console.hetzner.cloud/). Automated re-attachment is planned but not yet implemented in Akua. A Floating IP costs \~€3.81/month when not attached to a running server; it is free while attached.
2. **Short-TTL DNS**: point a DNS record at your machine's current public IP with a TTL of 60 seconds or less. After resume, update the DNS record. Services that support dynamic DNS (such as deSEC or Cloudflare) can automate this with a lightweight script.
3. **Load balancer**: place a load balancer in front of the machine. The load balancer has a stable IP; backends can change freely. This is the most robust option if you need zero-downtime failover.
### What is not affected
* **Local storage and LINSTOR volumes**: disk data is captured in the snapshot and restored intact.
* **Kubernetes ClusterIP and service IPs**: these are internal addresses assigned by the Kubernetes control plane. They are unaffected by the node's public IP changing.
* **Machine ID and hostname**: the Akua Machine ID and the Kubernetes node hostname remain constant. Kubernetes recognizes the resumed node as the same node and rebinds volumes automatically.
## Auto-suspend on subscription downgrade
When your Pro subscription ends, Akua automatically suspends all platform-managed machines instead of deleting them:
1. Subscription ends: machines are suspended.
2. Snapshots are kept for **90 days**.
3. Re-subscribe: your dashboard shows suspended machines with a **Resume** button.
4. After 90 days: snapshots are permanently deleted.
BYOM machines are not affected by subscription changes. They stay running because you pay the cloud provider directly.
## Snapshot retention
Suspended machine snapshots are kept for 90 days. After that, they are permanently deleted. The dashboard shows the expiration date for each suspended machine.
To permanently delete a suspension early (and its snapshot), click the trash icon next to the suspended machine. This is irreversible.
## API
Manage machine suspension programmatically.
Suspend, resume, and list suspension events for machines.
Set up API tokens for programmatic access.
## Related topics
Full machine lifecycle including provisioning and deletion.
Pause the Kubernetes control plane when you have no attached compute.
Hetzner-specific billing model and snapshot pricing.
Understand what happens to machines when your plan changes.