Orkestia
Blog
Runners

DevKit

Runner group kind backend_type=devkit — cloudless local or hosted broker, no cloud connection, used for provider-blind coding

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