HumanLayer joins Factory: refunds, migration and open source
HumanLayer is joining Factory, bringing its team and collaborative coding-agent workflows into the company behind Droid. The November 4 acquisition announcement describes a product transition rather than an immediate shutdown. HumanLayer users will have options to export their data, move to Factory or run the open-source software themselves.
For existing customers, the immediate questions are how long the hosted service stays available, what happens to payments and which workflows will survive the move. The companies have answered some of those questions, but have not published a final cutoff date or a complete migration specification.
What changes for existing HumanLayer users
In their own announcement, founders Dex Horthy and Kyle Mistele promise that the current platform will continue running for a transition lasting at least 30 days. They also say paying customers will receive refunds covering the last several months. The post does not specify exact refund amounts, processing dates or the end of hosted service.
Treat the 30 days as a minimum transition commitment, not a confirmed shutdown countdown. A team with active work should ask which records an export preserves and whether they can be imported elsewhere. Keep the export and a list of important projects before deciding where the next production task should run. These are our suggested checks, not a migration we have tested.
Which HumanLayer features are coming to Factory
Factory says multiplayer tasks and workstreams, plus collaboration on agent-written plans, specifications and design documents, are planned for the next few weeks. HumanLayer also names live session diff streaming. These are roadmap commitments from the acquisition posts, not evidence that the full feature set is available in Factory today.
The practical appeal is shared oversight. A developer can judge a proposed plan with colleagues before an agent changes the code, then examine the resulting diff. Whether that works for a particular team depends on the implementation: who can edit a plan, which version an agent follows and how reviewers see changes. The announcements do not settle those details.
For readers evaluating the destination, our Factory Droid workflow and permissions guide explains the existing harness and approval controls. Those controls still deserve a separate evaluation from the promised collaboration features.
HumanLayer core was already open source
The acquisition posts use future-facing language about open sourcing HumanLayer. However, HumanLayer had already announced its core release on October 23. That earlier post described the same code used by HumanLayer Cloud, covering the desktop and web applications, session daemon, cloud API, integrations and Research, Plan, Implement skills under Apache 2.0.
That date matters. The November 4 news is the company joining Factory and explaining its transition, rather than the first appearance of public source code. The October post also said hosted free and paid accounts were unchanged at that time. Its reassurance should now be read alongside the newer transition announcement.
Self-hosting keeps a path open, with work attached
The current HumanLayer repository describes a system that runs Claude Code, Codex, OpenCode and Pi on users’ machines, with tasks, plans and reviews synchronized through desktop and web clients. Its setup requires Bun and Docker, with Rust additionally needed for the Tauri desktop build. Self-hosting guides remain in progress.
The repository warns that its Docker Compose starter uses simple default passwords that must be changed before deployment. It also says source builds leave Sentry, PostHog and the WorkOS client ID off when their environment values are unset. That is a description of the source configuration, not an independent security audit.
Running a daemon locally and operating the full collaboration service are different responsibilities. Teams choosing self-hosting should identify who owns backups, access control, updates and recovery before relying on it. Public code gives them a way to continue or adapt the software, but it does not establish an indefinite hosted service or a guaranteed maintenance schedule.
The next useful evidence will be a documented export path, concrete migration instructions and release notes showing the promised Factory features. Until then, preserve current work and evaluate the available routes against the workflows your team actually uses.
