> For the complete documentation index, see [llms.txt](https://docs.warp.dev/llms.txt).
> Markdown versions of each page are available by appending .md to any URL.

# Warp Factories infrastructure and security

Warp Factories gives you control over inference and execution hosting while Warp stores run records, transcripts, and outputs.

Warp Factories runs on the infrastructure your team chooses. You decide where a factory runs code, which model providers serve its inference requests, and which credentials each agent receives. Warp coordinates the work and stores run data such as transcripts and artifacts.

## Control plane and execution plane

Every factory splits responsibilities across two planes:

-   **Control plane** - Warp coordinates runs, identity and configuration, observability, integrations, storage, and inference routing.
-   **Execution plane** - A Warp-hosted sandbox or a managed self-hosted worker checks out code, runs setup, invokes tools, builds the project, and executes commands.

flowchart LR
  I\["Integrations and triggers"\] --> C\["Warp control plane<br/>coordination · identity/config<br/>observability · inference routing"\]
  C --> H\["Warp-hosted sandbox"\]
  C -->|"task, config, and scoped<br/>runtime credentials"| S\["Managed self-hosted worker"\]
  H -->|"results, transcripts,<br/>artifacts, telemetry"| C
  S -->|"results, transcripts, attachments,<br/>artifacts, and telemetry<br/>can contain code context"| C
  C --> P\["Warp-managed or<br/>customer-configured inference"\]
  C --> D\["Warp-managed storage"\]

With managed self-hosting, repository checkouts, commands, and sandbox files stay on machines you control. Prompts, results, transcripts, attachments, artifacts, and telemetry still flow through Warp and configured providers. See [deployment patterns](https://docs.warp.dev/factories/deployment-patterns/), [execution security](https://docs.warp.dev/platform/execution-security/), and the [data security and boundaries](https://docs.warp.dev/platform/architecture/#data-security-and-boundaries) reference for details.

![Self-hosted data security and boundaries diagram showing what stays in customer infrastructure, what Warp retains, and what transits Warp to model providers](https://docs.warp.dev/_astro/data-security-boundaries.Cwu738rC_1A4aQ4.webp?dpl=dpl_7LutmzBiFsSjJNvKWSQuQLgcfrsy)

## Runners

A runner selects the operating system, architecture, sandbox image, and vCPU and memory shape. The factory’s [definition](https://docs.warp.dev/factories/factory-as-code/) supplies repositories, setup commands, and secrets. Define runners in `runners/*.yaml`; `agentDefaults.runner` sets the default, and agents and automations can override it. The execution host determines how each setting is used:

| Setting | Warp-hosted | Direct | Kubernetes | Docker |
| --- | --- | --- | --- | --- |
| `platform.os`, `platform.arch`, `platform.mac.version` | Selects the sandbox OS, architecture, and macOS VM version | Does not configure the host; the worker host determines the platform | Use Linux; the cluster and `pod_template` schedule nodes | Use Linux; the Docker daemon determines the architecture |
| `platform.linux.dockerImage` | Linux sandbox image | Ignored | Task and setup container image | Task container image |
| `platform.linux.registryCredentialSecretName` | Warp-managed private-registry credential | Ignored | Ignored; use `imagePullSecrets` | Ignored; configure registry credentials on the worker, such as in its Docker config |
| `instanceShape` | Sandbox size, subject to plan limits; omitted uses the workspace default | Ignored; the task uses host resources | Task-container requests and limits; overrides matching `pod_template` resources; omitted keeps template or cluster defaults | Task-container limits; omitted adds no limits |

Self-hosted runner settings don’t provision capacity. Worker configuration controls resources, registry authentication, volumes, placement, and backend policy. See [runner compute options](https://docs.warp.dev/factories/runners/) for available configurations.

## Choose an execution host

A factory runs its work on one of two execution hosts: Warp-hosted compute or a worker in the [managed self-hosting architecture](https://docs.warp.dev/factories/self-hosting/#managed-architecture).

| Decision area | Warp-hosted | Managed self-hosted |
| --- | --- | --- |
| **Compute** | Warp provisions the sandbox | Your team provisions the worker |
| **Checkout and commands** | Run on Warp-managed compute | Run on your infrastructure |
| **Network** | Warp manages sandbox connectivity | The worker connects outbound to Warp; no inbound firewall port |
| **Private services** | Must be reachable from the hosted sandbox | Reachable through the worker’s network access |
| **Operations** | Warp manages capacity and lifecycle | Your team manages capacity, isolation, updates, and availability |

To route factory work to a managed self-hosted worker (an Enterprise feature):

1.  **Deploy a worker** - Review the [self-hosting requirements](https://docs.warp.dev/factories/self-hosting/), then connect a worker that authenticates to Warp with a self-hosted worker API key. Workers run on `linux/amd64` and `linux/arm64`, and the worker’s platform determines which workloads it can run.
2.  **Pair it with a compatible runner** - Choose a runner that matches the worker’s platform.
3.  **Select the worker in the factory definition** - Set [`workerHost`](https://docs.warp.dev/factories/factory-as-code/) so the factory routes work to it.

For a working definition with `workerHost` set and a platform-matched runner, see [`07-self-hosted-worker`](https://github.com/warpdotdev/warp-factory-examples/tree/main/examples/07-self-hosted-worker).

Unmanaged self-hosted agents and other CLI agents can’t serve as a factory’s execution host, but they can exchange work with a factory through [Factory MCP](https://docs.warp.dev/factories/factory-mcp/).

### Managed self-hosting structures

The worker backend sets isolation and scheduling on your infrastructure:

| Structure | How factory runs execute | What your team operates | Use it when |
| --- | --- | --- | --- |
| **[Docker](https://docs.warp.dev/factories/self-hosting/managed-docker/)** (default) | In a separate Docker container on the worker host | The worker daemon, host, Docker daemon, images, capacity, and container policy | Docker is available and you want per-run container isolation without Kubernetes |
| **[Kubernetes](https://docs.warp.dev/factories/self-hosting/managed-kubernetes/)** | As a Kubernetes Job in the worker’s namespace | The worker deployment, cluster, namespace RBAC, scheduling, admission policy, and capacity | Your team already operates Kubernetes or needs cluster-native policy and scheduling |
| **[Direct](https://docs.warp.dev/factories/self-hosting/managed-direct/)** | In a separate workspace directly on the worker host, sharing its OS and kernel | The worker daemon, host security, dependencies, capacity, and cleanup | A container runtime isn’t available or runs need direct access to host resources |

## Choose inference independently

Execution hosting doesn’t select inference. Configure that boundary separately.

### Inference options for factory runs

Factory agents execute as cloud agents, so only inference options that support cloud agent runs apply:

| Option | Support for factory runs | Team controls | Key boundary |
| --- | --- | --- | --- |
| **Warp-managed inference** | Supported | The model selected for each agent | Warp provides the provider account and bills model usage with Warp credits |
| **[Team-managed keys and endpoints](https://docs.warp.dev/enterprise/enterprise-features/team-managed-keys-and-endpoints/)** | Supported on Business and Enterprise | Shared OpenAI, Anthropic, or Google keys, or an OpenAI-compatible endpoint | Warp stores the encrypted credential and uses it only at the inference boundary; it never enters the worker or run environment |
| **[BYOLLM: AWS Bedrock](https://docs.warp.dev/enterprise/enterprise-features/byollm-aws-bedrock/)** | Supported on Enterprise | The AWS account, IAM role, available Claude models, and provider billing | Warp assumes your IAM role through OIDC; inference runs in your AWS account |
| **[BYOLLM: Gemini Enterprise](https://docs.warp.dev/enterprise/enterprise-features/byollm-gemini-enterprise/)** | Not supported for factory runs | Interactive inference in your Google Cloud project | Gemini Enterprise BYOLLM currently supports interactive agent requests only |

Self-serve BYOK and custom inference endpoints are stored on an individual member’s device and don’t apply to factory runs. With team-managed keys and endpoints, select a specific provider model or endpoint; Auto continues to use Warp-managed inference. When you supply the provider, its retention follows your account and contract, and Warp can’t enforce ZDR for that provider.

## Credential boundaries

A factory handles four kinds of credentials, each with its own boundary:

| Credential | Used for | Boundary |
| --- | --- | --- |
| **Inference credentials** | Model provider requests | Used only at the inference boundary; never injected into the sandbox |
| **Execution secrets** | APIs, package registries, and tools an agent uses | Delivered from an explicit per-agent allowlist; factory agents that don’t act as a specific user receive no managed secrets by default |
| **Harness authentication** | Third-party harnesses such as Claude Code or Codex | Configured separately from the agent’s secret allowlist |
| **Repository identity** | Checking out code and pushing changes | Runs act with the creating user’s authorization (changes are attributed to them) or as the agent itself for unattended work; set by the definition’s [`credentialStrategy`](https://docs.warp.dev/factories/factory-as-code/#credentialstrategy) |

Scope each credential to the resources and actions its agent needs. Warp redacts known secret values at output boundaries, but redaction is a backstop, not a substitute for narrow external permissions and rotation. See [cloud agent secrets](https://docs.warp.dev/platform/secrets/), [harness authentication](https://docs.warp.dev/platform/harnesses/authentication/), [secret redaction](https://docs.warp.dev/support-and-community/privacy-and-security/secret-redaction/), and [team identity](https://docs.warp.dev/platform/team-access-billing-and-identity/) for the underlying controls.

## Factory roles and permissions

Factory creation uses the team-level Warp Factories role. Team and workspace admins and team-level Editors can create factories.

Three roles govern an existing factory:

-   **User** - View and run the factory, and propose definition changes.
-   **Editor** - Edit the factory definition, configure its agents, repositories, and automations, attach existing integrations, secrets, and MCP servers, and select existing runners.
-   **Admin** - Manage members, delete the factory, and force-merge a blocked definition change.

Team and workspace admins and owners always have the Admin role. Admins for a factory manage its roles; team and workspace admins manage the team-level role.

Managing shared runners and connecting team-wide integrations and providers require team or workspace permission. Factory roles don’t control specification or pull request review. Treat factory definition changes as operational code, and protect merges through repository settings.

## Metering

Warp meters hosted compute, Warp-provided inference, and platform services. Self-hosting moves compute costs to your infrastructure; customer-supplied inference bills your provider account. Platform services still consume credits. See [platform credits](https://docs.warp.dev/support-and-community/plans-and-billing/platform-credits/) for details.

## Deployment checklist

1.  **Classify access** - Inventory repositories, data, and services.
2.  **Set boundaries** - Choose execution and inference hosts.
3.  **Scope credentials** - Configure allowlists, harness authentication, and repository identity.
4.  **Enforce review** - Protect factory-definition and pull request merges.
5.  **Validate operations** - Test egress, isolation, rotation, capacity, observability, and metering.

## Related pages

-   [**Deployment patterns**](https://docs.warp.dev/factories/deployment-patterns/) - Compare Warp-hosted, managed self-hosted, and CLI-only execution.
-   [**Managed self-hosting**](https://docs.warp.dev/factories/self-hosting/) - Choose a worker backend and follow its setup guide.
-   [**Execution security**](https://docs.warp.dev/platform/execution-security/) - Review data boundaries, network egress, and backend-specific controls.