Automation Platform > Cloud Agents
Cloud Agent FAQs
# Cloud Agent FAQs This page answers common questions about cloud agents, including where they run, how they're configured, and how teams use cloud agents for day-to-day engineering work. ## Architecture and execution ### Where do cloud agents run? What's the architecture? Agents run either **locally** (inside your Warp session) or **in the cloud** as a **cloud agent run**, inside an **environment** (see [Environments](/platform/environments/)). The cloud agents platform is built around modular, observable execution: - A **trigger** starts work (manual, schedule/cron, webhook, or an integration like Slack/GitHub). - The **agent** executes inside an **environment** (either a Warp-hosted cloud sandbox, or a **self-hosted sandbox** on your infrastructure, depending on plan/support). - Every step is recorded: **transcripts, tool calls, logs, and outputs**, so work is auditable and debuggable instead of a black box. The same agent can be invoked consistently across entry points (Warp conversation, cloud agent web app, the CLI, API/SDK, Slack/GitHub triggers) without rewriting the underlying instructions. ### What exactly are cloud agents in Warp? A **cloud agent** is a packaged automation unit made up of: - **Instructions** — A reusable skill/prompt (what it should do). - **Profile** — Model selection + tools + permissions (how it operates). - **Trigger** — Manual, cron/schedule, webhook, or integration event (when it starts). - **Environment** — Repo access, dependencies (Docker image), secrets, setup commands, and runtime config (where it runs). - **Host** — Local (interactive) or cloud (run), and optionally self-hosted execution (where supported). Because the agent definition is modular, the same cloud agent can be started from different surfaces (terminal, web app, CLI, integrations) with a consistent interface. ### Can we intervene mid-run? Yes. For **cloud agent runs**, you can: - Inspect **run state**, tool calls, and logs. - **Steer** the agent while it's running. - Unblock it with additional instructions or context. If you're not happy with where it landed, you can take over to finish the task. That human handoff is a core part of making agents reliable beyond demos. ### Do cloud agents have access to Codebase Context and indexing? Yes. [Codebase Context](/agents/capabilities/codebase-context/) is enabled for all cloud agent runs, as long as Codebase Context is enabled for your account. This includes runs triggered from the CLI, API/SDK, integrations (Slack, Linear, GitHub Actions), and schedules. No additional configuration is needed — if Codebase Context is enabled, cloud agents use it automatically. ### Can I access a shell inside a cloud agent environment? Are there limitations (Docker, Playwright, etc.)? Yes. Cloud agent runs execute in a full Linux environment and behave like a local development session. You can install dependencies, run Docker, and use headless tools like Playwright, subject to standard sandbox resource limits. ### Do cloud agents run as root inside the container? No. By default, cloud agents run as a dedicated non-root `agent` user (UID/GID 1000 where available) with passwordless sudo. If your environment's image sets a non-root `USER`, Warp runs the agent as that user instead, unchanged. For images that start as root, commands that need root access, like `apt-get install`, work with a `sudo` prefix. See [configuring container users](/platform/environments/configuring-environments/#configure-container-users) for details on home directory location, file ownership, and fallback behavior. ### Do cloud agents support a fully self-hosted, on-prem, or offline mode? The cloud agents platform supports self-hosting the **agent sandbox** (the execution environment) on your own infrastructure. The **control plane**—which handles orchestration, tracking, and auditability—remains Warp-managed and is not self-hosted. Self-hosted execution is available on **Enterprise** plans. See [Self-hosting](/platform/self-hosting/) and [Deployment patterns](/platform/deployment-patterns/) for details. :::note Self-serve [Bring Your Own API Key (BYOK)](/agents/inference/bring-your-own-api-key/) does not apply to cloud agents. Keys you add yourself are stored locally on your device and can't be passed to cloud-hosted or self-hosted agent runs, so those runs consume [Warp credits](/support-and-community/plans-and-billing/credits/). Enterprise teams are the exception: an admin can configure [team-managed API keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) that are stored server-side by Warp and used by cloud agents. Those runs still consume [platform credits](/support-and-community/plans-and-billing/platform-credits/) for orchestration. ::: ## Models ### Which models are supported? Cloud agents are **multi-model by design**. You can choose models based on cost, latency, and capability, and teams commonly mix models by workflow: - Faster/cheaper models for triage and routine tasks. - Stronger models for complex changes (refactors, multi-file work, deeper reasoning). Model choice is configurable per **agent** (and often per environment/workflow), depending on how you set up your profiles. ### Can I choose which model cloud agents use? Yes. Cloud agents support the same set of models available in Warp. Model selection is configurable per agent or environment. ### Can I authenticate cloud agents with my own ChatGPT or Claude Pro / Max plan? We're strong proponents of this, but it ultimately depends on model provider policies. We're actively working with providers to explore whether direct third-party authentication is possible. ### Do you support local or private LLMs for compliance or air-gapped environments? Enterprise plans can route inference through your own cloud-provider account via [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/), so prompts stay within your cloud environment. Fully local, offline LLM execution is difficult given the current cloud agents orchestration and runtime architecture, but private-model support via enterprise cloud providers is available through BYOLLM. ### Will cloud agents support Agent-to-Agent Protocols (A2A)? It’s something we’re actively exploring. Our focus is on building durable orchestration primitives—runs, environments, observability, steering, and coordination—that can support A2A and other emerging standards over time. ## Security and billing ### Will cloud storage for agent definitions, runs, and conversations be secure and encrypted? Yes. All cloud agent data stored in the cloud is encrypted at rest and in transit, and protected by Warp account–level access controls. Cloud agent environments are sandboxed by default, with scoped access to repos, secrets, and compute. Security and isolation are first-class design constraints for the cloud agent runtime. ### Are cloud agents included in the Build plan, or is it a separate add-on? Cloud agents are included in the Build plan. Usage is metered via credits, with pricing based on agent runs and resource consumption. Concurrency limits and credit allocation details are still being finalized. ### How do cloud agents handle API keys and secrets for agents? Secrets are managed via the cloud agents CLI. Secrets are encrypted at rest, scoped to your Warp account, and injected into the agent environment at runtime. They are never hard-coded into agent instructions or logs. To learn more about how secrets work in practice, see [Cloud Agent Secrets](/platform/secrets/). ## Workflows ### How do agents handle branching, merge conflicts, and multi-agent coordination with cloud agents? The cloud agents platform is intentionally flexible. As the developer, you decide how agents should branch, coordinate, and resolve conflicts. Interactive agents can plan work and spawn subagents to parallelize tasks. Cloud agents provide the building blocks for [running and coordinating multiple concurrent agents](/platform/orchestration/), rather than enforcing a fixed workflow. ### Why focus on orchestration primitives instead of immediately adopting new agent standards? We believe durable infrastructure matters more than transient standards. The cloud agents platform is designed to provide stable building blocks—agent runs, environments, auditability, steering, and coordination—that orchestration frameworks and emerging standards can plug into over time. ### Can cloud agents integrate with external tools, APIs, or services (like n8n connectors)? Yes, and cloud agents do not rely on rigid, predefined workflows. Agents can install CLIs, call external APIs, use MCP servers, and access the internet directly. The intent is to delegate flexibility to agents rather than constrain them with fixed connectors. ### Can I export agent conversations and runs from cloud agents? Yes. Conversations can be copied directly from the UI. The cloud agent CLI and API also provide access to full conversation text, logs, and outputs programmatically. ### How do cloud agents handle environment access, files, and security compared to SSH-based setups? Access is handled through Warp session sharing rather than SSH keys. Authentication is tied to Warp accounts and access controls, enabling secure person-to-person sharing. Configuration files and credentials can be managed using encrypted .env workflows (for example, dotenv-style encryption), avoiding repeated manual decrypt/encrypt cycles. ### Can cloud agents review PRs like a teammate? Yes. Common patterns for a **cloud agent** in PR review: - Summarize changes and intent. - Flag risky diffs and edge cases. - Suggest tests and missing coverage. - Propose refactors for maintainability. A typical workflow is: the agent leaves structured review comments and optionally opens a follow-up PR for mechanical fixes (or commits to the branch, if you choose to allow that). ### Can cloud agents write unit tests? Yes, especially when: - The repo has a consistent test framework. - The **environment** is reproducible (dependencies and setup are reliable). The strongest loop is: a cloud agent generates tests, runs them in the environment, iterates until green, then opens a PR with the tests plus a short explanation of coverage and assumptions. ### Can cloud agents do big refactors? It can help, but the best practice is to scope into smaller, reviewable chunks. Agents are strongest when they can continuously validate progress (tests, lint, typecheck). For large refactors, a staged approach with checkpoints (and possibly multiple subagents for parallel exploration) tends to work better than one giant prompt. ### Can cloud agents triage issues / tickets automatically? Yes. A common cloud agent workflow: - When a ticket/issue is created (via integration trigger), a cloud agent gathers context (recent changes, logs/metrics links, ownership). - Proposes labels/priority and likely causes. - Drafts next steps or a response. - Asks clarifying questions back to the reporter when needed. ### Can cloud agents do dependency upgrades? Yes. Scheduled dependency bumps are a classic cloud agent use case: - Open a PR. - Run tests. - Resolve simple conflicts. - Attach a risk summary (optional). This is usually implemented as a scheduled **cloud agent** producing recurring **runs**. ### Can cloud agents keep docs up to date? Yes. With cloud agents, agents can: - Scan for drift (commands that no longer work, onboarding steps that changed). - Run validations in a docs/test environment. - Propose doc updates as PRs. This is most successful with “docs as code” workflows (GitBook/Mintlify/Docusaurus style), where updates go through normal review. ## Self-hosting ### Where does my source code go with self-hosted agents? With self-hosting, repositories are cloned and stored only on your infrastructure — Warp never hosts your codebase. Warp uses a split architecture: * **Execution plane (your infrastructure)** — Repository clones, build artifacts, runtime secrets, and container filesystem state stay on the machines you control. * **Control plane (Warp-hosted)** — Session transcripts (which include code context from agent interactions), orchestration metadata, and LLM inference route through Warp's backend under [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements. Warp does not persistently store your source code or use it for model training. See [Self-hosting](/platform/self-hosting/) for deployment options and [Security Overview](/enterprise/security-and-compliance/security-overview/) for full details. ### Can I use `oz agent run` in CI or existing runners? Yes. The [unmanaged architecture](/platform/self-hosting/unmanaged/) is designed exactly for this. Run `oz agent run` in any environment where you can execute a CLI command — GitHub Actions, Jenkins, Buildkite, Kubernetes pods, or custom orchestrators. This is how the [`warpdotdev/oz-agent-action`](https://github.com/warpdotdev/oz-agent-action) GitHub Action works. The agent runs locally on the runner and its session is tracked on Warp's backend for observability. ### Can self-hosted agents access services behind a VPN? Yes. Since self-hosted agents run on your infrastructure, they inherit your network access. This means agents can reach self-hosted GitLab/Bitbucket instances, internal APIs, databases, and any other services behind your VPN. This is one of the primary reasons teams choose self-hosting. ### Does self-hosting work with GitLab or other non-GitHub SCMs? Self-hosted agents can use any SCM accessible from your infrastructure. With the [unmanaged architecture](/platform/self-hosting/unmanaged/), agents run directly on your host and use whatever Git configuration and SCM access is already available. With the [managed architecture](/platform/self-hosting/#managed-architecture), automatic environment setup currently focuses on GitHub, but you can configure access to other SCMs via volume mounts, environment variables, setup commands, or Kubernetes Secrets (when using the [Kubernetes backend](/platform/self-hosting/managed-kubernetes/)). See the [GitLab](/platform/integrations/gitlab/) and [Bitbucket](/platform/integrations/bitbucket/) setup guides for step-by-step instructions. ### Do LLM requests still go through Warp with self-hosting? Yes. LLM inference routes through Warp's backend, which has [Zero Data Retention (ZDR)](/enterprise/security-and-compliance/security-overview/#zero-data-retention-zdr) agreements with all contracted model providers. Enterprise teams that need full control over inference routing can use [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through their own cloud provider accounts. AWS Bedrock BYOLLM supports both interactive agents and cloud agent runs; [Gemini Enterprise (Vertex AI)](/enterprise/enterprise-features/byollm-gemini-enterprise/) BYOLLM currently applies to interactive agents, with cloud agent support coming. ### What about large monorepos with long environment setup times? The [unmanaged architecture](/platform/self-hosting/unmanaged/) is well-suited for large monorepos because agents run directly in your pre-provisioned environment — there is no Docker image build or repo cloning step. For the [managed architecture](/platform/self-hosting/#managed-architecture), the Docker backend supports volume mounts (`-v` flag) to mount a pre-existing repo checkout from the host into task containers. With the Kubernetes backend, use `pod_template` to configure persistent volume claims or pre-populated storage for the same purpose. :::note The managed architecture supports three execution backends: **Docker** (default), **Kubernetes**, and **Direct** (no container runtime). The Kubernetes backend runs each task as a Kubernetes Job and includes a Helm chart for deployment. See [Self-hosting](/platform/self-hosting/#choosing-a-managed-backend) for details on choosing a backend. ::: ### Do Kubernetes pods provide enough sandboxing for self-hosted agents? This depends on your cluster configuration and risk profile. Evaluate your pod security policies, network policies, and RBAC settings based on your organization's security requirements. ## Current limitations ### Do cloud agents support image attachments? Cloud agent conversations do not currently support image attachments. Image attachment (via the toolbar button, clipboard paste, or drag-and-drop) is only available in [local agent conversations](/agents/local-agents/interacting-with-agents/terminal-and-agent-modes/). If you need to provide visual context to a cloud agent, you can describe the image contents in your prompt or reference image file paths within the agent's [environment](/platform/environments/).Tell me about this feature: https://docs.warp.dev/platform/faqs/Frequently asked questions about cloud agents, including where agents run, how runs work, supported models, security, and common workflows.
This page answers common questions about cloud agents, including where they run, how they’re configured, and how teams use cloud agents for day-to-day engineering work.
Architecture and execution
Section titled “Architecture and execution”Where do cloud agents run? What’s the architecture?
Section titled “Where do cloud agents run? What’s the architecture?”Agents run either locally (inside your Warp session) or in the cloud as a cloud agent run, inside an environment (see Environments).
The cloud agents platform is built around modular, observable execution:
- A trigger starts work (manual, schedule/cron, webhook, or an integration like Slack/GitHub).
- The agent executes inside an environment (either a Warp-hosted cloud sandbox, or a self-hosted sandbox on your infrastructure, depending on plan/support).
- Every step is recorded: transcripts, tool calls, logs, and outputs, so work is auditable and debuggable instead of a black box.
The same agent can be invoked consistently across entry points (Warp conversation, cloud agent web app, the CLI, API/SDK, Slack/GitHub triggers) without rewriting the underlying instructions.
What exactly are cloud agents in Warp?
Section titled “What exactly are cloud agents in Warp?”A cloud agent is a packaged automation unit made up of:
- Instructions — A reusable skill/prompt (what it should do).
- Profile — Model selection + tools + permissions (how it operates).
- Trigger — Manual, cron/schedule, webhook, or integration event (when it starts).
- Environment — Repo access, dependencies (Docker image), secrets, setup commands, and runtime config (where it runs).
- Host — Local (interactive) or cloud (run), and optionally self-hosted execution (where supported).
Because the agent definition is modular, the same cloud agent can be started from different surfaces (terminal, web app, CLI, integrations) with a consistent interface.
Can we intervene mid-run?
Section titled “Can we intervene mid-run?”Yes. For cloud agent runs, you can:
- Inspect run state, tool calls, and logs.
- Steer the agent while it’s running.
- Unblock it with additional instructions or context.
If you’re not happy with where it landed, you can take over to finish the task. That human handoff is a core part of making agents reliable beyond demos.
Do cloud agents have access to Codebase Context and indexing?
Section titled “Do cloud agents have access to Codebase Context and indexing?”Yes. Codebase Context is enabled for all cloud agent runs, as long as Codebase Context is enabled for your account. This includes runs triggered from the CLI, API/SDK, integrations (Slack, Linear, GitHub Actions), and schedules. No additional configuration is needed — if Codebase Context is enabled, cloud agents use it automatically.
Can I access a shell inside a cloud agent environment? Are there limitations (Docker, Playwright, etc.)?
Section titled “Can I access a shell inside a cloud agent environment? Are there limitations (Docker, Playwright, etc.)?”Yes. Cloud agent runs execute in a full Linux environment and behave like a local development session. You can install dependencies, run Docker, and use headless tools like Playwright, subject to standard sandbox resource limits.
Do cloud agents run as root inside the container?
Section titled “Do cloud agents run as root inside the container?”No. By default, cloud agents run as a dedicated non-root agent user (UID/GID 1000 where available) with passwordless sudo. If your environment’s image sets a non-root USER, Warp runs the agent as that user instead, unchanged. For images that start as root, commands that need root access, like apt-get install, work with a sudo prefix. See configuring container users for details on home directory location, file ownership, and fallback behavior.
Do cloud agents support a fully self-hosted, on-prem, or offline mode?
Section titled “Do cloud agents support a fully self-hosted, on-prem, or offline mode?”The cloud agents platform supports self-hosting the agent sandbox (the execution environment) on your own infrastructure. The control plane—which handles orchestration, tracking, and auditability—remains Warp-managed and is not self-hosted.
Self-hosted execution is available on Enterprise plans. See Self-hosting and Deployment patterns for details.
Models
Section titled “Models”Which models are supported?
Section titled “Which models are supported?”Cloud agents are multi-model by design. You can choose models based on cost, latency, and capability, and teams commonly mix models by workflow:
- Faster/cheaper models for triage and routine tasks.
- Stronger models for complex changes (refactors, multi-file work, deeper reasoning).
Model choice is configurable per agent (and often per environment/workflow), depending on how you set up your profiles.
Can I choose which model cloud agents use?
Section titled “Can I choose which model cloud agents use?”Yes. Cloud agents support the same set of models available in Warp. Model selection is configurable per agent or environment.