> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lazycloud.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Compute

> Where workloads run: LazyCloud compute, your own AWS account, or machines you join.

## Where a workload runs

The workspace decides. Its location is fixed when it is created, either
LazyCloud's compute or a connected AWS account, and its workloads and volumes
live there. Moving work means a new workspace in the other location and a copy
of the data.

```bash theme={null}
uv run lazycloud workspace create research             # runs on LazyCloud
uv run lazycloud workspace create research --cloud aws  # runs in your AWS account
```

`workspace create` needs administrator access and selects the new workspace.

The exception is a machine you joined. A workload with `machine="gpu-1"` runs
only there, and fails rather than running elsewhere when that machine is
offline or doesn't serve its workspace.

## Check usage

```bash theme={null}
uv run lazycloud compute status
uv run lazycloud compute instances
uv run lazycloud compute workloads
```

[Resources and options](/concepts/resources) covers sizing and GPUs.

## Your own AWS account

On the Business plan, one AWS account can back your workspaces. LazyCloud
launches instances there when work arrives and shuts them down when idle. The
instances, containers, and the bucket holding the workspace's volumes all live
in your account. AWS bills the machines, and LazyCloud charges a management
fee based on compute rates.

```bash theme={null}
uv run lazycloud cloud connect aws --account-id 123456789012
uv run lazycloud cloud authorize --profile YOUR_AWS_PROFILE
uv run lazycloud cloud validate
uv run lazycloud cloud status
```

`authorize` submits a CloudFormation stack that creates the management role and
network, and your AWS credentials never leave your machine. If it stalls, the
stack's events in AWS show why. `validate` checks the result once the stack
finishes. The dashboard shows the connection under Settings, then Compute.

LazyCloud picks instance types, regions, and warm capacity. Each workload still
sets its own CPU, memory, and GPU.

`cloud status` reports a broken authorization, for example after a role change.
`cloud reconnect` starts a replacement, and `cloud disconnect --wait` drains and
removes the connection once no workspace lives in the account.

## Your own machines

Any Linux server you own can join your account and run workloads for the
workspaces you choose, with no compute charge. Volumes and egress still bill.

The host needs Linux on amd64 or arm64 with systemd and root access, a rootful
Docker daemon, and outbound DNS and TCP 443. No inbound port or static IP.

On the machine:

```bash theme={null}
uv run lazycloud machine join --name gpu-1 --workspaces research,staging --gpu a100-80 --max-gpus 4
```

The name is unique in your account and is what workloads pin to. Only the
listed workspaces can use the machine, and `machine update` changes the list.
`--background` installs the agent as a service instead of running it in the
terminal. The dashboard has the same flow under Settings, then Compute.

```python theme={null}
from lazycloud import GpuType


@app.function(gpu=GpuType.A100_80, machine="gpu-1")
def train() -> None:
    ...
```

A deployment stays on its machine. If the machine leaves, the deployment waits
until one joins under that name again and you redeploy. Runs and sandboxes fail
at once while the machine is gone. `uv run lazycloud machine remove <id>`
retires a machine and stops any agent still running on it.

## Machine phases

`compute instances`, `machine list`, and the dashboard's Compute panels show
each machine's phase:

| Phase          | Meaning                                                            |
| -------------- | ------------------------------------------------------------------ |
| `requested`    | Asked for, nothing has reported yet.                               |
| `provisioning` | The provider reports it running, the agent hasn't.                 |
| `booting`      | Installing the agent.                                              |
| `joining`      | Enrolled, waiting for the first heartbeat.                         |
| `ready`        | Taking workloads.                                                  |
| `draining`     | No new work, running work finishes.                                |
| `terminating`  | Shutdown requested.                                                |
| `deleted`      | Gone. Leaves the list.                                             |
| `failed`       | Never became ready, or stopped serving. The chip names the reason. |

A `ready` machine that stops sending heartbeats shows an offline badge with how
long it has been quiet.