Architecture and deployment

Warp’s architecture separates the control plane (orchestration, observability, and LLM inference) from the execution plane (where agents run, code is accessed, and commands execute). This separation gives enterprise teams flexibility to choose where sensitive workloads run while maintaining centralized management and visibility.

Use this information to evaluate which deployment model fits your organization’s security, compliance, and operational requirements.

System architecture overview

Warp’s cloud agent infrastructure has four key components:

1. Trigger - What starts an agent run (CI step, webhook, cron schedule, Slack mention, CLI command, or API/SDK call).
2. Orchestration - What decides what to run and tracks it (Automation Platform orchestrator or your own system).
3. Execution - Where the agent actually runs (Warp-hosted environment, your infrastructure, or your existing CI/orchestrator).
4. Visibility - How the team monitors and intervenes (cloud agent dashboard, session sharing, APIs/SDKs).

The stack overview reference describes each component in this diagram.

High-level data flow

• Warp terminal (client) ↔ Warp backend (control plane) ↔ LLM providers
• The Warp backend handles task orchestration, observability, and LLM inference routing.
• The execution plane is where source code is accessed, commands run, and build artifacts are produced. This can run on Warp’s infrastructure or yours.

Warp-hosted (SaaS)

Warp-hosted is the default deployment model. Agents run on Warp-managed infrastructure with no setup required from your team.

How it works

• Agents execute in isolated Docker containers on Warp-hosted infrastructure (GCP).
• The Automation Platform orchestrator manages agent lifecycle - provisioning, execution, monitoring, and cleanup.
• Environments are ephemeral and destroyed after each run.

Triggers

Warp-hosted agents can be triggered by:

• First-party integrations - Slack, Linear, and other connected tools
• Scheduled agents - Cron-like automation for recurring work
• CLI - oz agent run-cloud for on-demand cloud execution
• API/SDK - Programmatic triggers from your own systems

When to use

• You want the simplest path to scalable cloud agent execution.
• You need to run many tasks in parallel without building sandboxing infrastructure.

Self-hosted execution

Warp supports running agent tools on your infrastructure. Inference and session data still transit Warp’s servers.

Note

Self-hosted execution is available exclusively on Warp’s Enterprise plan.

Split architecture

Self-hosted deployments use a split architecture:

• Execution plane (customer-hosted) - Repository clones, build artifacts, and agent tools run on your infrastructure. Code context, commands, and output can be included in LLM prompts and session transcripts that route through Warp’s servers (see What transits Warp’s servers).
• Control plane (Warp-hosted) - Task orchestration, observability data, and LLM inference route through Warp’s servers.

Deployment modes

Unmanaged - Use oz agent run to run agents in your existing orchestrator or CI environment. Supports Linux, macOS, and Windows with no Docker dependency.

• Best for teams that already have CI/CD infrastructure or internal orchestrators.
• You control scheduling, scaling, and environment setup.
• Warp provides cloud connectivity, shared context, visibility, and session sharing.

Managed - Run the oz-agent-worker daemon to let Warp orchestrate agents in isolated Docker containers on your infrastructure.

• The worker process connects to the Automation Platform via WebSocket and receives tasks automatically.
• Agents run in isolated Docker containers managed by the worker.
• You get the same orchestration capabilities as Warp-hosted, but execution stays on your infrastructure.

Network requirements

Self-hosted agents require outbound-only network access. No inbound network access is required.

Egress requirements:

• Outbound access to Warp’s backend services (for orchestration and observability)
• For managed mode: access to Docker Hub and GitHub (for container images and repository access)

When to use

• You need agent tools to run in your own execution environment.
• You want the Automation Platform‘s orchestration and visibility with customer-hosted compute.

Hybrid deployments

Organizations can combine Warp-hosted and self-hosted execution to balance convenience with security requirements.

How it works

• Route tasks that need your execution environment to self-hosted agents.
• Route less sensitive workloads (e.g., open-source tooling, internal utilities) to Warp-hosted agents.
• Both execution modes share the same cloud agent dashboard, session sharing, and API/SDK visibility.

Example configurations

• By sensitivity - Production repositories run on self-hosted agents; staging and development run on Warp-hosted.
• By team - Security-sensitive teams (e.g., infrastructure, payments) use self-hosted; other teams use Warp-hosted.
• By task type - Scheduled maintenance tasks run on Warp-hosted; ad-hoc debugging runs self-hosted in dev environments.

Data flow and boundaries

Understanding what data stays where is critical for security and compliance decisions.

What stays on customer infrastructure (self-hosted)

• Source code - Repository contents and version history
• Build artifacts - Compiled outputs and generated files
• Runtime secrets - Environment variables and credentials

Agent prompts, transcripts, and output can contain code or other data from that environment and transit Warp’s servers.

What transits Warp’s servers

• Task orchestration - Scheduling, routing, and lifecycle management
• Observability data - Run status, duration, and metadata
• LLM inference - Prompts and responses (which include code context from agent interactions) routed through Warp to LLM providers
• Session sharing data - Session transcripts, which include code context from agent interactions, when session sharing is enabled for monitoring and collaboration

Choosing a deployment model

Consider the following when selecting a deployment model:

Warp-hosted is right if:

• You want zero infrastructure management for agent execution.
• You need maximum parallelization and scalability.

Self-hosted is right if:

• You need to integrate with existing CI/CD or infrastructure tooling.
• You want full control over the execution environment.

Hybrid is right if:

• Different teams or repositories have different security requirements.
• You want the convenience of Warp-hosted for most work but need self-hosted for sensitive workloads.

Related resources

• Architecture reference - Diagrams of the stack, the run lifecycle, self-hosted execution, and data boundaries
• Deployment Patterns - Detailed patterns for CLI-only, Automation Platform-hosted, and self-hosted setups
• Private networking - Connect private LLM gateways and MCP servers to Warp-hosted services
• Security overview - Data handling, encryption, and compliance details
• Bring Your Own LLM - Route inference through your own cloud infrastructure
• Admin Panel - Configure agent policies and security settings
• Contact sales - Discuss deployment options for your organization