How Helmhive works

Helmhive sits between the people who decide and the systems that execute. It stores intent, authority, and evidence, and it delegates execution to isolated runners and narrow brokers that never receive more than they need.

The parts

• Workspace. The tenant. It owns services, people, runners, settings, and the audit trail.
• Repository source. A Git provider identity (a Gitea bot or a GitHub App installation) that defines which repositories can be discovered.
• Service. An explicitly enrolled repository with an execution policy and per-service roles.
• Change. A request that becomes an exact plan, an approval, isolated implementation and review, and one pull request.
• AI runner. An isolated process with its own provider login, publishing the models, capabilities, and execution environment it offers.
• Execution environment. The immutable toolchain (image digest, platform, tools) a runner guarantees and a service binds to.
• Deployment runner. A separate isolated process that executes deployment adapters with credentials that stay on its host.
• Deployment environment and plan. A revisioned workflow for one service, and an immutable release plan approved and run against it.

A change, end to end

1. A Requester describes an outcome and confirms success criteria.
2. Planning binds the current commit, policy revision, environment revision, affected paths, checks, and expiry into a hashed plan.
3. A Developer approves that exact hash.
4. A runner implements inside the authorized paths and runs the declared checks; a second runner reviews with fresh context.
5. A server-side broker, holding a separate bot credential, opens one pull request.
6. Your Git provider takes over: CI, review, merge, release.

Full detail: Change lifecycle.

A deployment, end to end

1. A deployment runner registers and publishes adapters and authority aliases.
2. Connections bind adapters to aliases; an environment fixes a workflow for a service.
3. A plan pins a release and every revision it depends on.
4. An administrator approves the exact hash, then starts the run.
5. The runner executes, records a mutation boundary, verifies, and reports; uncertain outcomes go to reconciliation.

Full detail: Deployment model.

What Helmhive deliberately does not do

It does not merge, release, or deploy on its own; it does not hold provider or infrastructure credentials in the control plane; it does not infer authority from natural language; and it does not promote AI memory automatically. See Safety and authority model.