Skip to main content

​
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.
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

Resources and options 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.
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:
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.
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: A ready machine that stops sending heartbeats shows an offline badge with how long it has been quiet.