diff --git a/src/assets/agent-platform/cloud-agent-run-lifecycle.png b/src/assets/agent-platform/cloud-agent-run-lifecycle.png new file mode 100644 index 000000000..583957ca0 Binary files /dev/null and b/src/assets/agent-platform/cloud-agent-run-lifecycle.png differ diff --git a/src/assets/agent-platform/cloud-agents-infra.png b/src/assets/agent-platform/cloud-agents-infra.png index b64a2063b..c046659c1 100644 Binary files a/src/assets/agent-platform/cloud-agents-infra.png and b/src/assets/agent-platform/cloud-agents-infra.png differ diff --git a/src/assets/agent-platform/customer-dedicated-saas.png b/src/assets/agent-platform/customer-dedicated-saas.png index 64ead3300..41a242909 100644 Binary files a/src/assets/agent-platform/customer-dedicated-saas.png and b/src/assets/agent-platform/customer-dedicated-saas.png differ diff --git a/src/assets/agent-platform/data-security-boundaries.png b/src/assets/agent-platform/data-security-boundaries.png new file mode 100644 index 000000000..ada3b7a8e Binary files /dev/null and b/src/assets/agent-platform/data-security-boundaries.png differ diff --git a/src/assets/agent-platform/deployment-models.png b/src/assets/agent-platform/deployment-models.png new file mode 100644 index 000000000..38813b646 Binary files /dev/null and b/src/assets/agent-platform/deployment-models.png differ diff --git a/src/assets/agent-platform/factories-work-item-flow.png b/src/assets/agent-platform/factories-work-item-flow.png new file mode 100644 index 000000000..8fdd7bd7a Binary files /dev/null and b/src/assets/agent-platform/factories-work-item-flow.png differ diff --git a/src/assets/agent-platform/self-hosted-execution-flow.png b/src/assets/agent-platform/self-hosted-execution-flow.png new file mode 100644 index 000000000..41a242909 Binary files /dev/null and b/src/assets/agent-platform/self-hosted-execution-flow.png differ diff --git a/src/assets/agent-platform/self-hosted-network-egress.png b/src/assets/agent-platform/self-hosted-network-egress.png new file mode 100644 index 000000000..4687427ee Binary files /dev/null and b/src/assets/agent-platform/self-hosted-network-egress.png differ diff --git a/src/assets/agent-platform/self-hosted-run-sequence.png b/src/assets/agent-platform/self-hosted-run-sequence.png new file mode 100644 index 000000000..370ef57e9 Binary files /dev/null and b/src/assets/agent-platform/self-hosted-run-sequence.png differ diff --git a/src/assets/agent-platform/warp-hosted-data-boundaries.png b/src/assets/agent-platform/warp-hosted-data-boundaries.png new file mode 100644 index 000000000..f017926d0 Binary files /dev/null and b/src/assets/agent-platform/warp-hosted-data-boundaries.png differ diff --git a/src/assets/agent-platform/warp-hosted-run-sequence.png b/src/assets/agent-platform/warp-hosted-run-sequence.png new file mode 100644 index 000000000..a27b10813 Binary files /dev/null and b/src/assets/agent-platform/warp-hosted-run-sequence.png differ diff --git a/src/assets/agent-platform/warp-stack-overview.png b/src/assets/agent-platform/warp-stack-overview.png new file mode 100644 index 000000000..9376c21dd Binary files /dev/null and b/src/assets/agent-platform/warp-stack-overview.png differ diff --git a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx index 1130480de..b516e1313 100644 --- a/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx +++ b/src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx @@ -19,7 +19,9 @@ Warp's cloud agent infrastructure has four key components: 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 ({VARS.DASHBOARD}, session sharing, APIs/SDKs). -{/* TODO: Insert system architecture diagram once received from design team */} +![Warp stack overview diagram showing clients, the Warp control plane, the data plane, Warp-hosted and customer-hosted execution planes, and external systems](../../../../assets/agent-platform/warp-stack-overview.png) + +The [stack overview](/platform/architecture/#stack-overview) reference describes each component in this diagram. ### High-level data flow @@ -136,6 +138,8 @@ Understanding what data stays where is critical for security and compliance deci Consider the following when selecting a deployment model: +![Deployment models diagram comparing Warp-hosted, managed self-hosted, and unmanaged self-hosted patterns by what runs on Warp versus customer infrastructure](../../../../assets/agent-platform/deployment-models.png) + **Warp-hosted** is right if: * You want zero infrastructure management for agent execution. * Your security team is comfortable with SOC 2 Type II certified, ZDR-covered infrastructure. @@ -152,6 +156,7 @@ Consider the following when selecting a deployment model: ## Related resources +* [Architecture reference](/platform/architecture/) - Diagrams of the stack, the run lifecycle, self-hosted execution, and data boundaries * [Deployment Patterns](/platform/deployment-patterns/) - Detailed patterns for CLI-only, {VARS.WARP_AUTOMATION_PLATFORM}-hosted, and self-hosted setups * [Security overview](/enterprise/security-and-compliance/security-overview/) - Data handling, encryption, and compliance details * [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) - Route inference through your own cloud infrastructure diff --git a/src/content/docs/factories/how-factories-work.mdx b/src/content/docs/factories/how-factories-work.mdx index 672e5a475..84c436cc9 100644 --- a/src/content/docs/factories/how-factories-work.mdx +++ b/src/content/docs/factories/how-factories-work.mdx @@ -17,6 +17,19 @@ Deciding which repositories belong in this factory is a separate question. See [ A **work item** is a single request the factory acts on, such as an issue, support request, pull request, or Factory MCP task. It keeps its identity from intake to handoff, however many agents contribute to it along the way. +![Warp Factories system diagram showing work sources, automations, the foreman and stage agents, human handoff, the factory definition, platform execution, the factory dashboard, and the measure-and-improve loop](../../../assets/agent-platform/factories-work-item-flow.png) + +The diagram's components, from intake to improvement: + +* **Work sources** - Work items arrive from [Slack](/factories/integrations/slack/), [GitHub](/factories/integrations/github/), [GitLab](/factories/integrations/gitlab/), [Linear](/factories/integrations/linear/), or [Jira](/factories/integrations/jira/), from local coding agents through the [Factory MCP](/factories/factory-mcp/), or from direct runs and schedules. +* **Automations** - [Automations](/factories/automations/) filter provider events and decide which agent handles them. Schedules fire them on a timer; direct requests go straight to the foreman. +* **Foreman and stage agents** - The foreman holds one conversation per work item and dispatches the Triage, Spec, Implement, and Review agents as the work needs them. See [factory agents](/factories/factory-agents/) and the stages below. +* **Human handoff** - The factory opens a pull request with evidence, updates the original work item, and you review and merge. +* **Factory definition** - Version-controlled agents, automations, runners, and skills define the factory, either Warp-managed or in a GitHub repository your team owns. See [definitions as code](/factories/factory-as-code/). +* **Execution** - Every stage runs as a cloud agent run on Warp-hosted or [self-hosted](/platform/self-hosting/) compute, with the workspace from the factory's repositories and each stage's configured model and [harness](/platform/harnesses/). +* **Factory dashboard** - Metrics, work items by stage, and runs and costs. See the [factory dashboard](/factories/factory-dashboard/). +* **Measure and improve** - [Scorers](/factories/measure-and-improve/) grade completed work, benchmarks compare configurations, and self-improvement turns repeat failures into follow-up pull requests for your review. + ## How a work item moves through the factory The foreman coordinates every work item. It routes work between the factory's agents, passes each one the context it needs, and continues existing agent conversations instead of starting new ones. See [factory agents](/factories/factory-agents/) for what each agent does. diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index c0b07368b..c61ea5503 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -29,6 +29,10 @@ flowchart LR Self-hosting moves only the execution plane: with a managed self-hosted worker, repository checkouts, command execution, and the sandbox filesystem stay on machines you control, but content that enters prompts, results, transcripts, attachments, artifacts, or telemetry still flows through Warp and the providers you configure. See [deployment patterns](/platform/deployment-patterns/) and [self-hosting security and networking](/platform/self-hosting/security-and-networking/) for the broader data model. +The diagram below maps those boundaries for self-hosted execution; factory runs follow the same data model. See the [data security and boundaries](/platform/architecture/#data-security-and-boundaries) reference for a description of each data class. + +![Self-hosted data security and boundaries diagram showing what stays in customer infrastructure, what Warp retains, and what transits Warp to model providers](../../../assets/agent-platform/data-security-boundaries.png) + ## Runners A runner defines the compute a factory's agents work on: the operating system and architecture, the sandbox image, and the instance shape (vCPUs and memory). It's the infrastructure choice you make for a factory. The workspace itself — repositories, setup commands, and secrets — comes from the factory's [definition](/factories/factory-as-code/), and Warp keeps it in step for you. See the [runner reference](/platform/runners/) for the available compute options. diff --git a/src/content/docs/platform/architecture.mdx b/src/content/docs/platform/architecture.mdx new file mode 100644 index 000000000..aeff898e8 --- /dev/null +++ b/src/content/docs/platform/architecture.mdx @@ -0,0 +1,116 @@ +--- +title: Architecture +description: >- + Reference diagrams of the Warp stack, the cloud agent run lifecycle, + self-hosted execution, and data boundaries. +--- +import { VARS } from '@data/vars'; + +The {VARS.WARP_AUTOMATION_PLATFORM} connects the tools that start agent work with the environments where that work runs. Warp operates the control plane, which coordinates runs and routes inference. Cloud agent runs execute in a Warp-hosted sandbox or on customer infrastructure. [Self-hosted](/platform/self-hosting/) execution, [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/), and customer-owned storage change where specific work and data stay. + +## Stack overview + +The platform has five layers: clients, the Warp-operated control plane that coordinates runs, the data plane that stores run data, the execution plane where agents access code and run tools, and external systems that agents read from and write to. + +![Warp stack overview diagram showing clients, the Warp control plane, the data plane, Warp-hosted and customer-hosted execution planes, and external systems](../../../assets/agent-platform/warp-stack-overview.png) + +* **Clients** - The surfaces that start and observe work, like the Warp app, the {VARS.WARP_AGENT_CLI}, the web app, the [factory dashboard](/factories/factory-dashboard/), and clients connected through the [Factory MCP](/factories/factory-mcp/). All clients talk to the same control plane APIs. +* **APIs** - The control plane's entry points: the [Agent API and SDKs](/reference/api-and-sdk/), a webhook receiver for [integration](/platform/integrations/) events, and the hosted Factory MCP endpoint. +* **Control plane** - Warp coordinates runs, manages shared configuration, routes model calls, and records run history. +* **Data plane** - Run data (transcripts, artifacts, and attachments) lives in Warp-managed storage or, on Enterprise plans, in your own Amazon S3, Google Cloud Storage, or Azure Blob Storage bucket. The choice is independent of where runs execute. +* **Warp-hosted execution** - By default, each cloud agent run gets an isolated sandbox prepared from its environment. See [Warp-hosted execution](/platform/warp-hosting/). +* **Self-hosted execution** - On Enterprise, a managed worker runs tasks on your infrastructure. Unmanaged setups run the {VARS.WARP_AGENT_CLI} in your CI or orchestrator. See [Self-hosting](/platform/self-hosting/). +* **External systems** - The platform connects to identity providers, source control, integration providers, model providers, and a payment provider. + +## Cloud agent run lifecycle + +Every cloud agent run follows the same lifecycle, no matter what started it or where it executes. A trigger creates a task, the control plane resolves its configuration and dispatches it to an execution host, the agent works in a loop until it's done, and the run leaves durable records behind. + +![Cloud agent run lifecycle diagram showing triggers, the Warp control plane, the execution sandbox with its agent loop, LLM providers, and output targets](../../../assets/agent-platform/cloud-agent-run-lifecycle.png) + +1. **A trigger fires** - A [schedule](/platform/triggers/scheduled-agents/), an [integration](/platform/integrations/) event, an [API or SDK](/reference/api-and-sdk/) call, a CLI command, or a [Handoff](/platform/handoff/) from the Warp app starts the run. +2. **The task is created** - The control plane opens a run record that tracks the task's state, inputs, and provenance. +3. **Configuration is resolved** - The platform picks the run's [environment](/platform/environments/), [runner](/platform/runners/), execution host, and [model and harness](/platform/harnesses/). +4. **The sandbox is provisioned** - The execution host clones the environment's repositories, runs setup commands, and injects only the [secrets](/platform/secrets/) the run is allowed to use. +5. **The agent loop runs** - The harness gathers context, calls the model, and runs tools until the task is done. Tools run in the sandbox. With the Warp Agent, model calls route through Warp to providers under [Zero Data Retention](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr); Claude Code and Codex call their provider directly. +6. **Outputs land at their targets** - The agent pushes branches, opens pull requests, and replies to the Slack thread, Linear issue, or Jira work item that started the task. +7. **The run record persists** - Transcripts, artifacts, and cost data attach to the run record. +8. **The team has visibility** - Authorized users follow the run in the {VARS.DASHBOARD} or attach to it with [Agent Session Sharing](/agents/local-agents/session-sharing/). +9. **The sandbox tears down** - When snapshotting is enabled, the platform captures workspace changes for a later [Handoff](/platform/handoff/), then destroys the sandbox. + +During the run, prompts and code context, command and tool outputs, MCP tool calls and results, transcripts and run status, and model requests and responses pass through the control plane for session management and inference. + +Self-hosted runs follow the same lifecycle; steps 4 through 6 execute on your managed worker instead of a Warp-hosted sandbox. See [Self-hosted execution flow](#self-hosted-execution-flow) for that variant. + +### Sequence view + +This sequence diagram shows the requests and responses exchanged among a trigger, a per-run sandbox, the Warp control plane, and external providers during a cloud agent run. + +![Warp-hosted run sequence diagram showing numbered request and response flows between the trigger, the per-run sandbox, the Warp control plane, and providers and source control](../../../assets/agent-platform/warp-hosted-run-sequence.png) + +## Self-hosted execution flow + +Self-hosted execution keeps checkout, commands, and the workspace on your infrastructure while the {VARS.WARP_AUTOMATION_PLATFORM} keeps orchestrating, observing, and routing inference. A worker daemon dials out to Warp, so no inbound firewall ports are needed, and executes tasks locally. The numbers in the diagram mark the route. + +![Self-hosted execution architecture diagram showing the managed worker on customer infrastructure connecting outbound to the Warp control plane, with numbered flow steps](../../../assets/agent-platform/self-hosted-execution-flow.png) + +1. **The worker connects** - You run the managed worker (`oz-agent-worker`) on your infrastructure. It authenticates with an agent API key and holds an outbound-only connection, waiting for tasks routed to its [`--host`](/platform/self-hosting/#routing-runs-to-self-hosted-workers) ID. +2. **Warp assigns the task** - When a trigger targets your worker, the control plane sends the task, its resolved configuration, and scoped runtime credentials over that connection. +3. **The agent runs on your backend** - The worker clones repositories, runs setup, injects allowed [secrets](/platform/secrets/), and executes in a Docker container, a Kubernetes Job, or directly on the host, depending on the [backend](/platform/self-hosting/#managed-architecture) you chose. Code, build artifacts, and workspaces stay on your machines. +4. **Run data returns to Warp** - Status, transcripts, artifacts, attachments, and telemetry flow back for the run record. Content the agent puts into prompts or results can include code context; see [security and networking](/platform/self-hosting/security-and-networking/). +5. **Warp routes inference** - With the Warp Agent, model calls go from your worker through Warp to LLM providers under [Zero Data Retention](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr), or through your own provider account with [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/). Claude Code and Codex call their provider directly from your infrastructure. +6. **Your team monitors the run** - Runs on self-hosted workers appear in the {VARS.DASHBOARD} and support [Agent Session Sharing](/agents/local-agents/session-sharing/), the same as Warp-hosted runs. + +### Self-hosted sequence view + +This sequence diagram shows the requests and responses exchanged among a trigger, your worker and sandbox, the Warp control plane, and external providers during a self-hosted run. + +![Self-hosted run sequence diagram showing numbered request and response flows between the trigger, customer infrastructure, the Warp control plane, and providers](../../../assets/agent-platform/self-hosted-run-sequence.png) + +1. **Create task** - A trigger fires: an integration event, a schedule, an API or SDK call, a CLI command, or a Handoff. +2. **Assign task** - The control plane delivers the task over the worker's authenticated connection, with resolved configuration and scoped runtime credentials. +3. **Prepare workspace** - The worker clones repositories, runs setup commands, and injects allowed secrets. +4. **Prompt and context** - The agent gathers context inside the sandbox and sends it for inference. +5. **Inference** - Warp Agent model calls route through Warp to LLM providers under ZDR, or through your own provider account with [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/). +6. **Run tools** - Tool calls execute locally: files, commands, internal services, and MCP servers. +7. **Results** - Transcripts, tool outputs, and lifecycle updates return to the run record. +8. **Outputs** - The agent pushes a branch, opens a pull request, and replies to the integration that started the run. +9. **Observability** - Your team follows and steers the run from the dashboard and shared sessions. + +## Warp Factories work-item flow + +A software factory assembles the {VARS.WARP_AUTOMATION_PLATFORM}'s primitives — runs, environments, runners, integrations, and secrets — into one measurable workflow. Work enters from the tools your team already uses, a foreman coordinates specialized agents through the stages each work item needs, and a human makes the final call. + +![Warp Factories system diagram showing work sources, automations, the foreman and stage agents, human handoff, the factory definition, platform execution, the factory dashboard, and the measure-and-improve loop](../../../assets/agent-platform/factories-work-item-flow.png) + +[How Warp Factories work](/factories/how-factories-work/) explains each component in the diagram and how a work item moves through the stages. + +## Data security and boundaries + +Every run moves a few distinct classes of data, and each class has its own boundary. This section maps them across your infrastructure, the Warp platform, model providers, and the data plane where run data is stored. All communication is encrypted in transit (TLS 1.2+), all stored data is encrypted at rest (AES-256), and known secret values are redacted at output boundaries. + +![Warp-hosted data security and boundaries diagram showing repositories, clients, and integrations in customer infrastructure, the per-run sandbox and control plane on the Warp platform, model providers, and the Warp-managed or customer-owned data plane](../../../assets/agent-platform/warp-hosted-data-boundaries.png) + +* **Source code** - For Warp-hosted runs, repositories are cloned into an isolated per-run sandbox and destroyed with it; Warp does not persistently store repository clones or train on your code. For [self-hosted execution](/platform/self-hosting/), checkout and the workspace stay on your infrastructure. Either way, code context the agent puts into prompts, transcripts, or artifacts transits Warp and may persist as run data. +* **Prompts and context** - With the Warp Agent, model calls route through Warp to LLM providers under [Zero Data Retention](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements: providers don't retain or train on the traffic. [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) keeps the same route but uses your provider account. Claude Code and Codex call their provider directly from the execution environment, under your provider agreement rather than Warp's. +* **Run data** - Transcripts, artifacts, and run attachments are stored in Warp-managed storage, encrypted at rest and access-controlled by your team's roles. Enterprise teams can instead write them to a customer-owned Amazon S3, Google Cloud Storage, or Azure Blob Storage bucket. Warp writes with a service identity you authorize on the bucket policy, so no cloud credentials are shared. The choice is independent of where runs execute. +* **Control-plane data** - Warp always retains what it needs to operate the platform: user and organization settings, agent and factory configuration, orchestration and lifecycle metadata, trigger and integration metadata, operational logs, and usage and billing. +* **Execution secrets** - Secrets you inject locally never transit Warp. [Managed secrets](/platform/secrets/) are stored encrypted and fetched just-in-time by the execution environment with a run-scoped token, and each delivery is audit-logged. [Secret redaction](/support-and-community/privacy-and-security/secret-redaction/) at output boundaries is a backstop, not a substitute for narrow scopes and rotation. +* **Inference credentials** - With the Warp Agent and Bring Your Own LLM, provider credentials are used only at the Warp–provider boundary and never enter the sandbox. Claude Code and Codex use your provider credentials inside the execution environment, delivered as managed secrets or injected locally. +* **MCP credentials** - OAuth-connected and URL-backed MCP servers are proxied through the control plane, so their credentials stay with Warp. Command-based servers run inside the execution environment with local or managed secrets. Direct connections from the execution environment to URL-backed servers are in early access. +* **Repository identity** - Agents check out and push with scoped repository credentials, and pull requests are attributed to the creating user or to the agent, depending on the configured [credential strategy](/factories/factory-as-code/#credentialstrategy). Branch protection and repository permissions apply as usual. + +### With self-hosted execution + +[Self-hosted execution](/platform/self-hosting/) moves the execution boundary: checkout, builds, and command execution stay on your infrastructure, and no Warp-hosted sandbox is involved. The control plane still coordinates runs, holds control-plane data, and routes Warp Agent inference. Run data goes to Warp-managed storage or your own bucket, the same as for Warp-hosted runs. + +![Self-hosted data security and boundaries diagram showing what stays in customer infrastructure, what Warp retains, the Warp-managed or customer-owned data plane, and what transits Warp to model providers](../../../assets/agent-platform/data-security-boundaries.png) + +## Related pages + +* [Deployment patterns](/platform/deployment-patterns/) - Choose between CLI-only, Warp-hosted, and self-hosted deployments. +* [Self-hosting overview](/platform/self-hosting/) - Managed vs unmanaged architectures and setup guides. +* [Self-hosting security and networking](/platform/self-hosting/security-and-networking/) - The data model and egress requirements for self-hosted workers. +* [Security overview](/enterprise/security-and-compliance/security-overview/) - Warp's data handling, encryption, and compliance posture. +* [How Warp Factories work](/factories/how-factories-work/) - The work-item lifecycle in depth. +* [Warp Factories infrastructure and security](/factories/infrastructure-and-security/) - The same boundaries applied to factories. diff --git a/src/content/docs/platform/deployment-patterns.mdx b/src/content/docs/platform/deployment-patterns.mdx index 8ee707406..5f35d060a 100644 --- a/src/content/docs/platform/deployment-patterns.mdx +++ b/src/content/docs/platform/deployment-patterns.mdx @@ -10,6 +10,8 @@ import { VARS } from '@data/vars'; Teams adopt cloud agents in a few repeatable ways. This page outlines the most common architectures, what they're good for, and how they fit together. +![Deployment models diagram comparing Warp-hosted, managed self-hosted, and unmanaged self-hosted patterns by what runs on Warp versus customer infrastructure](../../../assets/agent-platform/deployment-models.png) + ## Quick mental model Cloud agent setups usually have four moving parts: @@ -64,7 +66,9 @@ Use this when you already have a system that schedules work (CI, dev boxes, inte Use this when you want the {VARS.WARP_AUTOMATION_PLATFORM} to run agent workloads on Warp-managed infrastructure, typically inside reproducible Docker environments, with built-in lifecycle management. -![Warp enterprise SaaS architecture showing customer infrastructure, isolated tenant sandboxes, Warp backend, and LLM providers](../../../assets/agent-platform/cloud-agents-infra.png) +![Warp-hosted execution architecture showing customer infrastructure, triggers and integrations, isolated tenant sandboxes, the Warp control plane, and LLM providers](../../../assets/agent-platform/cloud-agents-infra.png) + +See the [cloud agent run lifecycle](/platform/architecture/#cloud-agent-run-lifecycle) reference for a description of each component in the architecture. ### What it looks like diff --git a/src/content/docs/platform/overview.mdx b/src/content/docs/platform/overview.mdx index 2e0fe0882..086d791b8 100644 --- a/src/content/docs/platform/overview.mdx +++ b/src/content/docs/platform/overview.mdx @@ -78,6 +78,7 @@ Runs pick up your team's shared setup no matter what triggered them: [MCP server ## Where to go next +* [Architecture](/platform/architecture/) - reference diagrams of the stack, the run lifecycle, and data boundaries. * [Cloud agents](/platform/) - what cloud agents are, how they get triggered, and how to run them with or without the Warp app. * [Cloud agents quickstart](/platform/quickstart/) - run your first cloud agent in about ten minutes. * [Environments](/platform/environments/) - define the toolchain and repos a run executes against. diff --git a/src/content/docs/platform/self-hosting/index.mdx b/src/content/docs/platform/self-hosting/index.mdx index df73af7ad..38bd5e5e7 100644 --- a/src/content/docs/platform/self-hosting/index.mdx +++ b/src/content/docs/platform/self-hosting/index.mdx @@ -34,7 +34,7 @@ Self-hosting has two architectures. The core distinction is **who orchestrates a | **Automatic environment setup** | Yes (via Warp [environments](/platform/environments/)) | No (you manage it) | | **Session tracking and steering** | Yes | Yes | -The two architectures are not mutually exclusive. Some teams run managed workers for integration-triggered work and unmanaged agents in CI pipelines. +The two architectures are not mutually exclusive. Some teams run managed workers for integration-triggered work and unmanaged agents in CI pipelines. The deployment models diagram on [Deployment patterns](/platform/deployment-patterns/) compares what runs where in each model. ## How self-hosting works @@ -42,7 +42,9 @@ Warp uses a split-plane architecture: **execution happens on your infrastructure If your security requirement is "repository clones and execution must stay on our infrastructure," self-hosting is designed for that. If your requirement is "no code context can ever route through Warp or an external LLM provider," review [Security and networking](/platform/self-hosting/security-and-networking/) with your Warp account team before deploying. -![Self-hosted Oz architecture showing customer-managed execution with Oz orchestration](../../../../assets/agent-platform/customer-dedicated-saas.png) +![Self-hosted execution architecture showing the managed worker on customer infrastructure connecting outbound to the Warp control plane](../../../../assets/agent-platform/customer-dedicated-saas.png) + +The [self-hosted execution flow](/platform/architecture/#self-hosted-execution-flow) reference explains each numbered step in the diagram. With any self-hosted architecture: diff --git a/src/content/docs/platform/self-hosting/security-and-networking.mdx b/src/content/docs/platform/self-hosting/security-and-networking.mdx index 5b22cef4a..cc6c2fd63 100644 --- a/src/content/docs/platform/self-hosting/security-and-networking.mdx +++ b/src/content/docs/platform/self-hosting/security-and-networking.mdx @@ -38,6 +38,8 @@ Repositories are cloned and stored only on your infrastructure, but code content Self-hosted agents **do not require any network ingress**. They require outbound (egress) access to the following services: +![Self-hosted worker network egress diagram showing outbound-only connections from customer infrastructure to Warp backend endpoints, Docker Hub, Google Cloud Storage, and GitHub](../../../../assets/agent-platform/self-hosted-network-egress.png) + **Warp's backend (all architectures):** * `app.warp.dev` — port 443 @@ -111,6 +113,7 @@ LLM inference routes through Warp's backend. With Warp-managed inference, reques ## Related pages * [Self-hosting overview](/platform/self-hosting/) — Managed vs unmanaged and architecture decision guide. +* [Data security and boundaries](/platform/architecture/#data-security-and-boundaries) — Diagrams of where each class of data lives and travels. * [Security overview](/enterprise/security-and-compliance/security-overview/) — Warp's broader security model, including ZDR. * [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) — Route inference through your own cloud provider accounts. * [Self-hosted worker reference](/platform/self-hosting/reference/) — CLI flags and config schema, including every security-relevant option. diff --git a/src/sidebar.ts b/src/sidebar.ts index 3a1ebed4a..b36e94f08 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -623,6 +623,7 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ // 'Warp-hosted agents' under its own opposite. label: 'Deployment & hosting', items: [ + { slug: 'platform/architecture', label: 'Architecture' }, { slug: 'platform/deployment-patterns', label: 'Deployment patterns' }, { slug: 'platform/warp-hosting', label: 'Warp-hosted agents' }, // Qualified: a bare 'Overview'/'Quickstart' would now read as the