Hezo: self-hosted AI agent teams with org charts, budgets and sandboxed containers
Your own team of AI agents. Built to deliver.
At a glance
- What is it?
- Hezo is a GPL-3.0 licensed TypeScript server and web app that runs teams of AI agents as an organisation, with per-agent model keys, budget caps and one container per project. The design is opinionated about secrets and isolation, and the container runtime requirement is the first thing to check before you install it.
- Who is it for?
- Adopt Hezo if you want agents organised as a team with approvals, budgets and per-project container isolation, you already run Docker, Colima, Rancher Desktop, OrbStack or Lima, and you accept GPL-3.0 terms. Do not adopt it if you plan to deploy on a managed-container PaaS such as Render, Railway or Cloud Run with the default setup, because the documentation states those platforms do not provide the host container-runtime socket the default mode needs.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Hezo targets: many agents, no org structure
Running one AI agent is a script. Running ten is a scheduling problem, and the README frames the pain directly: "You manage goals and projects, not twenty terminal tabs." Hezo is for people who have moved past a single chat session and now need several agents working on one piece of work with different roles. The README names the roles it expects you to create: a CEO, a Captain, engineers, designers and researchers. That is a management metaphor, not a technical one, and it drives the whole product surface. Projects, org charts, budgets and approvals are the primitives. The intended user is technical enough to run a server and a container runtime, but is not being asked to write the orchestration layer. The README positions the audience around managing goals and projects rather than supervising individual agent runs.
How the pieces fit: server, web app, containers and a master key
Hezo ships as one self-contained binary that starts a server, and the README instructs you to open http://localhost:3100 in a browser. The web app is where you create projects, pick teams and watch progress. Agents do not run on the host: the README states that "Agents always run inside a container", and every project gets its own container. That is the isolation boundary. The README also describes a secrets boundary: agents never see your real secrets, and sensitive material is encrypted behind a key only you hold. First-run setup is where you create that master key and connect a model. The README further notes that each agent can be given its own model, so a Designer might run on GPT while an Engineer runs on Claude and an Analyst on Gemini, which is the example the org-chart animation in the README uses. The orchestration layer is described in terms of tasks: agents pick up tasks and work autonomously, and the project dashboard summarises state. The README does not describe the scheduler, the message bus or the storage layer, so the internals are not verifiable from this material.
Getting it running: install, start, first-run setup
The README gives two install paths. On macOS and Linux: curl -fsSL https://hezo.ai/install.sh | sh. On Windows PowerShell: irm https://hezo.ai/install.ps1 | iex. After install, the command is simply hezo, which starts the server, and you then open http://localhost:3100. There is also a manual route: download the binary from GitHub Releases. The README states the machine needs a Docker-compatible runtime, and lists Docker, Colima, Rancher Desktop, OrbStack and Lima as working options, adding that Hezo finds the socket itself. If you would rather not run a local runtime, the README points to a managed sandbox service, in which case the server needs no runtime at all. Switching between local and managed containers is done from Settings > Containers. First-run setup creates the master key and connects a model, and the README links a first-project walkthrough. For an always-on instance, the README offers one-click deploys for Google Cloud and AWS, with DigitalOcean still a written guide until its Marketplace image is listed. Those deploy paths provision Docker, the binary, automatic HTTPS through a real certificate via <ip>.sslip.io, systemd and a firewall.
The container socket is the constraint that decides your hosting
The README is unusually direct about a limitation, and it is the one most likely to bite. The default setup runs each project's agents on the host's own container-runtime socket. The README states this means you need a real VM, and explicitly names managed-container PaaS platforms (Render, Railway, Cloud Run) as unsuitable for the default mode. If you have already standardised on one of those, Hezo in its default configuration is the wrong tool. The documented escape hatch is to run the containers on a managed sandbox service instead, which removes the runtime requirement from the server and lets a much smaller VPS suffice. That is a real architectural fork, not a configuration detail, and it changes where your agent code actually executes. A second constraint follows from the same design: because agents run AI-written code inside containers, the isolation boundary matters more than it would for a fixed tool. The README leans on this, saying Hezo is "secure by design" and that agents never see your real secrets. That claim is only as strong as the container runtime you point it at.
GPL-3.0, release cadence and what maintenance looks like
Hezo is licensed GPL-3.0-or-later, per the badge and the LICENSE.md reference in the README. That matters if you plan to embed it in a product or ship a modified server: the copyleft terms travel with derivative distribution, and the README does not offer an alternative licence. If your organisation avoids GPL-3.0 for server-side components, this is a blocker to settle before you invest in a deployment. On cadence, the release list shows three releases in three days (0.62.0 on 2026-09-08, 0.62.1 and 0.62.2 on 2026-09-09), and the last push to main was 2026-09-10. That is a fast-moving pre-1.0 project. Frequent patch releases at this rate usually mean fixes are landing quickly, but they also mean the surface you deploy today may shift. The README does not describe an upgrade procedure, a migration path for stored data, or a compatibility policy between minor versions, so treat upgrades as something to verify against the release notes rather than assume. There is a CI workflow and a coverage badge, which tells you tests run, not what they cover.
Where Hezo sits next to a plain agent framework
The closest comparison is a general agent framework where you write the orchestration yourself: you define tools, wire a loop, and decide how agents hand work to each other. Hezo inverts that. The README describes launching a ready-made team from a marketplace (App Team, Social Media Marketing, Investment Portfolio), starting from a team template, or asking the CEO to assemble one. Structure, budgets and approvals are product features rather than code you maintain. The trade is control for convention. With a framework you decide exactly how state is stored and how agents communicate; with Hezo you get the org metaphor and the sandboxing, and you inherit its opinions about roles and task flow. The README also mentions UI support for 12 languages, which a hand-rolled orchestration layer would not give you. If your agents must follow a bespoke coordination protocol, a framework will fit better. If you want a running team with a dashboard and approval gates without building the management layer, Hezo is aimed squarely at that.
Who should adopt Hezo, and what to check first
Adopt it if you want agents organised as a team, you are comfortable running a server, and you either have a host with a Docker-compatible runtime or you are willing to point Hezo at a managed sandbox service. The budget caps, per-agent model keys and approval flow are the parts that distinguish it from stitching a framework together yourself. Do not adopt it if you are locked to a managed-container PaaS and cannot move the agent containers elsewhere, or if GPL-3.0-or-later is incompatible with how you plan to distribute your work. Before installing, read the install script at https://hezo.ai/install.sh rather than piping it blind, confirm your runtime is one of Docker, Colima, Rancher Desktop, OrbStack or Lima, and check the release notes for 0.62.2 against whatever version you install, since there is no documented upgrade path. The decision turns on one question: does your host expose a container-runtime socket, or are you running the agents on a managed sandbox service?
Editorial conclusion
Adopt Hezo if you want agents organised as a team with approvals, budgets and per-project container isolation, you already run Docker, Colima, Rancher Desktop, OrbStack or Lima, and you accept GPL-3.0 terms. Do not adopt it if you plan to deploy on a managed-container PaaS such as Render, Railway or Cloud Run with the default setup, because the documentation states those platforms do not provide the host container-runtime socket the default mode needs. Before installing, verify that the install script at hezo.ai/install.sh and the binary on GitHub Releases are what you expect, and confirm which container runtime your host exposes.
Community notes