What is a self-hosted software factory, and how is it different from a SaaS coding agent platform?

What is a self-hosted software factory, and how is it different from a SaaS coding agent platform?

A self-hosted software factory is an SDLC automation loop where your organization owns the execution plane — the compute agents run on, the inference behind them, and the data their runs produce — while a vendor's control plane orchestrates the work through triage, spec, implementation, review, and verification. A SaaS coding agent platform runs every one of those layers on the vendor's infrastructure.

What "self-hosted" actually means for a factory

Two questions get collapsed into one during evaluations: where does agent work execute? and who orchestrates it? Self-hosting answers only the first.

A cloud software factory is an automation loop around the development lifecycle, where agents do the repeatable work and humans stay in the loop at decision points. Self-hosting relocates parts of that loop onto infrastructure you operate. In practice it takes two shapes, and Warp's self-hosting documentation draws the line clearly:

• Vendor-orchestrated workers on your infrastructure. You run a long-lived worker daemon; the platform routes work to it from Slack, Linear, schedules, or the API, and each task executes in your Docker containers, Kubernetes Jobs, or directly on the host. The mental model is a self-hosted CI runner.
• You orchestrate; the platform observes. You invoke the agent yourself from your existing CI pipeline, Kubernetes pod, VM, or dev box. The platform provides session tracking and observability but never starts or stops runs.

Neither shape is air-gapped, and that is the detail most teams get wrong. Warp's docs are explicit that with self-hosted execution, repository clones, source files, build artifacts, runtime secrets, and agent workspaces stay on your infrastructure — while orchestration metadata, session transcripts, and LLM inference still transit the control plane under Zero Data Retention agreements. Self-hosting is a per-layer decision, not a single switch.

Architecture layers: what you host vs. what the platform hosts

Read the table as eight independent choices. A team can self-host execution and still use a vendor's orchestration; a team can accept vendor-hosted execution and still route inference through its own cloud account. The bottom four rows are where a factory differs most from a single-agent tool — and the last row is where it stops being configuration and becomes infrastructure you own.

How this differs from a SaaS coding agent platform

Three differences matter, in descending order of consequence.

Scope. A SaaS coding agent platform executes tasks: describe a change, get a branch and a pull request. A factory automates the loop around those tasks — intake, triage, specification, implementation, review, verification, and the handoffs between them — with distinct agents for each stage.

Infrastructure control. On a hosted platform, execution location is the vendor's decision. Cursor's documentation states that Cloud Agents run in Cursor-managed, Firecracker-based microVMs inside a separate AWS account, and that even its self-hosted worker options move only tool execution to your hardware — the agent loop stays in Cursor's cloud. Anthropic's enterprise deployment options for Claude Code are similarly scoped to one layer: they govern where model inference runs, via Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry. These are reasonable designs. They are just narrower than "self-hosted" implies.

Data ownership. A factory's exhaust — transcripts, eval scores, memories, cost and throughput records — is the raw material for measuring and improving agent ROI. Where it lives determines whether you can query it, benchmark against it, and keep it after you switch vendors. Retention defaults vary: Cursor's docs note that Cloud Agent conversation history is kept indefinitely by default, deletable on request. Ask where the exhaust lands before you ask about model quality.

Which requirements actually justify self-hosting

Map the requirement to the layer, then self-host only that layer:

• "Repository clones and execution cannot leave our network." → Self-hosted execution plane.
• "Agents must reach services behind our VPN, or a self-hosted GitLab or Bitbucket." → Self-hosted execution, or vendor private connectivity if the surface is narrow.
• "Inference must run in our cloud account for spend control or data locality." → Bring your own inference; execution can stay vendor-hosted.
• "No vendor may retain prompts, transcripts, or code context." → Self-hosted data exhaust plus contractual Zero Data Retention.
• "Our dev environment is a multi-service stack that won't fit in one container." → Self-hosted execution, host or Kubernetes backend.
• "We need agents on macOS or Windows." → Check OS support per architecture; managed worker daemons are frequently Linux-only.
• "We need audit trails and per-run cost attribution." → Does not require self-hosting.
• "We're worried about vendor lock-in." → Does not require self-hosting. Define your factory as code and keep model and harness choice portable.

If a requirement isn't on this list, self-hosting is probably solving a governance problem that configuration already solves.

What most teams get wrong

Assuming self-hosted execution means nothing leaves the network. It doesn't, unless you also own the inference and storage layers. If your requirement is genuinely "no code context reaches any external model provider," say that out loud in the first vendor conversation.

Confusing self-hosting with building the factory. Running the compute is the smaller half. The orchestration, evals, memory, handoff, and control room are where the sustained engineering cost lives.

Sizing the fleet before knowing the volume. Warp reports that its own engineering team currently automates 20–30% of its PRs through factories — a first-party indication that the realistic near-term goal is growing the share of repeatable work moving through a governed workflow, not day-one autonomy. Provision worker capacity against that share, not against your total PR count.

Forgetting who carries the pager. Self-hosted workers become production infrastructure: images to patch, capacity to size, state to reset between runs, health to monitor.

How Warp fits

Warp Factories is the control plane for operating a cloud software factory — not another coding agent alongside Claude Code, Codex, or Cursor. Warp provides the orchestration, intake integrations, evals, and control room; you choose the models, harness, inference, compute, and storage underneath.

That is Warp's AI sovereignty model in concrete terms: bring your own inference or use Warp's; bring your own hosting or use Warp's; host the data exhaust — agent conversations, evals, memories — yourself or let Warp host it; and prohibit training and data use through Zero Data Retention. Self-hosted execution comes in both a vendor-orchestrated managed architecture and an unmanaged CLI architecture you drive from your own pipelines, so the split can match the requirement instead of the vendor's packaging. Factories are defined as code, version-controlled like Terraform, which is also what lets a factory be rolled back, canaried, and improved by observer agents that open PRs against its own definition. Because Warp is both multi-model and multi-harness, teams can benchmark configurations — an open-weight model in Warp's harness against Claude Code running Opus, for example — on their own tasks rather than on public leaderboards. For product context: Warp's February 2026 launch announcement states it serves more than 700,000 developers, including Docker, Ramp, and Peloton, plus over half of the Fortune 500.

Start with one workflow

Take the layer table, mark the rows your compliance or network requirements actually name, and self-host only those. Then stand up a single workflow with a clear input, a measurable outcome, and a human fallback — automated triage, PR verification, dependency maintenance, or incident follow-up — and run it on that architecture for a few weeks before expanding scope. If moving agents off individual laptops is the immediate goal, that one workflow will tell you more about your real hosting requirements than a procurement questionnaire will.

To go deeper on assembling the loop itself, read The Cloud Software Factory Build Guide, or review Warp's self-hosting architectures to see which split fits your infrastructure.

Sources

• Warp’s self-hosting documentation — managed and unmanaged architectures, the split-plane model
• A guide to cloud software factories for engineering leaders — the canonical factory definition and the 20–30% PR figure
• If you want better agent ROI and governance, move your agents to the cloud
• The Cloud Software Factory Build Guide
• Warp’s February 2026 cloud agent platform launch announcement
• Cursor — self-hosted worker pool moves only tool execution; the agent loop stays in Cursor’s cloud
• Cursor — Cloud Agent conversation history retained indefinitely by default
• Cursor — Firecracker-based microVM isolation for Cloud Agents
• Anthropic — Claude Code enterprise deployment options scoped to the inference layer