From 69b1a5be2531e144207e0fa12379be92779d035d Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Fri, 30 Oct 2026 19:56:10 +0000 Subject: [PATCH 1/2] docs: clarify BYO inference networking for self-hosted factories Distinguish hosted inference requests from worker execution, document gateway allowlisting and private connectivity, and flag production network details for engineering confirmation. Co-Authored-By: Oz --- .../team-managed-keys-and-endpoints.mdx | 2 +- .../factories/infrastructure-and-security.mdx | 18 ++++++++++++++++++ .../docs/factories/self-hosting/index.mdx | 2 ++ .../docs/platform/execution-security.mdx | 6 +++--- 4 files changed, 24 insertions(+), 4 deletions(-) diff --git a/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx b/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx index aee45b9f8..b2eb89570 100644 --- a/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx +++ b/src/content/docs/enterprise/enterprise-features/team-managed-keys-and-endpoints.mdx @@ -74,7 +74,7 @@ Configure team providers from the [Admin Panel](/enterprise/team-management/admi The team's enabled models appear in members' model pickers when their team settings refresh. :::note -A team endpoint's base URL must be reachable from Warp's hosted services. Use a public HTTPS URL by default, or [connect a private LLM gateway through private networking](/enterprise/enterprise-features/private-networking/). +A team endpoint's base URL must be reachable from Warp's hosted services, even with self-hosted workers. See [Networking for BYO inference endpoints](https://docs.warp.dev/factories/infrastructure-and-security/#networking-for-byo-inference-endpoints) for IP allowlisting, or [connect a private LLM gateway through private networking](/enterprise/enterprise-features/private-networking/). ::: ### Keep inference on your team's providers diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 18e288d6c..ae8d409ec 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -85,6 +85,24 @@ Factory agents execute as cloud agents. For runs using the Warp Agent, support v 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. +### Networking for BYO inference endpoints + +For factory runs using the Warp Agent and a team-managed inference endpoint, model requests originate from Warp's hosted backend, not your self-hosted worker or VPC. Your workers execute checkout, tools, builds, and commands. + +Your inference gateway must accept connections from Warp's backend, even if your workers can already reach it. For example, a TrueFoundry gateway on AWS needs a separate ingress path for Warp's inference requests. + +For a public HTTPS gateway, allowlist both fixed outbound IP addresses in your gateway's ingress rules: + +{/* VERIFY: Confirm that all current production team-managed inference requests use only these two fixed outbound IPs. */} + +* `34.181.225.186` +* `35.245.132.55` + +These addresses identify Warp's hosted backend, not worker execution traffic. The worker's outbound connection to Warp doesn't require inbound ports on the worker. + +If your gateway can't be exposed publicly, contact your Warp account team to arrange [private networking](https://docs.warp.dev/enterprise/enterprise-features/private-networking/). Options include AWS PrivateLink, Google Cloud Private Service Connect, and Azure Private Link. Setup is coordinated with Warp; self-hosting a worker doesn't establish this private connection. +{/* VERIFY: Confirm production availability and onboarding scope for private LLM gateway connectivity through AWS PrivateLink, Google Cloud Private Service Connect, and Azure Private Link. */} + ## Credential boundaries A factory handles four kinds of credentials, each with its own boundary: diff --git a/src/content/docs/factories/self-hosting/index.mdx b/src/content/docs/factories/self-hosting/index.mdx index b80ffa2c9..536aec2ed 100644 --- a/src/content/docs/factories/self-hosting/index.mdx +++ b/src/content/docs/factories/self-hosting/index.mdx @@ -149,6 +149,8 @@ Use unmanaged execution for an existing CI pipeline, Kubernetes Job, VM, or deve Repository clones and execution workspaces stay on your infrastructure. Agent context and model requests still travel through Warp's services. See the [self-hosted execution flow](/platform/architecture/#self-hosted-execution-flow) for the architecture and [Security and networking](/platform/execution-security/) for data boundaries, ZDR, and BYOLLM. +For a factory using a team-managed inference gateway, see [Networking for BYO inference endpoints](/factories/infrastructure-and-security/#networking-for-byo-inference-endpoints) for gateway ingress requirements, source IPs, and private connectivity options. + View managed and unmanaged runs in the {VARS.DASHBOARD}. Managed workers can also export OpenTelemetry metrics; see [Monitoring](/factories/self-hosting/monitoring/). ## Related pages diff --git a/src/content/docs/platform/execution-security.mdx b/src/content/docs/platform/execution-security.mdx index 895228ed0..749990138 100644 --- a/src/content/docs/platform/execution-security.mdx +++ b/src/content/docs/platform/execution-security.mdx @@ -32,7 +32,7 @@ Repositories are cloned and stored only on your infrastructure, but code content ## Network requirements -Self-hosted agents **do not require any network ingress**. They require outbound (egress) access to the following services: +Self-hosted workers **do not require network ingress for their connection to Warp**. 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) @@ -58,9 +58,9 @@ Tasks use the following Docker images: **Linux distribution-specific package repositories** — only with the managed architecture, when using a Warp environment whose base image does not have Git pre-installed. The exact repositories depend on the package manager configuration in the environment's base image. -All traffic uses HTTPS (port 443). No inbound ports need to be opened. +All traffic uses HTTPS (port 443). No inbound ports need to be opened on the worker for its connection to Warp. -[Team-managed inference endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) and URL-backed MCP servers that you host must be reachable from Warp's servers. +[Team-managed inference endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) and URL-backed MCP servers that you host must be reachable from Warp's servers. The worker's outbound-only connection doesn't provide ingress to your inference gateway; see [Networking for BYO inference endpoints](https://docs.warp.dev/factories/infrastructure-and-security/#networking-for-byo-inference-endpoints) for gateway allowlisting and private connectivity options. --- From 0f86f682b5363aa7583113f4d4459039217cef20 Mon Sep 17 00:00:00 2001 From: "warp-agent-staging[bot]" <240773466+warp-agent-staging[bot]@users.noreply.github.com> Date: Fri, 30 Oct 2026 20:47:33 +0000 Subject: [PATCH 2/2] docs: qualify private networking availability by deployment Document the verified registration and hosted-backend reachability boundary without claiming production availability for each cloud connectivity method. Co-Authored-By: Oz --- src/content/docs/factories/infrastructure-and-security.mdx | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index ae8d409ec..67971c4de 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -100,8 +100,7 @@ For a public HTTPS gateway, allowlist both fixed outbound IP addresses in your g These addresses identify Warp's hosted backend, not worker execution traffic. The worker's outbound connection to Warp doesn't require inbound ports on the worker. -If your gateway can't be exposed publicly, contact your Warp account team to arrange [private networking](https://docs.warp.dev/enterprise/enterprise-features/private-networking/). Options include AWS PrivateLink, Google Cloud Private Service Connect, and Azure Private Link. Setup is coordinated with Warp; self-hosting a worker doesn't establish this private connection. -{/* VERIFY: Confirm production availability and onboarding scope for private LLM gateway connectivity through AWS PrivateLink, Google Cloud Private Service Connect, and Azure Private Link. */} +If your gateway can't be exposed publicly, contact your Warp account team to confirm whether [private networking](https://docs.warp.dev/enterprise/enterprise-features/private-networking/) is available for your deployment. A private endpoint must be registered with Warp and reachable from Warp's hosted backend; self-hosting a worker doesn't establish this connection. ## Credential boundaries