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

# Warp Factories infrastructure and security

Warp Factories separate control and execution planes so teams can choose hosting, inference, storage, secret, and governance controls.

Warp Factories separates coordination from execution. Your team can choose where a factory runs code, which supported providers serve model requests, where supported factory data is stored, and which credentials each agent receives.

Note

Warp Factories is currently in closed beta. Available infrastructure and security controls depend on your team’s configuration and agreement with Warp.

## Control plane and execution plane

A factory uses two connected infrastructure planes. The boundary determines where code runs and which data moves between your infrastructure, Warp, and configured providers.

-   **Control plane** - Warp coordinates work items and agent runs, resolves factory and agent configuration, manages run identity, records observability data, and routes model inference. The control plane also connects factory runs to integrations, storage, and the control room.
-   **Execution plane** - An isolated sandbox checks out source code, runs setup steps, invokes tools, builds the project, and executes commands. The sandbox can run on Warp-hosted compute or on self-hosted compute that your team operates.

The execution choice does not move the control plane. A self-hosted factory still uses Warp to coordinate runs and exchange the information needed to operate them.

For Warp-hosted execution, the repository checkout and commands run in an isolated sandbox on Warp-managed infrastructure. For self-hosted execution, the repository checkout, command execution, and sandbox filesystem stay on customer-managed compute. In both cases, prompts, factory and run configuration, results, transcripts, attachments, artifacts, and telemetry can interact with the Warp control plane and configured providers.

Customer-owned inference and storage options change the applicable provider and persistence boundaries. They do not make the factory an offline system or remove Warp from orchestration. Code context can appear in prompts, command output, results, and transcripts as agents work, even when the repository checkout stays on self-hosted infrastructure.

Review [deployment patterns](../platform/deployment-patterns) for the broader platform architectures and [self-hosting security and networking](../platform/self-hosting/security-and-networking) for detailed data boundaries.

## Environments and runners

Environments and runners configure different parts of execution:

| Configuration | Defines | Typical contents |
| --- | --- | --- |
| **Environment** | The workspace and runtime context an agent receives | Repositories, setup commands, secrets, toolchain image, and cloud provider configuration |
| Runner | The compute used to execute the workspace | Operating system, CPU architecture, sandbox image, vCPUs, and memory |

An environment answers, “What does this agent need to do its work?” A runner answers, “What compute should execute that work?”

An environment can define execution defaults, while a run can select a runner explicitly when the work needs a different operating system, architecture, image, or compute size. Otherwise, Warp uses the environment’s configured execution defaults and ultimately the system default. See the [runner reference](../platform/runners) for full resolution behavior. This separation lets one repository setup serve both routine tasks and resource-intensive builds without duplicating the environment.

Use [environments](../platform/environments) to define repositories, setup, secrets, and provider access. Use [runners](../platform/runners) to define execution compute. The [factory definitions as code](./factory-as-code) page explains how a factory references these resources.

## Choose Warp-hosted or self-hosted execution

Warp-hosted and self-hosted execution use the same factory coordination model. The operational and data boundaries differ.

| Decision area | Warp-hosted execution | Self-hosted execution |
| --- | --- | --- |
| **Compute ownership** | Warp provisions and operates the sandbox infrastructure | Your team provisions and operates the worker infrastructure |
| **Source checkout and commands** | Run on Warp-managed compute | Run on customer-managed compute |
| **Control plane** | Warp coordinates runs, observability, and inference routing | Warp coordinates runs, observability, and inference routing |
| **Network model** | Warp manages sandbox connectivity | Workers initiate outbound connections to Warp; no inbound firewall port is required |
| **Internal network access** | Requires access from the hosted sandbox | Uses the network access available to your worker |
| **Compute metering** | Warp-hosted compute is metered | Customer supplies the compute |
| **Operational responsibility** | Warp manages sandbox capacity and lifecycle | Your team manages capacity, isolation, updates, and availability |

Choose Warp-hosted execution when the factory can run on Warp-managed infrastructure and your team does not want to operate workers. Choose self-hosted execution when repository checkout, builds, commands, or access to private services must remain on customer-managed compute.

Self-hosted workers connect outbound to Warp to receive work and report run state. They do not require an inbound firewall rule. Repository checkout, command execution, and the sandbox filesystem stay on your compute. Content included in prompts, results, transcripts, attachments, artifacts, or telemetry can flow through Warp and configured providers unless a corresponding customer-owned provider or storage option changes that part of the path.

Self-hosting supports the platform boundary documented in the [self-hosting overview](../platform/self-hosting/). Use that guide to select a supported deployment architecture and review its operational requirements. Do not treat self-hosting as a guarantee that all factory data stays in your network.

Caution

Self-hosted factory execution is available only to Enterprise teams and currently supports Linux on x86\_64 workers. Use a supported runner and review the [self-hosting requirements](../platform/self-hosting/) before routing factory work to customer-managed compute.

Self-hosted execution is available to eligible Enterprise teams. Workers authenticate to Warp with a supported principal. Infrastructure operators are responsible for worker credentials, capacity, isolation, updates, and availability.

## Bring your own inference and storage

Teams can separate model and data ownership from execution hosting. These controls are independent: self-hosted compute does not require customer-supplied inference, and customer-owned storage does not require self-hosted compute.

### Inference routing

For supported factory models, teams can use:

-   **First-party provider credentials** - Route supported model requests through credentials managed for your team.
-   **AWS Bedrock and Google Vertex AI** - Route supported model requests through configured cloud provider accounts.
-   **Custom endpoints** - Route supported models through an OpenAI-compatible endpoint.
-   **Warp-managed inference** - Let Warp provide and meter the model request.

