Operate
Runner auth
Runners are not Admin keys and not client API keys. They authenticate to the plane with per-kind tokens so only authorized fleets can pull jobs.
What it is
Set RUNNER_TOKEN_<kind> on the control plane (single token or comma-separated allow-list for rotation).
Runners present RUNNER_TOKEN. Optional RUNNER_TENANTS_<kind> restricts tenants on unbound internal routes.
Why it is here
When client auth is on, an open runner channel would bypass the story. Serve fail-closes unless every tokenized kind has a tenant list (use default for single-tenant).
How to implement
- Choose kinds matching your runners (e.g. python-langgraph, typescript-langgraphjs).
- Generate tokens; set plane env + runner env; restart plane after allow-list changes.
- Set
RUNNER_TENANTS_*when client auth is enabled. - Confirm jobs flow: create a run, watch Admin → Runs move pending → running → success.
- Rotate by appending a new token to the allow-list, rolling runners, then removing the old.
# Control plane (illustrative) export RUNNER_TOKEN_PYTHON_LANGGRAPH="tok_a,tok_b" export RUNNER_TENANTS_PYTHON_LANGGRAPH="default,acme" # Runner export RUNNER_TOKEN="tok_b"
In the product
Runs stuck pending usually means no authenticated runner for that kind
What to expect
- Not for Admin login — pasting a runner token into Admin fails.
- Run-binding — connector/store proxy calls need live run id + generation; tenant comes from the assignment.
- Next — credentials map, production day-0, ops.