HumanLayer Is Now Open Source: What Is in the Repo and What It Takes to Self-Host

Teams building AI-assisted delivery pipelines run into the same constraint. The agent orchestration layer sits in the middle of the SDLC, between the compute, the coding agents and the review flow, and if that layer is a closed hosted product, nobody on the team can fix, extend or audit it. HumanLayer's answer is to publish its core under Apache 2.0, at github.com/humanlayer/humanlayer.

The release is not a stripped-down community edition. According to the announcement from Dex and Kyle, it is the same code HumanLayer Cloud runs: the desktop app, the daemon that drives Claude Code and Codex sessions, the cloud API, the sync layer and the full data model. Self-hosting is possible today, but it comes with one real friction point: a set of third-party API keys that are currently mandatory.

For an engineer weighing this, the useful questions are what is actually in the repository, what the licence and telemetry terms are, and how much work a self-hosted deployment takes right now.

What is in the repository

The repository covers the whole product, not only a client or SDK. The components, as the HumanLayer team lists them:

• The desktop app, built on Electron with a Tauri build as well, plus the underlying web app that powers the UI.
• The daemon that runs Claude Code and Codex sessions on your own machines, shipped inside the humanlayer CLI.
• The cloud API, and the Electric proxy that syncs Postgres out to every client.
• Build sources for the public humanlayer-pi and humanlayer-opencode plugins.
• The RPI skills and the Linear CLI.
• The data model: orgs, teams, projects, tasks, sessions, plans and comments, diffs, PRs, and the GitHub, Linear, Jira and Slack integrations.

The architecture follows from that list. Agent sessions execute locally through the daemon, state lives in Postgres, and Electric replicates it out to the desktop and web clients. Teams that want to change how sessions are tracked, or add an integration beyond the four that ship, now have the data model and the API in front of them rather than a hosted contract.

Licence and telemetry

Everything is under Apache 2.0. That permits commercial use, modification and redistribution, with the usual attribution and notice requirements, so you can fork the daemon or the API into internal tooling without a separate commercial agreement.

The telemetry position is unusually explicit. If you build and run HumanLayer yourself, there is no telemetry at all. Data leaves your environment only when you configure keys or DSNs for an external service. In practice your egress surface is whatever you wire up: an error-reporting DSN, the Slack or Linear integration, the model providers your agents call. For security reviews, that turns 'what does this tool phone home to' into a question you answer by reading your own config.

Running the stack yourself

The supported path today is the docker compose file in the repository. The team's suggested workflow is to launch a coding agent inside the repo and prompt it with: walk me through getting the devstack up and running. That fits a codebase meant to be operated by agents, but it also tells you the setup is not yet a one-command install with a polished operator guide.

The blocker you will hit first is credentials. A number of third-party API keys that could be optional are not yet, and the affected processes refuse to start without them. The announcement names WorkOS, Slack and Linear among them. If you only want to evaluate the agent session flow, you will still need to provision those accounts or patch the startup checks yourself.

The team says making these keys optional is one of the first things it will change, and that contributors are lined up to work on the self-hosting experience. Deployment targets beyond docker compose, such as AWS, infrastructure-as-code and Kubernetes, are described as coming soon, with no committed timeline.

Why the team made the core open

HumanLayer's stated argument is that software factories have to be open and composable. Every team the company talks to is assembling its own pipeline from compute, harnesses and review flows it already has, and nobody wants a black box at the centre of it.

The announcement points to David Crawshaw's essay 'Devtools must be open source' for the sharper version: once your agent can read and patch the source of every tool you use, closed tools become frustrating, because you cannot fix them, cannot customise them, and depend on the vendor's priorities. That argument matters most in agent-heavy workflows, where the agent itself is often the one that would make the fix.

For existing HumanLayer Cloud users, paid or free, nothing changes for now. The hosted product continues as before, and the open repository is the same code underneath it.

Where it does not fit yet, and what to watch

If you need a self-hosted deployment that starts without external SaaS dependencies, it is not there yet. The mandatory WorkOS, Slack and Linear keys mean an air-gapped or minimal-footprint install takes code changes on your side until the upstream work lands. Teams standardised on Kubernetes or Terraform will be writing their own manifests for the time being.

Security is the other open question, and the team names it directly. Going open source brings maintainer, triage and security problems HumanLayer has not dealt with before, and the announcement acknowledges that concern in light of recent events. The team says it has spent significant time hardening the app, but a newly public codebase with an untested triage process deserves your own review before it runs agents with write access to your repositories.

Before committing, check the issue tracker for progress on optional credentials and deployment targets, and watch how quickly security reports get handled. Those two signals will show whether self-hosting HumanLayer is a production option or still an evaluation project.

This article draws on Open Source Alternatives to Reflector? and answers to it (1, 2), on the Stack Exchange network, licensed under CC BY-SA 4.0.