Open source · Apache-2.0

Tickets in. Reviewed pull requests out.

OpenFactory takes a card from your board, runs a coding agent on it in a sandbox with your project's own test gates, has a second agent review the result, and opens the pull request. You decide what gets built and what ships.

Apache-2.0 No cloud account Test count: docs/STATUS.md
Docker is the only prerequisite
curl -fsSL https://openfactory.digital/install.sh | sh
# pulls the published images and starts the panel
# on http://localhost:8787
Why

One assistant per developer does not scale. A pipeline does.

Claude Code, Codex and Kimi make one person faster. They are licensed per seat and driven by hand: someone starts each task, stays with it, and carries it to a pull request. Capacity is still headcount.

OpenFactory runs those same agents as a pipeline the team owns. Tickets go in without a person attached to each one, and the number you manage becomes cost per merged ticket instead of seats per month. People keep the decisions that need judgment and stop being the hand-off between a ticket and a PR.

AN ASSISTANT PER PERSON one PR one PR one PR Capacity is headcount. Bought per seat. No person, no PR.
ONE PIPELINE THE TEAM OWNS one person tickets OpenFactory runs the same agents reviewed PR reviewed PR reviewed PR Capacity is the pipeline. Measured per merged ticket.

Same agents on both sides. The difference is whether a person has to drive each one.

Integrations

Works with the tools you already run

OpenFactory sits between your tracker and your coding agent. Each provider is a registry entry, so you can swap the tracker, the forge, the CI observer or the agent independently.

BOARD & TRACKER GitHub Jira Azure DevOps OpenFactory tech-lead product you decide HARNESS Claude Code Codex Kimi OpenCode FORGE · OPENS THE PR GitHub Azure DevOps CI/CD · YOUR OWN GitHub Actions Azure Pipelines ticket in · status back dispatch · diff back opens the PR triggers observes, never deploys
OpenFactory updates the ticket and opens the PR. It reads your CI results and never triggers a deploy.
when a job stalls

The tech-lead classifies the failure

It parks the ticket, works out what would fix it, retries only what is safe to retry, and escalates the rest to a person as a concrete question. Where the boundary is.

taking requirements

The product role scopes the work

Talks to the requester, reads the board, and proposes tickets with the requirement behind each one. Nothing enters the queue until a person accepts it. The roles.

Measured

Fewer tokens per ticket. Same wall-clock.

OpenFactory keeps a module map of your codebase and puts it in the agent's context, so the agent reads less to find the same code. A/B on one production codebase, n = 8 tickets per arm, medians, scanned 2026-09-01:

Map off (control) Map injected
Tokens per ticket −22.0%
75,175
58,655
Agent turns per ticket −30.8%
138
95.5
Cost per ticket −36.2%
$11.70
$7.47
Wall-clock per ticket +1.1%
3,272 s
3,309 s

Wall-clock did not move. The map makes a ticket cheaper, not faster.

Eight tickets per arm on one codebase is a signal, not proof. The arm definitions, the method and what is excluded are in docs/knowledge-layer.md. The platform reports the deltas and leaves the verdict to you: it cannot know whether the two ticket mixes are comparable.

Product

See it run

One ticket going through: sized, built in a sandbox, gated, opened as a PR, reviewed by a second agent, and reported back on the card.

OpenFactory dashboard and pipeline board
Board → PRa ticket picked up and turned into an open pull request
Independent reviewthe second agent's decision, score and findings
Escalationa stall surfaced as a question with executable options
For the team running it

What you keep. What it takes.

You keep the decisions

Policy approves the routine steps, so nobody signs off on test runs. What gets built, whether it merges, and every promotion to production stay with a person.

It never fails silently

An unreadable board is not an empty queue. A stalled job retries within its budget or puts a concrete question on the card. The test suite treats going quiet as a bug.

Your machines, your gates, your fork

docker compose up, no cloud account. It runs your project's own build and test commands. Apache-2.0: read it, fork it, add a provider with one module and one registry row.

Known limits are written down. Read them before you adopt it →

Install

Docker is the only prerequisite

No Python on the host, no sudo. The script pulls the published images, asks only what it cannot infer from the machine, and leaves the panel at http://localhost:8787.

One line
curl -fsSL https://openfactory.digital/install.sh | sh
read it first curl -fsSL https://openfactory.digital/install.sh -o install.sh && less install.sh && sh install.sh
by hand the commands are in the README, pinned to a release and verified against its checksums

The worker mounts the host's Docker socket to start sandbox containers. That is root-equivalent on the host, the same trade any compose stack that mounts the socket makes.

The installer sends nothing anywhere. There is no phone-home telemetry.

Re-run the installer to upgrade. It pulls the newest release and restarts the stack. Your configuration and data survive.

Then register a project, inside the worker
docker compose --env-file .env.compose exec worker openfactory project init myapp https://github.com/<owner>/myapp.git

That registers the project, creates the board with the platform's columns, and scaffolds .openfactory/project.yaml. openfactory doctor myapp then lists what is still missing, with a remedy for each item, including the two credentials it cannot infer: the coding agent's and a forge token.

Read the code. Run it on your own machines.

Apache-2.0. No cloud account, no telemetry.