What is Helmhive
Helmhive is a control plane for services and governed software changes. A workspace enrolls the services a team is responsible for, records who may do what on each of them, and lets people and AI agents act through the same explicit permissions and audit trail.
Helmhive stores control-plane state: services, execution policy, plans, approvals, runs, correlations, and audit evidence. Your Git provider, CI, registries, and deployment systems keep their own records. Merging, releasing, and deploying stay under human control in those systems.
What you can do with it
Section titled “What you can do with it”- Enroll services from repositories a connected Git provider identity can see, and record an execution policy for each: repository root, approved commands, protected paths, expected checks, and the AI capabilities allowed.
- Turn a plain-language request into a tested pull request. A Requester describes the outcome and confirms success criteria, a Developer approves one exact plan, isolated runners implement and independently review the change, and a server-side broker opens the pull request. See Change lifecycle.
- Run AI work on isolated runners that hold their own provider logins, publish the models they can use, and guarantee an immutable toolchain. See AI delivery model.
- Plan, approve, run, and verify deployments through reviewed plans and separately trusted deployment runners, with rollback as a new plan and uncertain outcomes reconciled explicitly. See Deployment model.
- Trace everything in Activity and the audit trail.
How the console is organised
Section titled “How the console is organised”The sidebar has four groups. Items you are not allowed to use are hidden, but the server still denies the operation if you reach it another way.
| Group | Pages | Who sees it |
|---|---|---|
| Work | Overview, Services, Changes | Everyone in the workspace |
| Operate | AI, Deployments, Activity | Workspace administrators and owners (Activity also needs audit access) |
| Admin | Settings (Repositories, People, Authentication, Audit) | Workspace administrators and owners |
| Support | Help | Everyone |
Two independent role layers
Section titled “Two independent role layers”A workspace role (Member, Administrator, Owner) controls the workspace itself: members, settings, repository sources, runners, deployments, and audit. A service role (Requester, Developer, Administrator) controls one assigned service: who may request changes and who may approve an exact plan.
The layers never inherit from each other. A workspace Administrator still needs the Developer role on a service to approve one of its plans. See Roles and permissions.
Where to go next
Section titled “Where to go next”- Everyone: Before you begin explains hosting, your operator, the first sign-in, and how people get accounts.
- Workspace owners and administrators: Set up a workspace.
- Requesters and developers: Work with changes.
- To learn the vocabulary first: Glossary.