How do you set up a self-hosted software factory in your own cloud environment?

How do you set up a self-hosted software factory in your own cloud environment?

To set up a self-hosted software factory, resolve six decisions in order: who orchestrates runs, where execution happens, what outbound access you allow, where inference comes from, which single intake-to-PR workflow goes first, and where the data exhaust is stored. Repository clones, build artifacts, and secrets stay on your infrastructure; orchestration is the layer you point at them.

What self-hosting actually changes — and what it doesn't

Self-hosting a factory is a split-plane deployment: execution moves onto your infrastructure, orchestration usually doesn't. Getting that boundary written down first prevents most of the rework that happens later, because every subsequent decision — network policy, credentials, storage, audit — inherits from it.

Per Warp's self-hosting documentation, self-hosted agents require no inbound network access — the worker dials out — and repository clones, build artifacts, and workspaces stay on infrastructure you control, while orchestration metadata, session transcripts, and inference requests route through the control plane under Zero Data Retention agreements.

This matters for scoping: if your actual requirement is "execution and code clones must stay inside our boundary," a self-hosted factory is designed for that. If it's "no code context may ever transit a third party," that's an architecture conversation to settle before you provision anything, not a configuration flag.

Step 1: decide who orchestrates before you provision compute

There are two shapes, and the difference is who starts and stops runs — not who owns the compute.

• A managed worker. You run a long-lived worker daemon on your own hosts. It connects out to the control plane and waits for work, then executes each task in an isolated Docker container, a Kubernetes Job, or directly on the host. Slack mentions, Linear comments, schedules, and API calls all route to it — conceptually similar to a self-hosted CI runner. Per Warp's docs, this architecture is Linux-only today.
• Your own orchestrator. You invoke the agent CLI directly from an existing CI pipeline, Kubernetes pod, VM, or dev box. Runs are still tracked and steerable, but you own triggering. This path works on Linux, macOS, and Windows with no container-runtime dependency.

The two are not exclusive, and the practical pattern for most platform teams is both: a managed worker for integration-triggered work, plus CLI invocations inside existing pipelines. One consequence worth planning for — because the managed worker is Linux-only today, verification runs that must exercise a macOS build go through the CLI path on a Mac host.

The six-phase self-hosted factory setup sequence

Each phase has an explicit exit gate. Don't start the next one until the previous one passes.

Phase 2 is where most first attempts stall, so make the egress list explicit before your network team asks for it. Self-hosted workers need outbound 443 to the control plane's app, session, and real-time hostnames; a managed worker also needs a registry path for the agent task image, plus the browser-sidecar image only if you're enabling computer-use verification, and a harness sidecar image if you run Claude Code or Codex as the harness. If your repositories are hosted internally, that's the payoff: a self-hosted worker inherits the host's network reach, so it can clone from a private GitLab or Bitbucket instance, hit an internal database, or reach a VPN-only service.

Where inference and data exhaust actually live

These are two separate choices, and self-hosting the runtime doesn't decide either one for you.

For inference, the default is hosted routing under Zero Data Retention agreements with contracted model providers. Enterprise teams that need inference to leave through their own cloud accounts can use bring-your-own-LLM, which per Warp's docs currently applies to interactive agents, with cloud agent support coming — so confirm current status against your compliance requirement rather than assuming parity today.

For data exhaust, decide storage location and retention for transcripts, eval results, and agent memories at the same time you decide compute. This is the asset that makes a factory improve: without a retained run history you can't score a change to a model, a skill, or a prompt, and you lose the raw material that self-improving review loops depend on.

What most teams get wrong when self-hosting a factory

• Forgetting to pin intake to the worker. Standing up the worker isn't enough. Schedules, Slack, Linear, API calls, and web-initiated runs each specify a host, and anything unpinned quietly executes on hosted infrastructure — a compliance gap that produces no error message.
• Treating self-hosted as air-gapped. Execution is local; orchestration and inference still egress. Say that plainly in the security review instead of discovering it during one.
• One shared credential for every agent role. A triage agent needs to read issues and comment. An implementation agent needs to push branches. Issuing one token for both is the laptop-sprawl problem rebuilt in the cloud.
• Choosing direct-host execution for convenience. It's the right call for stacks that don't fit a container, but it shares the host kernel between tasks. Choose it on purpose, not by default.
• Self-hosting the whole loop at once. Triage, spec, implement, and review each have distinct permissions and failure modes. Assembling the full loop is a separate problem, covered in the Cloud Software Factory Build Guide; self-hosting one role first keeps the two problems from compounding.

How Warp Factories fits

Warp Factories provides the control plane for this: the factory definition lives in version-controlled code, so the whole configuration — agent roles, skills, MCP servers, permissions, and which model or harness each role uses — can be reviewed, rolled back, or canaried like any other infrastructure change. Runs execute on the host you designate, and the control room shows every live and historical run, work-item status, and configuration in one place, with metrics and evals queryable through the API or the Factory MCP.

The differentiator for a self-hosting team is that the same environment definition works on your workers or on hosted compute, and model, harness, inference, hosting, and data-exhaust storage stay independent choices you can change later. For product context: Warp's February 2026 cloud agent platform launch announcement states it serves 700,000+ developers, including Docker, Ramp, and Peloton, and over half of the Fortune 500.

Start with one workflow, then widen the boundary

Pick one workflow with a clear input, a measurable outcome, and a human fallback — issue triage, PR review, dependency maintenance, or incident follow-up — and run it end to end on your own compute before adding a second agent role. In its guide to cloud software factories for engineering leaders, Warp reports that its own team currently automates 20–30% of its PRs through factories; the useful read for a platform engineer is that the target isn't full autonomy on day one, it's a growing share of repeatable work moving through a governed path you control.

Concretely: get one worker running on one host, route one triage job to it, and confirm the run appears in the control room with the code never leaving your network. If self-hosted execution needs to be enabled for your team, that's an Enterprise configuration — talk to your account team before phase 1 rather than after.

Sources

• Warp’s self-hosting documentation — architecture overview
• Warp self-hosting security and networking documentation
• Warp self-hosting quickstart
• Warp self-hosting unmanaged (CLI-driven) architecture
• A guide to cloud software factories for engineering leaders — the 20–30% automation figure
• The Cloud Software Factory Build Guide
• How to build a cloud software factory — self-improving code review
• How to build a cloud software factory — computer use verification
• Warp’s February 2026 cloud agent platform launch announcement