# Limits and concurrency

> Job duration limits, concurrency, architecture support, disk sizes, and custom runner configuration limits per plan.

Source: https://latchkey.dev/documentation/runner-limits

## Summary

- Max job duration 4 hours; 20 concurrent busy runners per workspace by default.
- Linux x86_64 only: no Windows, macOS, arm64, or GPU host runners today.
- Runners are single-use; persist outputs with artifacts and caches.

## The numbers

| Limit | Value |
| --- | --- |
| Maximum job duration | 4 hours per runner; the machine is terminated at 4 hours even if the job is still running |
| Concurrent jobs | 20 busy runners per workspace by default (idle warm runners do not count); higher limits available |
| Operating system | Ubuntu 24.04 LTS only (no Windows or macOS runners) |
| Architecture | x86_64 (amd64) only; no arm64 host runners (arm images can be cross-built with docker buildx) |
| Disk | 100 GB (small, medium, large), 200 GB (xlarge), 100 to 500 GB for custom configurations |
| Custom runner configurations | Developer and Launch: 2, Scale: 10, Enterprise: unlimited |
| Region | Runners run in AWS us-east-1 |

## What to do when you hit one

The numbers only matter on the day one of them bites. What to change on your side when that happens:

- **A job approaches 4 hours** The machine terminates at 4 hours even mid-job, so treat the cap as a hard ceiling, not a budget. Split the work into parallel jobs (each gets its own runner), or move it up a size so the same work finishes sooner.
- **Jobs queue at busy moments** The default is 20 busy runners per workspace, and idle warm runners never count against it. Jobs beyond the limit wait in the queue until a busy runner finishes; if your peaks queue regularly, higher limits are available.
- **You need Windows, macOS, or arm64** Keep those specific jobs on GitHub-hosted or other runners and mix freely within the same workflow. For arm64 container images, cross-build with docker buildx; QEMU is preconfigured on the image.
- **Jobs fill the disk** Self-healing prunes caches when a disk fills mid-job, but if a job routinely needs more space than its size provides, the durable fix is a custom configuration with up to 500 GB.

Two of these deserve a why. The 4-hour cap is the same backstop that keeps [self-healing](/documentation/self-healing) retries from ever running up your bill: it guarantees that a hung job cannot hold a machine, or your invoice, indefinitely. And the concurrency limit counts **busy** runners only, which is easy to misread: a warm pool sitting idle costs you none of the 20 slots, so warm capacity never competes with your real jobs.

## Custom runner configurations

From the **Runners** page, you can create custom configurations with their own `latchkey-<name>` labels, choosing CPU/memory shape and disk size. The **AI Scan** flow analyzes your workflows and proposes the right configuration; its image is then built automatically and you are notified when the runner is ready to use. Until the image build completes, jobs targeting that label wait in the queue.

The full decision guide, including when a custom shape beats a preset and what it costs, is in [Custom runners with AI Scan](/documentation/custom-runners).

## Good to know

- Runners are single-use: one job per machine, destroyed afterward. Anything you write to local disk is gone when the job ends; use artifacts or caches for persistence.
- GitHub-hosted runner labels (`ubuntu-latest` and friends) keep working side by side; you can migrate one job at a time.
- If you need GPU, Windows, macOS, or arm64 hosts, keep those specific jobs on GitHub-hosted or other runners for now and mix freely within the same workflow.

### What is the maximum job duration on a Latchkey runner?

Four hours. A job that needs longer should be split across jobs that hand work to each other through artifacts, because a single job approaching the limit is usually doing work that could run in parallel.

### How many jobs can I run at once?

Twenty concurrent busy runners per workspace by default. If you regularly queue behind that ceiling, the limit is raisable; the dashboard shows concurrent usage so you can tell queueing from slowness.

### Do Latchkey runners support Windows, macOS or ARM?

Not today. Latchkey runners are Linux x86_64 only, with no Windows, macOS, arm64 or GPU hosts. Those jobs can stay on GitHub-hosted or other runners and mix freely inside the same workflow, so this does not block adoption for the rest of your pipeline.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt