# Computer lifecycle states

> Computer states, allowed transitions, and what persists

> Nevia is in beta and open to selected teams. Public launch in Dec 2026. The CLI installs with `curl -fsSL https://get.nevia.cloud | sh`, and the MCP server is at https://api.nevia.cloud/mcp. A person signs in once in the browser.
> Setup, sign-in and requesting access: [SKILL.md](https://nevia.cloud/SKILL.md). When Nevia fits and when it doesn't: [why.md](https://nevia.cloud/why.md).

> For the complete documentation index, see [llms.txt](https://nevia.cloud/llms.txt). This page's HTML version: https://nevia.cloud/docs/reference/computer-lifecycle

This page describes the current computer lifecycle. For commands, see
[Sleep and wake a computer](https://nevia.cloud/docs/computers/lifecycle.md).

## States

`state` describes the computer now. `pending` names the state a transition is driving
toward; `null` means no transition is pending.
[`nevia status`](https://nevia.cloud/docs/reference/cli/status.md) shows a pending target with an arrow,
such as `ready (→ sleeping)`.

| State      | Meaning                                                                  | Run a command | Create a checkpoint |
| ---------- | ------------------------------------------------------------------------ | ------------- | ------------------- |
| `creating` | Provisioning or restoring the computer.                                  | No            | No                  |
| `ready`    | The microVM is running.                                                  | Yes           | Yes                 |
| `sleeping` | The microVM is paused in memory; RAM remains allocated.                  | No            | Yes                 |
| `failed`   | The computer failed to start or complete a transition. Read its `error`. | No            | No                  |
| `deleting` | Deletion is in progress.                                                 | No            | No                  |
| `deleted`  | Deletion is complete; the computer is no longer available.               | No            | No                  |

Exec and checkpoint creation require `pending: null` and an existing microVM.
Checkpoint creation also requires snapshot support and no operation running on the
source computer. Reading status or logs does not wake a sleeping computer. Logs are
available while `ready` or `sleeping`.

## Transitions

Sleep, wake and branch require `pending: null` and no operation running on the
computer. Wait for a pending transition or a reported operation to finish before
retrying.

| Action               | Required starting state                         | While in progress                            | Result                                                                |
| -------------------- | ----------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------- |
| Create               | No existing computer.                           | `creating`, pending `ready`                  | New computer becomes `ready`.                                         |
| Sleep                | `ready`                                         | `ready`, pending `sleeping`                  | Same computer becomes `sleeping`.                                     |
| Wake                 | `sleeping`                                      | `sleeping`, pending `ready`                  | Same computer becomes `ready`.                                        |
| Branch               | Source is `ready` or `sleeping`.                | New computer is `creating`, pending `ready`. | New computer becomes `ready`; source keeps its state.                 |
| Restore a checkpoint | Checkpoint is `ready`.                          | New computer is `creating`, pending `ready`. | New computer becomes `ready`; source keeps its state.                 |
| Delete               | A live computer, subject to the blockers below. | `deleting`, pending `deleted`                | Computer and its data are removed.                                    |
| Restart              | Unsupported.                                    | No transition.                               | The API returns `422 not_supported`; there is no CLI restart command. |

These results describe successful transitions. A failed transition can leave the
computer in `failed`.

Sleep on an idle `sleeping` computer and wake on an idle `ready` computer return the
computer unchanged. Sleep and wake can finish within the request. If they need more
time, the response includes an operation and a pending target. The CLI's `--wait`
follows that operation.

Deletion requires protection to be off and no operation running on the computer.
A checkpoint in use by another live computer also blocks deletion of its source;
delete the dependent computers first.

## Persistence

Provisioning attaches a persistent disk at `/data` only when the deployment configures
a storage pool. A directory named `/data` alone does not imply a persistent disk.
Commands run as the `nevia` user and start in its home directory, which lives on that
disk; write there. The `/data` mount point itself is not writable.
Sleep calls Ember `Machines/Pause`; wake calls `Machines/Resume`. Pausing keeps RAM
allocated and does not require an attached data disk or snapshot support. It does
not create a durable restore point; use a checkpoint when you need one.

The writable root filesystem uses memory. Saving memory preserves those filesystem
changes along with the workload's memory.

| Action                            | Memory and writable root filesystem                                          | Persistent disk, when attached            |
| --------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------- |
| Sleep, then wake                  | Retained in RAM while paused and resumed at wake.                            | Kept.                                     |
| Create and restore a checkpoint   | Captured in the checkpoint and restored into a new computer.                 | Private copy of the captured data.        |
| Branch a `ready` computer         | The branch boots from the image with fresh memory and a fresh writable root. | Private copy of the source's data.        |
| Branch a computer paused by sleep | The branch boots from the image with fresh memory and a fresh writable root. | Private copy of the paused source's data. |
| Delete                            | Removed.                                                                     | Removed.                                  |

Older machines suspended to disk by `Machines/Suspend` also appear as `sleeping`.
Wake restores their suspension snapshot; branching one restores its saved memory
and paired disks. The current CLI `suspend` command pauses in memory instead.

A branch of a running computer can reuse a disk snapshot less than five seconds
old. To include writes you just made, finish and flush them, then wait at least
five seconds before branching.

Sleep and wake keep the computer's identity, `url`, image, environment, size and
ports. A branch or checkpoint restore creates a new computer with its own identity
and `url`; it keeps the source's ports but not its running programs. Writes to its
copied data do not change the source.

A sleeping computer keeps its `url` and does not answer on it. Ports change only while
the computer is ready. See [Computer ports and URLs](https://nevia.cloud/docs/reference/computer-ports-and-urls.md)
for the URL and port rules.

## Exec and checkpoints

Sleep, deletion and checkpoint capture end active exec sessions; waking does not
reconnect them.

Checkpoint capture briefly pauses a running source, then resumes it; a sleeping
source stays asleep. Only `crash` consistency is supported.

See [Run a command](https://nevia.cloud/docs/computers/exec.md),
[Create and restore checkpoints](https://nevia.cloud/docs/computers/checkpoints.md), and
[Branch a computer](https://nevia.cloud/docs/computers/branch.md) for the procedures.