DevKit
backend_type: devkit. Connection: none. Status: production for laptop coding (and a hosted-broker variant).
A DevKit group is still a runner group in the control plane. There is no cloud connection and no row in data.runner.list-provider-config-specs — the spec catalog only covers provider-backed kinds. Capacity is the ltinteg-devkit runner serve process (on a laptop, or a hosted image that speaks the same protocol).
When to choose it
- Provider-blind coding agents: the child never receives git credentials.
- Attended development on a mapped local repo (
repository_uuid→ path). - You are not ready to (or must not) put coding compute in a cloud account.
Do not use a Fargate / Kubernetes GitHub Actions group as a substitute. The eligibility gate requires purpose=agent, and the coding broker protocol is DevKit-specific.
How it registers
ltinteg-devkit runner repositories add <repository-uuid> /absolute/path/to/repo \
--allowed-root /absolute/root/containing/repos
ltinteg-devkit runner serve --group <runner-group-uuid>
The process proves your API-token organization, heartbeats a RunnerInstance with backend_type=devkit, and claims opaque assignments. Full CLI: Local coding runner.
Config
No provider config keys. Concurrency and allowed roots live in the DevKit client config (runner_max_concurrency, runner_allowed_roots), not in runner_group.config.
Purposes
Almost always purpose=agent and integration_type=none. A DevKit group is not a GitHub Actions pool.
Hosted vs laptop
The same kind covers a laptop broker and a hosted DevKit/agent image. Hosted images add sandboxing and digest-pinned environments; they are still backend_type=devkit (or a Kubernetes agent group running the agent-runner image — that is Kubernetes with purpose=agent, not this kind).
