An open source software factory is a software factory whose production system, meaning the agent runtime, the sandboxes, the control plane, and the review and feedback loops around them, is built from source you can read, fork, and run on infrastructure you control.
The companies posting the biggest factory numbers all own theirs. Stripe's Minions, which merge more than 1,300 pull requests a week, began as a fork of Block's open-source agent, goose. Ramp built Inspect. Uber built Minion. None of them bought a seat license and waited for a roadmap. They took a system they could modify and modified it until it fit.
Until this year that option was reserved for companies with a platform team to spare. It isn't anymore. The pattern Ramp described is now open source, and so are several other ways to assemble a factory from parts. I maintain one of them, OpenInspect, and I deploy these systems into engineering teams for a living. This post is the map I wish existed when I started: what "open source" has to cover for a factory to count, the architecture layer by layer, which open-source tools sit at each layer, and what it actually takes to run a fork in production.
One quick disambiguation before we start, because the search results for this phrase are a mess. This is not about Factory.ai, a commercial vendor whose name overlaps the category. It is not about the Eclipse Foundation's OSBP, a low-code "software factory" from the model-driven era. And it is not about the Department of Defense's DevSecOps software factories. It is about running fleets of AI coding agents on an open-source stack.
In this guide
- What counts as an open source software factory?
- Why this layer should be open source
- The architecture, layer by layer
- Open-source software factory tools compared
- Running a forked factory
- What open source does not solve
- FAQ
What counts as an open source software factory?
The full definition and the production numbers are in the pillar post, so I'll keep this short. A software factory has three parts, and I've been using the manufacturing framing since before it was fashionable:
- A production line. A fleet of background agents that take work from wherever it originates (an issue, a Slack thread, a Sentry alert, a cron schedule), do it in an isolated environment, and return a pull request.
- Quality control. CI, static analysis, tests, and an AI reviewer that inspect every artifact against the same standard, regardless of who or what prompted it.
- A feedback loop. When a defect gets through, the system captures why and turns it into a doc, a skill, a lint rule, or a tool, so the defect rate falls over time.
"Open source" has to cover all three for the label to mean anything. An open-source agent CLI running on a laptop is not a factory; it is a very good power tool. The factory is the system around it, and that is the part that gets locked up when you buy.
| Component | What "open" has to include |
|---|---|
| Production line | The control plane that owns sessions, identity, secrets, and sandbox lifecycle; the sandbox images; the harness configuration; every client surface |
| Quality control | The review bot, the rules it enforces, and the back-pressure inside the sandbox |
| Feedback loop | Trajectories tied to pull requests, the skills and tools the agent receives, and the automations that maintain the codebase |
The point is not ideological. It is that every one of those rows is something you will need to change in month three, and you can only change what you can read.
Why this layer should be open source
I open-sourced OpenInspect for a reason I've repeated in every talk since: background agent infrastructure is becoming critical company infrastructure, and critical infrastructure should not be a vendor lock-in. Here is the argument in full.
Every company's environment is unique. Twenty microservices, an internal CLI, a staging cluster that needs a flag nobody documented, a data warehouse behind a VPN. A closed platform has to support all of that from the outside, one feature request at a time. A forkable system gets wired into the company the way the company actually works.
A background agent system manages far more than compute. The comparison vendors reach for is managed Kubernetes or managed Airflow: "we run the workers, you write the workflows." But an agent platform also controls your agents' workflows, their access to your services, their network policy, and how they show up in Slack, GitHub, and Linear. Imagine a managed Airflow where you could not edit a DAG. If you want a new integration, you file a support ticket. If you want a new workflow, also a support ticket. The build-vs-buy post has the forum receipts; the short version is that your P0 becomes someone else's P3.
Incentives point in different directions. You want your AI code reviewer to use as many tokens and as good a model as the change deserves. A per-seat vendor is paid the same whether it uses the best model or the cheapest one that passes. That misalignment lives in the quality-control stage, which is exactly the stage that sets your factory's ceiling.
Continuity is not negotiable. Now imagine your entire software factory is built on one company and that company changes terms, gets acquired, or shuts the product down. Overnight every automation, every skill, every environment you tuned is gone or frozen. You do not bet the core of your engineering process on a third party's continuity.
The cost floor is low. This surprises people. In an OpenInspect deployment the control plane and web app run on Cloudflare Workers and typically cost single-digit dollars a month. Sandboxes are pay-per-second on a provider you choose. Inference is whatever you already pay for, whether that's API keys, a ChatGPT subscription via OAuth, or an open-weight model like GLM 5.2 served on your own GPUs. The expensive part of a factory has never been the platform license. It is the tokens, and those you pay either way.
One paragraph of fairness. If nobody in your org is going to own the loop, buy. A hosted platform beats a six-month planning exercise, and the when-buying-makes-sense criteria still apply. Open source is the right answer when a platform, developer-productivity, or AI-enablement team exists to run it, which in my experience is the case at most companies past about fifty engineers.
The architecture, layer by layer
Every production background-agent system I've studied, including Stripe's, Ramp's, and the ones I've deployed, has the same shape: a control plane that coordinates sessions and holds identity and secrets, and a data plane where the agent harness actually runs. It's the durable shape, not the implementation. Here is that shape broken into the layers you will assemble, with the open-source options at each one.
| Layer | What it does | Open-source options | Notes |
|---|---|---|---|
| Triggers and surfaces | Where work enters and where results land: Slack, GitHub, Linear, web, cron, alerts, webhooks | OpenInspect (all of the above), Open SWE (GitHub, web), Astro's triagebot (GitHub Actions) | "Eight ways in" is the target; most of them should be events, not humans |
| Control plane | Session state, identity, RBAC, secrets, sandbox lifecycle, audit | OpenInspect (Cloudflare Durable Objects and D1), Machinist (Go control plane and workers), fabro (Rust binary, DOT-graph workflows) | The layer you will customize most |
| Sandboxes | One isolated, reproducible environment per session | Modal, Daytona, E2B, OpenComputer, Firecracker if you want to run your own | Mostly commodity; pick on features, not boot time |
| Harness | The agent loop itself | OpenCode, Claude Code, Codex, OpenHands, goose | Do not build your own |
| Quality control | CI, static analysis, tests, an AI reviewer you own | Semgrep, your CI, an agent session pointed at the PR | CI is the inspection station; the reviewer sits on top of it |
| Feedback loop | Turn failures into docs, skills, rules, tools; keep the codebase habitable | Managed skills, PR-linked trajectories, scheduled cleanup automations | The part nobody sells because it is specific to you |
| Inference | The models | Any API, subscriptions via OAuth, or self-hosted open weights (GLM 5.x, Kimi, Qwen) | Model choice per session is a feature, not a setting |
A few of these layers deserve more than a table row.
Sandboxes: pick on features, not boot time
I've launched well over a hundred thousand sandboxes across most of the providers, and the list of things that matter has stabilized. A sandbox provider needs: filesystem snapshots, tunnel URLs for dev servers, a secrets mechanism with an egress allowlist, the ability to run Docker, stdout and stderr visible in a dashboard and from a CLI, a first-class notion of an image (bonus points if it's a Dockerfile), and burstable CPU and memory.
Things that do not matter nearly as much as the marketing suggests: memory snapshots, pause-and-resume, and sub-second boot. The major providers boot in a second or two. The long pole is your environment getting ready, and you fix that yourself by pre-building the image and snapshotting the filesystem, so a session restores in a few seconds instead of running npm install every time.
On pause-and-resume specifically: I think it's the wrong paradigm for agent sandboxes. Pausing leaves processes in undetermined states, TCP connections dead, and timestamps wrong, and every provider does it a little differently. Snapshot-and-restore is the predictable option. Everything dies, the disk survives, boot re-derives the rest. One code path, the same on every boot.
One more opinion: do not run agent sandboxes in a shared Kubernetes cluster. The isolation is not designed for untrusted, prompt-injectable workloads. Use VMs, which is what every serious provider is doing under the hood anyway.
Harness: do not build your own
This is where teams waste the most time. You are unlikely to have novel ideas about sub-agent orchestration, context compaction, or progressive disclosure that are worth owning an entire harness. The open harnesses are more or less at parity, and they improve every month without you. Spend your time on the pieces around the harness instead: the execution infrastructure, custom tools and skills for your company's systems, and self-improvement on your own trajectories. That is where all the leverage is, and it is the part a vendor cannot do for you.
Quality control: the reviewer should be yours
In the manufacturing framing, CI is quality control. An AI reviewer fits on top of it, and at this point not having one is close to irresponsible: it catches what a human skimming their fifteenth PR of the day will not. The reviewer is also the component where the incentive argument above bites hardest, so it belongs inside your factory, running the model you choose, with your rules.
Two patterns that pay off immediately. First, back-pressure, not advice: warnings are read by reviewers, deterministic failures are read by the agent. A Semgrep rule at severity: ERROR that fails the pre-commit hook the moment raw SQL appears means the agent sees the failure and rewrites the code before a human ever opens the PR. Fix the pattern once and it holds across every future PR. Second, autofix: when the reviewer leaves comments, the same session that opened the PR should pick them up and push the changes. By the time you look, it's fixed.
Feedback loop: the product is the loop
When a PR fails, give the agent its own trajectory and ask why. Then turn the answer into a doc, a skill, or a lint rule. Teams that do this consistently report that the merge rate on agent PRs climbs toward "nearly all of them" within a couple of months. It does not start there. It gets there because the codebase becomes habitable: dead code removed, setup scripted, conventions enforced by tools instead of tribal memory.
The unglamorous automations matter too. A weekly job that deletes the junk tests agents leave behind. A nightly session that reads the last 24 hours of changes and opens PRs for what it finds. These are ten-line automations in an open system and unavailable in most closed ones.
Open-source software factory tools compared
There is no neutral comparison of these projects anywhere, so here is mine. Star counts are from GitHub as of September 2026 and are a rough proxy for community, not quality. I maintain the first row, so weigh my opinion accordingly.
| Project | Shape | Runs where | Ways in | Best for |
|---|---|---|---|---|
| OpenInspect (~2.7k stars, MIT) | Session platform: control plane, sandboxes, multiplayer sessions, automations, review, RBAC | Cloudflare control plane; Modal, Daytona, E2B, or OpenComputer sandboxes | Web, Slack, GitHub, Linear, cron, Sentry, GitHub Actions, webhooks | A company-wide internal factory modeled on Ramp's Inspect |
| OpenHands (~80k stars, MIT) | Harness plus a self-hosted control center and automations | Local, remote, or cloud backends | Web, API, GitHub | Teams that want the most mature open harness and will build the factory around it |
| Open SWE (LangChain, MIT) | Async coding agent with per-thread sandboxes and a dashboard | LangGraph backend | GitHub, web | Teams already on LangGraph |
| fabro (~1.6k stars, MIT) | Workflow orchestration: agents as nodes in a DOT graph with human gates | Single Rust binary; Daytona sandboxes | CLI, API | Long unattended pipelines with explicit approval gates ("dark factory" runs) |
| Machinist (~340 stars, MIT) | Local-first control plane and workers that wrap Claude Code, Codex, or Pi | Your VM or laptop | CLI, API, schedules | Small teams that want scheduled multi-repo work without cloud sandboxes |
| Vercel's software factory template | Fixed pipeline of classifier, analyzer, implementer, reviewer, backporter agents | Vercel Sandbox, Functions, Queues | GitHub webhooks | Maintaining one high-traffic open-source repo |
| Astro triagebot | Label-based state machine running triage-and-fix agents | GitHub Actions | GitHub | Issue triage on a public repo with no extra infrastructure |
| SWE-AF (~1k stars) | Multi-agent fleet: plan, code, test, ship | Self-hosted | CLI, API | Experimenting with fleet orchestration patterns |
How to read this. The projects fall into three shapes, and the shape matters more than the feature list:
- Session platforms (OpenInspect, OpenHands' control center) treat a long-lived, multiplayer session as the unit. Anyone in the company can start one from Slack, an engineer can take it over, and it ends as an attributed PR. This is the shape Ramp, Stripe, and Uber converged on for internal use.
- Workflow graphs (fabro, Vercel's template, SWE-AF) treat a pipeline as the unit: fixed stages, explicit gates, good for unattended batch work on a known kind of task. Less good when a PM wants to poke at a bug from Slack.
- Local control planes (Machinist) keep everything on hardware you already have. Cheap and simple, but you give up the isolation and parallelism that cloud sandboxes provide, which is most of the point once more than a couple of people use the system.
If you want the company-wide version, you want a session platform, and you will want it to be single-tenant and inside your trust boundary. If you want to run a hundred migrations overnight against a well-understood target, a workflow graph is a better fit, and nothing stops you from running one inside a session platform's sandboxes.
Running a forked factory
Deploying is the easy part. Here is what actually happens in the first ninety days, drawn from the deployments I've run and supported.
What you fix first
The agent is a perpetual new hire. It joins fresh every session, with no Slack to ping and no teammate to pair with, so anything undocumented becomes visible immediately. The number-one surprise, at nearly every company, is that there is no working local development environment. The stack is theoretically runnable; nobody has run it end to end in months. The shortcuts show up in a predictable order:
- No way to log in without a real third-party identity provider
- No mocked or test servers for external dependencies
- Special configuration, not in the repo, needed to reach staging services
- Service-level auth in place, but no granular access control on what a given caller may do
Fixing these for the agent fixes new-hire onboarding too. Budget the first two to four weeks for it and do not shortcut it: a crappy environment produces a crappy factory, and developers will quietly stop using it.
Fork hygiene
An open-source factory is a fork you operate, so treat the upstream relationship deliberately. The pattern that works:
- Sync weekly, or nightly by automation. Most teams pull upstream at least once a week. Several run a nightly session that merges upstream, runs the tests, and opens a PR if anything conflicts.
- Keep company-specific work in the places designed for it. Skills, custom tools, environment scripts, and integrations are meant to be yours. The control plane and harness plumbing should stay close to upstream so merges stay cheap.
- Push generic fixes back. If you needed it, someone else does too, and it stops being your merge conflict.
On the maintainer side, the obligation is to avoid sweeping backwards-incompatible changes. That is the contract that makes a fork viable.
Adoption is a product problem
Do not mandate it. Every system I know of that stuck, at Ramp, at Stripe, and at the companies I've worked with, spread because it was obviously better, not because someone was told to use it. The hang-ups you will hit are consistent: developers glued to a terminal workflow who write off anything different, developers who are not yet "agent-pilled" and want to watch every edit, people who built private scripts around a CLI and do not want to share them, and people who feel exposed when the whole team can see how they prompt. The same objections were made during the move from copying out of ChatGPT into an IDE. Give it time and make the environment good.
Expect non-engineers to show up faster than you think. Once the environment lives in a sandbox, "what is Docker" stops being a prerequisite, and the first time a PM gets a fix merged, the Slack channel erupts. That is the moment adoption tips.
Run it like a plant manager
The underrated benefit of a factory you own is visibility. Every session, every task, every token is recorded and tied to the resulting pull request. You can see tokens per task by size and complexity, time to merge per PR and why the slow ones are slow, and which skills or repos produce the most rework. If spend doubled in six weeks with no change in output, you would know the same day. That is the data that turns "we use AI" into a process you can actually improve.
What open source does not solve
Some honesty, so the pitch stays credible.
- It is an ongoing system, not a project. Treat it like any ML system: someone tunes it until the end of days. The biggest risk I see is a team standing it up, declaring victory, and walking away.
- Enterprise identity is yours to finish. OAuth via GitHub and Google is built in; SAML SSO is not. It's a contained piece of work, but it's work.
- Supply chain and prompt injection do not go away because you own the code. A factory that pulls packages and reads issues is exposed to both. Owning the system means you can scope what a session can reach and add an egress allowlist; it does not mean you can skip doing so.
- Some teams should stay artisanal. When code generation gets ten times faster, review is the station that breaks. You either retool around the factory or you accept that you are a low-volume, high-touch shop and price accordingly. Both are legitimate. Pretending to be one while operating as the other is not.
- The hard problems are still hard. Agent memory, self-improving skills, and closed measurement loops are where the frontier is. Most organizations are not there yet, and that's fine: the early stages, meaning basic infrastructure, environment setup, org integration, and access control, are where the value is for the first year.
FAQ
Is there actually an open source software factory? Yes. OpenInspect is an MIT-licensed, self-hosted implementation of the pattern Ramp described for Inspect: sessions in cloud sandboxes, multiplayer, eight ways in, automations, review, and RBAC. fabro, Machinist, OpenHands, Open SWE, and Vercel's template cover other shapes. See the comparison table.
What is the difference between a background agent platform and a software factory? The platform is the production line: sessions, sandboxes, surfaces. The factory is the platform plus quality control and a feedback loop. Every factory has a background agent platform inside it; not every platform is being run as a factory.
Can I self-host a software factory? Yes, and for a company-wide system you should. OpenInspect, for example, runs the control plane on Cloudflare, sandboxes on the provider you choose, and inference on whatever you already pay for, inside your own accounts and trust boundary.
What does an open source software factory cost to run? The platform itself is close to free: a control plane on serverless infrastructure costs single-digit dollars a month, and sandboxes bill by the second. The real spend is tokens, which you pay regardless of platform, and the people who tune the system.
Do I need to write my own coding agent? No, and you should not. Use OpenCode, Claude Code, Codex, or OpenHands inside the sandbox and invest in the tools, skills, and environment around it.
Which sandbox provider should I use? Any one that offers filesystem snapshots, tunnels, an image concept, a secrets mechanism with egress control, and visible logs. OpenInspect supports Modal, Daytona, E2B, and OpenComputer; switching is a configuration change.
How is this different from Factory.ai? Factory.ai is a commercial platform. This post is about the category: factories assembled from open-source parts that you deploy and modify yourself.
How do I keep a fork in sync with upstream? Pull weekly or nightly, keep company-specific work in skills, tools, and environment scripts rather than core plumbing, and contribute generic fixes back. Upstream's job is to avoid breaking changes.
The takeaway
The teams with the best software factories built them from something they could change. That used to require a platform team and a year. Today it requires a fork, a sandbox account, and a team willing to own the loop. The layers are commodity, the harnesses are open, and the reference implementations exist. What is left is the work that was always yours: making your environment reproducible, deciding what the agent may touch, building the quality gate you trust, and feeding every failure back into the line.
Own the line.
Work with me
I help engineering teams stand up an open source software factory inside their own trust boundary: OpenInspect or a system like it, sandboxed agents, the integrations your company actually uses, secrets and access design, and the operating model to run it. If you're deciding between forking and buying, I run an OpenInspect Readiness Review that shows what would break first.
Book a call or see how I work with teams.
Related reading
- What is a software factory? — the definition, the production numbers, and the operating model
- Build vs. buy coding agents — why owning the platform is the asset
- OpenInspect — the architecture and security model of the open-source implementation
- Choosing sandbox infrastructure for agent fleets
- Observability for coding-agent sessions
Cole Murray is the creator of OpenInspect, an open-source background-agent platform. Previously he built large-scale ML systems at Amazon, and he researches AI security (the Cline supply-chain attack, multiple n8n CVEs). He's spoken on background-agent systems at the Background Agents Summit, on Modal's platform, and on the Latent Space podcast.