Compute

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.

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

uv run lazycloud compute status
uv run lazycloud compute instances
uv run lazycloud compute workloads

Resources and options covers sizing and GPUs.

Your own AWS account

On the Business plan, one AWS account can back your workspaces. LazyCloud runs its fleet there exactly as it runs its own: the same instance types, regions, warm hosts and stopped reserves, launched when work arrives and shut down when idle. The instances, containers, and an S3 bucket per workspace holding its volumes and disks all live in your account. AWS bills the machines and the bucket, and LazyCloud charges a management fee based on compute rates. Connect from the dashboard under Settings, then Compute, with Connect AWS. Or from the CLI:

uv run lazycloud cloud connect aws --account-id 123456789012
uv run lazycloud cloud status --watch --until ready

Either way you get an AWS Console link that opens a CloudFormation stack ready to create. The stack makes the management role, which LazyCloud uses to set up a network in each region it runs in. After a look at what it creates, tick the IAM acknowledgement and choose Create stack. You don’t need the AWS CLI, and LazyCloud never sees your AWS keys. The connection turns ready on its own once the stack finishes. If it stalls, the stack’s events in AWS show why. LazyCloud picks instance types, regions, and warm capacity. Each workload still sets its own CPU, memory, and GPU. While no workspace uses the account, nothing runs there. cloud status reports a broken authorization, for example after a role change. cloud reconnect starts a replacement. Deleting a workspace empties and deletes its bucket. Disconnecting needs every workspace in the account deleted first. LazyCloud then terminates its instances, deletes the networks it made and the stacks it asked you to create, and removes the connection. If a step can’t finish, for example a stack AWS refuses to delete, the connection shows Action required. Retry once the cause is fixed, or forget the connection. Forgetting removes it at once and lists what stayed in AWS, each with a Console link, for you to delete.

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 25 or later on the system containerd, and outbound DNS and TCP 443. No inbound port or static IP. Joining installs lazycloud-snapshotter, which serves image layers as containers read them. It switches Docker to the containerd image store with the snapshotter as its storage driver and restarts Docker, so containers you run there stop. Images you pulled under overlay2 stay hidden until you switch back. To revert, remove storage-driver and features.containerd-snapshotter from /etc/docker/daemon.json and the proxy_plugins.lazycloud block from /etc/containerd/config.toml, restart containerd and Docker, then systemctl disable --now lazycloud-snapshotter. On the machine:

uv run lazycloud machine join --name gpu-1 --workspaces research,staging --gpu h100 --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.

from lazycloud import GpuType


@app.function(gpu=GpuType.H100, 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.

Getting started

Core concepts

CLI reference

Examples

Account

Where a workload runs

Check usage

Your own AWS account

Your own machines

Machine phases