Inference credentials stay at the inference boundary. They are separate from the secrets injected into an execution sandbox. This prevents an agent process from receiving a provider credential solely because the factory uses that provider.

See [team-managed model keys and endpoints](../enterprise/enterprise-features/team-managed-keys-and-endpoints) and [Bring Your Own LLM](../enterprise/enterprise-features/bring-your-own-llm) for supported provider patterns. Provider-side retention depends on your provider account and contract. Review the [security overview](../enterprise/security-and-compliance/security-overview) and your provider terms rather than assuming a configurable retention setting in Warp.

### Customer-owned storage

Eligible teams can configure customer-owned Amazon S3 or Google Cloud Storage for supported transcripts, artifacts, and run attachments. Warp remains in the orchestration and write path for this data. Your team owns the bucket, access policy, retention policy, and lifecycle rules.

Customer-owned storage changes where these supported data classes are persisted. It does not move all factory or control-plane state into your account, and it does not remove the data from the control-plane flow that produces and writes it. Confirm eligibility, covered data classes, access model, and retention requirements with your Warp account team before deployment.

## Scope secrets and credentials

Factory agents often need package registry tokens, service credentials, API keys, or authentication for a selected harness. Use separate credentials for separate purposes and grant the minimum access required for each role.

-   **Explicit agent allowlists** - Attach only the named managed secrets that an agent needs. A triage agent that only reads issues does not need the deployment credentials used by an implementation agent.
-   **No default secrets for non-user agents** - Factory agents that do not run on behalf of a user start with no managed secrets. Add each required secret explicitly.
-   **Separate harness authentication** - Credentials for third-party harnesses, such as Claude Code or Codex, use dedicated harness authentication secrets. They do not depend on the agent’s general secret allowlist.
-   **Output redaction** - Warp redacts known secret values at output boundaries. Redaction reduces accidental disclosure in results and transcripts, but it does not replace narrow credentials, external service permissions, or rotation.

Read [cloud agent secrets](../platform/secrets) for storage and scoping behavior, [harness authentication](../platform/harnesses/authentication) for third-party harness credentials, and [secret redaction](../support-and-community/privacy-and-security/secret-redaction) for output handling.

Repository credentials also need an attribution strategy. User-initiated work can use the initiating person’s authorization when your workflow requires creator attribution. Unattended factory work uses an executor identity configured for the team. The selected identity determines which repositories the run can access and how resulting changes are attributed. Restrict executor access to the repositories and actions the factory requires. See [team access, billing, and identity](../platform/team-access-billing-and-identity) for the available authorization models.

## Permissions and governance

Warp team Owners and Admins control factory configuration and shared resources, including factory definitions, environments, runners, secrets, and provider configuration. Use the existing [team roles and permissions](../enterprise/team-management/roles-and-permissions) to limit who manages these resources.

Warp Factories does not add a separate factory-specific role or a per-stage approval role. Define consequential decisions in the workflow and repository policy:

-   **Specification decisions** - Require human review when requirements, product behavior, or technical constraints need judgment.
-   **Merge decisions** - Keep pull request merge access with the people and repository controls responsible for shipping code.
-   **Factory changes** - Review version-controlled factory definitions through the same change-management process you use for other operational code.
-   **Credential changes** - Limit provider, storage, and execution credentials to designated administrators and rotate them under your organization’s policy.

These are workflow and repository policy decisions, not factory-specific RBAC enforcement. Humans remain responsible for specifications, merges, and infrastructure changes. See [factory agents](./factory-agents) for agent responsibilities and [measure and improve](./measure-and-improve) for evidence used to review factory changes.

## Metering and billing boundaries

Factory usage can include inference, compute, and platform metering:

-   **Warp-hosted compute** - Warp meters the sandbox resources used for hosted execution.
-   **Self-hosted compute** - Your team supplies and pays for worker compute. Warp does not meter that infrastructure as Warp-hosted compute.
-   **Inference routing** - Warp meters model usage when Warp provides inference. Customer-supplied providers bill model usage under the applicable provider account, while requests can still route through the Warp control plane.
-   **Platform services** - Coordination, integrations, run lifecycle, observability, and APIs can consume platform credits for both hosted and self-hosted cloud runs.

Plan terms and rates can change. Use [platform credits](../support-and-community/plans-and-billing/platform-credits) and [team access, billing, and identity](../platform/team-access-billing-and-identity) for the current public billing model.

## Deployment checklist

Before sending production work to a factory:

1.  **Classify the workload** - Identify which repositories, data, internal services, and regulated systems the factory can reach.
2.  **Choose the execution boundary** - Select Warp-hosted or self-hosted execution based on where source checkout, builds, and commands must run.
3.  **Define environments and runners** - Encode the required repositories, setup, secrets, operating system, architecture, image, and compute size.
4.  **Choose inference and storage** - Decide whether to use Warp-managed or customer-supplied inference and whether supported factory data belongs in customer-owned storage.
5.  **Scope identities and secrets** - Give each agent an explicit secret allowlist, separate harness authentication, and the appropriate creator or executor repository identity.
6.  **Set human decision points** - Define when the factory must request specification input, hand off a pull request, or stop for review. Enforce merge policy in your code forge.
7.  **Validate operations and cost** - Test network egress, sandbox isolation, credential rotation, output redaction, worker capacity, observability, and the expected metering path before increasing workload volume.

Revisit this checklist when you add an agent, repository, provider, integration, runner, or new class of work. Infrastructure boundaries are part of the factory’s operating definition, not a one-time deployment choice.