About factory infrastructure and security

Warp Factories separates execution, inference, and credential boundaries. You choose where code runs, which providers serve inference, and which credentials each agent receives. Warp coordinates the work and stores transcripts and artifacts.

Control plane and execution plane

Warp manages coordination, while a Warp-hosted sandbox or a worker on your infrastructure executes the work. These responsibilities form the control plane and execution plane:

• 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 can contain code context. The diagram’s inference path applies to the Warp Agent; Claude Code and Codex call their providers directly from the execution environment. See deployment patterns, execution security, and data security and boundaries for details.

Runners

A runner selects the operating system, architecture, sandbox image, and vCPU and memory shape. The factory’s definition supplies repositories, setup commands, and secrets. Its agentDefaults.runner sets the default runner, which agents and automations can override.

The execution host determines how runner settings apply; self-hosted runner settings don’t provision capacity. See Runner settings by execution host for the setting-by-setting comparison.

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.

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

Managed self-hosting requires an Enterprise plan. See the managed prerequisites for worker credentials and network access, and the Self-hosting quickstart to connect a worker.

Workers run on linux/amd64 and linux/arm64. The runner must match the worker’s platform; workerHost selects the connected worker for factory runs.

For a working definition with workerHost set and a platform-matched runner, see 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.

Managed self-hosting structures

The worker backend sets isolation and scheduling on your infrastructure:

Backend	How factory runs execute
Docker (default)	In a separate Docker container on the worker host
Kubernetes	As a Kubernetes Job in the worker’s namespace
Direct	In a separate workspace on the worker host, sharing its OS and kernel

For backend selection guidance, including Command and one-shot Direct options, see Choosing a managed backend.

Choose inference independently

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

Inference options for factory runs

Factory agents execute as cloud agents. For runs using the Warp Agent, support varies by inference option:

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 charges your available usage
Team-managed keys and endpoints	Supported on Business and Enterprise	Shared OpenAI, Anthropic, or Google keys, or an OpenAI-compatible endpoint	Warp stores credentials encrypted and uses them only at the inference boundary, never in the worker or run environment
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	Not supported for factory runs	Interactive inference in your Google Cloud project	Gemini Enterprise BYOLLM currently supports interactive agent requests only

Personal BYOK and personal custom inference endpoints are stored on a 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. Your provider’s retention follows your account and contract; 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 from the Warp Agent	Used only at the Warp–provider 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	Used inside the execution environment for direct provider calls; 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

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, harness authentication, Secret Redaction, and team 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 usage. Self-hosting removes Warp-hosted compute charges. Your provider bills customer-supplied inference. Neither removes applicable platform charges. External inference bills are not fully represented in Warp’s totals.

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 for Warp Factories - Compare execution models
• Runners for Warp Factories - Configure compute and worker compatibility
• Self-hosting overview - Review managed backends and setup requirements
• Security and networking - Review data boundaries, egress, and backend controls
• Team-managed LLM API keys and endpoints - Configure inference credentials
• Roles and permissions - Govern team and workspace resources
• Platform usage - Understand agent-hour charges