Open infrastructure for cloud software factories
build on Warp: factories as code, any model or harness, with evals, benchmarks, and self-improvement built in.
224 tasks · 0 active · 1,422 PRs shipped
Your software factory, defined in code.
Factories-as-code allows for a versioned and measured approach to optimizing costs and performance of your factories.
The Factory definition is the shared foundation for every agent. It connects repositories, credentials, work sources, and cloud access, then sets the execution choices agents inherit.
schemaVersion: v1alpha1name: web-server-factorydescription: Autonomous software-development factory for a web application.alias: web-factoryThe alias is the Foreman’s @-mention handle in Slack and Linear, so teammates can route work to the Factory by name. It can differ from the Factory name.repositories: - owner: acme name: web-server - owner: acme name: web-clientRepositories define where Factory agents can work. Each run checks out the relevant code on its execution host so agents can inspect and change it.secrets: - DEPLOY_API_TOKENSecrets give agents protected credentials for the tools and services they need. Values are encrypted at rest and injected as environment variables only during runs.mcpServers: sentry: warpId: YOUR_MCP_SERVER_IDMCP servers connect every agent to shared tools such as Sentry or internal services. Each named connection references a centrally managed server.cloudProviders: aws: roleArn: arn:aws:iam::123456789012:role/factory-agentCloud providers securely connect Factory agents to cloud accounts and resources for infrastructure work. Federated access lets runs assume an AWS role or use a GCP identity without embedding long-lived cloud keys in the definition.integrations: - type: slack - type: linearIntegrations connect the Factory to work sources such as Slack and to Linear or Jira for task tracking, so the Foreman can coordinate work where your team already works.agentDefaults: model: auto runner: standardAgent defaults establish the model or harness, runner, and environment that roles inherit, while specialized agents can override those choices when needed.
Beyond CI/CD to automating the whole SDLC
defined in code, built for scale, and easy to deploy.
How work moves through a factory
issues land from the channels your team already uses, the foreman moves them down the line, and the line stops wherever you decide.
the foreman carries this issue down the line — watch for the f badge
Cutting our cost per PR from $80 to $30
How we used Warp Factories Benchmarks to test models on our own engineering tasks and optimize for cost without sacrificing quality.
read case study
Open at every layer
Any agent
any MCP-capable coding agent.
Any model
frontier or open-weight, chosen per pipeline stage.
Your compute or ours
warp's cloud, or self-hosted in your own VPC.
Data lives where you want
you own and store what your factory produces.
Baked-in measurement and self-improvement
evals, benchmarks, and self-improvement loops drive measurable gains.
Evals on your own work
Benchmarks across models
Self-improvement loops
"warp factories drove our cost per agent pr down by 30%."
Control your coding agent chaos
continuous improvement, better governance and security, by default.
increase agent roi · cost per pr
Status advances on a shared clock; no agent is ever idle.
agents prove their work with computer use
every factory agent captures a screenshot or video so you can verify its work before shipping a PR.
Activations dropped on the contact sales page this week. Can you investigate and fix the culprit?
On it — opening the browser to test the flow myself...
to your team
Enter your work email and answer one question — we'll get you to the right person on our team.
Trusted by over 800,000 developers and thousands of engineering teams at leading companies
Found it — the testimonials section was hidden by collapsing divs. Patched, PR #436 is up for review.
The factory infrastructure you'd build yourself
available now, so your eng time goes into your product, not the plumbing. tick a box to clear the desk (drag the pile around on desktop).
Frequently asked questions
a factory is a fleet of agents wired to your SDLC — triggered by an issue, a slack message, or a schedule, and coordinated by warp factories from triage through review to a mergeable PR.
as code, in a factory.yaml + supporting agent files. define triggers, agents, models, and approval gates — check it into your repo like any other config.
no. bring your own model or harness (e.g. claude code or codex) — warp factories works with whatever your team prefers and helps identify the most cost-effective configuration over time.
no. factories is a separate product — nobody at your company has to use warp terminal. work comes in through tools you already use, like slack, linear, jira, github, and gitlab. if you do use warp terminal, it has built-in factory integrations (native mcp) so you can iterate locally.
most orgs start around 20-30% of PRs fully automated, starting with simple tasks. over time this goes up as models improve and your factory self-improves.
wherever you choose — warp's cloud, or fully self-hosted inside your own VPC, under your existing retention and compliance rules.
humans put work into the factory via your existing tools like slack, teams, linear, jira, github and gitlab. at any time you can iterate on that work locally and the factory agents loop you in proactively when they need help.
yes — most teams start with a single low-risk workflow, like dependency bumps or flaky test triage, before expanding coverage.
usage-based, priced per agent run.