Warp Factories infrastructure and security

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. Available controls depend on your team’s configuration and agreement with Warp.

Control plane and execution plane

• Control plane - Warp coordinates runs, identity and configuration, observability, integrations, storage, and inference routing.
• Execution plane - A Warp-hosted or self-hosted sandbox 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["Customer-hosted sandbox"]
  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 or supported<br/>customer-owned storage"]

Self-hosting changes the execution boundary; it does not remove Warp from orchestration. On self-hosted compute, the repository checkout, command execution, and sandbox filesystem stay on customer infrastructure. Content included in prompts, results, transcripts, attachments, artifacts, or telemetry can still flow through Warp and configured providers. Customer-owned provider and storage options change their corresponding paths, not the existence of the control plane. See deployment patterns and self-hosting security and networking for the broader data model.

Environments and runners

Configuration	Defines	Typical contents
Environment	Workspace and runtime context	Repositories, setup, secrets, toolchain image, and provider configuration
Runner	Execution compute	Operating system, architecture, sandbox image, vCPUs, and memory

A run can select a runner explicitly. Otherwise, Warp uses the environment’s configured execution defaults and ultimately the system default. Use environments to define the workspace and the runner reference for compute and resolution behavior. A factory references both through its definition as code.

Choose an execution host

Decision area	Warp-hosted	Self-hosted
Compute	Warp provisions the sandbox	Your team provisions the worker
Checkout and commands	Run on Warp-managed compute	Run on customer-managed compute
Control plane	Runs through Warp	Runs through Warp
Network	Warp manages sandbox connectivity	Outbound connection to Warp; no inbound firewall port
Private services	Must be reachable from the hosted sandbox	Uses the worker’s network access
Operations	Warp manages capacity and lifecycle	Your team manages capacity, isolation, updates, and availability

Self-hosted execution is available to eligible Enterprise teams and currently supports Linux on x86_64 workers. Workers authenticate to Warp with a supported principal. Use a supported runner and review the self-hosting requirements before routing factory work. Do not treat self-hosting as a guarantee that all factory data stays in your network.

Choose execution, inference, and storage independently

Team choice	Boundary changed	What remains in the Warp path
Warp-hosted or self-hosted execution	Where checkout, commands, and the sandbox filesystem run	Coordination, configuration, observability, and inference routing
Warp-managed or customer-supplied inference	Provider account, model routing, billing, and provider-side retention	Run coordination and inference routing
Warp or customer-owned storage	Persistence for supported transcripts, artifacts, and run attachments	Orchestration, the write path, and other factory and control-plane state

Supported customer inference includes first-party model credentials, AWS Bedrock, Google Vertex AI, and OpenAI-compatible custom endpoints. Provider-side retention follows your provider account and contract; Warp does not expose a retention toggle for that provider. Review team-managed model keys and endpoints, Bring Your Own LLM, and the security overview.

Eligible teams can use customer-owned Amazon S3 or Google Cloud Storage for the supported data classes in the table. Warp writes the applicable data to the configured bucket. Your team owns its access and lifecycle policies, but customer-owned storage does not move all factory state into your account.

Credential boundaries

Credential	Where it applies	Boundary
Inference credentials	Model provider requests	Remain at the inference boundary and are not injected into the sandbox
Execution secrets	APIs, package registries, and tools used by an agent	Explicit per-agent allowlist; non-user factory agents default to no managed secrets
Harness authentication	Third-party harnesses such as Claude Code or Codex	Separate from the agent’s general secret allowlist
Repository identity	Checkout and code-forge changes	User authorization for creator attribution or a team executor identity for unattended work

Restrict each credential to the resources and actions its agent needs. Warp redacts known secret values at output boundaries, but redaction does not replace narrow external permissions or rotation. See cloud agent secrets, harness authentication, secret redaction, and team identity for the underlying controls.

Governance and metering

Team Owners and Admins control factory definitions, environments, runners, secrets, and provider configuration through existing team roles. Warp Factories does not add a factory-specific approval role. Specification review and merge approval remain workflow and repository policy decisions. Review factory-definition changes as operational code and keep merge access with the people responsible for shipping.

Warp meters hosted compute, Warp-provided inference, and platform services. Your team supplies self-hosted compute. Customer-supplied providers bill model usage through the applicable provider account, while platform services can still consume credits. See platform credits for the current model.

Deployment checklist

1. Classify the workload - Identify the repositories, data, internal services, and regulated systems the factory can reach.
2. Choose execution - Decide where checkout, commands, and the sandbox filesystem must run.
3. Define environments and runners - Set repositories, setup, secrets, operating system, architecture, image, and compute.
4. Choose inference and storage - Select provider routing and persistence for supported data.
5. Scope credentials - Set each agent’s secret allowlist, harness authentication, and repository identity.
6. Set human gates - Define specification and pull request review in workflow and repository policy.
7. Validate operations - Test network egress, isolation, rotation, redaction, capacity, observability, and metering before increasing volume.