HumanLayer open-sources its whole agent control plane
HumanLayer, the company behind a popular workflow for steering Claude Code and Codex sessions, open-sourced its entire product on Friday evening under Apache 2.0. Not a community edition. In Dex Horthy's words: "This is all the same code HumanLayer Cloud runs."
What's in the box: the desktop app (Electron, plus a Tauri build) and the web app behind it, the daemon that runs Claude Code and Codex sessions on your machines, the cloud API and the proxy that syncs Postgres out to every client, the pi and OpenCode plugins, the RPI skills and Linear CLI, and the full data model of orgs, teams, projects, tasks, sessions, plans, diffs, PRs and the GitHub, Linear, Jira and Slack integrations. Build and run it yourself and there's no telemetry. The repo sits at about 12,400 stars. Blog: https://www.humanlayer.com/blog/open-sourcing-humanlayer Repo: https://github.com/humanlayer/humanlayer
The reasoning is worth reading. Every team is building its own "software factory" out of compute, harnesses and review flows it already has, and "the last thing great builders want is a black box sitting in the middle of their SDLC." The sharper version: once your agent can read and patch the source of every tool you use, closed tools are frustrating because you can't fix them.
It isn't polished for self-hosting yet. The post admits several third-party keys, such as WorkOS, Slack and Linear, are still required, and processes "will refuse to start without them." Within hours a user flagged that the dev docker-compose ships default database passwords and an unauthenticated Redis, and Dex said a warning is coming. Run it on a laptop, not an open server, until that's fixed.
The bigger signal is timing. In a week when LiteLLM's compromise showed what happens when an agent platform holds unscoped tokens, the layer that sits between your agents and your code is the one you most want to be able to read. Expect more orchestration vendors to face the same question: if your customer's agent can audit your source, why should it be closed?
← Back to all articles
What's in the box: the desktop app (Electron, plus a Tauri build) and the web app behind it, the daemon that runs Claude Code and Codex sessions on your machines, the cloud API and the proxy that syncs Postgres out to every client, the pi and OpenCode plugins, the RPI skills and Linear CLI, and the full data model of orgs, teams, projects, tasks, sessions, plans, diffs, PRs and the GitHub, Linear, Jira and Slack integrations. Build and run it yourself and there's no telemetry. The repo sits at about 12,400 stars. Blog: https://www.humanlayer.com/blog/open-sourcing-humanlayer Repo: https://github.com/humanlayer/humanlayer
The reasoning is worth reading. Every team is building its own "software factory" out of compute, harnesses and review flows it already has, and "the last thing great builders want is a black box sitting in the middle of their SDLC." The sharper version: once your agent can read and patch the source of every tool you use, closed tools are frustrating because you can't fix them.
It isn't polished for self-hosting yet. The post admits several third-party keys, such as WorkOS, Slack and Linear, are still required, and processes "will refuse to start without them." Within hours a user flagged that the dev docker-compose ships default database passwords and an unauthenticated Redis, and Dex said a warning is coming. Run it on a laptop, not an open server, until that's fixed.
The bigger signal is timing. In a week when LiteLLM's compromise showed what happens when an agent platform holds unscoped tokens, the layer that sits between your agents and your code is the one you most want to be able to read. Expect more orchestration vendors to face the same question: if your customer's agent can audit your source, why should it be closed?
Comments