[warp-agent-staging]

What this feature does

Factory runs using the Warp Agent call team-managed inference gateways from Warp's hosted backend, even when workers execute on customer infrastructure. Gateway owners need ingress from Warp, not only worker network access. This documents the existing routing boundary; live IP coverage remains pending engineering confirmation. Private-networking availability must be confirmed for each deployment; this is not a new client-release claim.

Content design plan

• Reader and job: A platform engineer connecting a private LLM gateway to a self-hosted factory.
• Gap today: Existing pages describe hosted routing but don't name inference source IPs or clearly separate worker egress from gateway ingress.
• Change: One conceptual networking subsection on the existing factory infrastructure page, with three targeted cross-links. Keep endpoint configuration and private-connection setup on their existing pages.

Editorial verdict: preserve each page's purpose, the personal/team-managed credential distinction, and the existing third-party-harness direct-call exception. A deletion-only pass removed repeated routing prose; no new page, setup walkthrough, or availability expansion.

Source evidence

Source revisions: warp-server@d8a0cc2f7130faac1e833efb66161fbc448a82fd; docs base 232cf27943a1fbbc11eead43792cf224e4b5f226; warp-terraform@00ade81922a047049183e7d11ddb8e34aae64fcd.

• Hosted inference origin: generate_multi_agent_output.go:177–214 resolves team credentials and private endpoints on the server. custom_endpoint/client.go:17–38 creates the outbound HTTP client and endpoint base URL; streaming.go:87–112 uses that client for model requests.
• Exact IPs: networking/egress_ranges.go:71–77 independently lists 34.181.225.186/32 and 35.245.132.55/32 as production control-plane Cloud NAT addresses. This is checked-in source evidence, not a live infrastructure audit.
• Private route implementation: custom_endpoint/client.go:29–38, config/private_llm_endpoints.go:23–42, and outboundhttp/private_service.go:185–220 support registered private destinations and pinned outbound connections. These application-level pins require a separately provisioned private network route.
• AWS implementation: aws_customer_endpoint/main.tf:22–38 creates an Interface VPC endpoint targeting a customer service. aws_bridge/aws/bridge.tf:63–108 and aws_bridge/gcp/main.tf:26–47 implement the private cross-cloud interconnect. A conditional staging LiteLLM caller publishes the endpoint through PSC; its comment explicitly identifies a temporary test, not a customer deployment or passing runtime result.
• Azure implementation: azure_customer_endpoint/main.tf:20–42 creates a Private Endpoint for a service alias or, separately, Blob Storage. azure_bridge/azure/main.tf:108–135 and azure_bridge/gcp/main.tf:84–115 implement the IPsec/BGP bridge. Staging hub defaults are enabled on the Azure and GCP sides, but no committed Azure LLM endpoint caller or runtime result was found.
• GCP PSC implementation: consumer/main.tf:74–101 pins a private consumer IP and forwards it to a service attachment. psc_service/main.tf:38–55, 84–115, and 155–179 publish a TCP proxy to private endpoint addresses reached over the bridge. TLS is not terminated by this proxy. A customer GCP attachment can also be consumed directly.
• Production configuration is not availability proof: the production consumer endpoint map is empty; production GCP hub/VPN defaults are disabled, as are the AWS and Azure sides. These are committed defaults, not live apply state. No live audit was performed; cloud state and secret values were not accessed. Customer eligibility and per-cloud production offerings remain unverified. The revision therefore asks the account team to confirm deployment-specific availability instead of promising three cloud options.
• Linked-page limits: private-networking.mdx:34–59 presents cloud connection methods and onboarding procedures more broadly than this verification establishes. Those availability/procedure claims remain unverified and unchanged here. In particular, its generic Azure “alias or resource URI” instruction exceeds the alias-only generic-service branch above; resource-ID input is Blob-specific. Terraform setup guides describe intended manual provisioning, not production entitlement.
• Worker versus harness boundary: existing infrastructure-and-security.mdx:30 distinguishes hosted Warp Agent model calls from direct Claude Code/Codex calls. New prose is explicitly limited to the Warp Agent.

Gate 0: the targeted rollout check found the relevant team-managed endpoint gate on in production at the server revision above. Neither the source revision nor that check proves live network coverage or per-cloud onboarding availability. Only the unresolved IP-coverage promise remains marked below; cloud availability is no longer promised.

Validation

• npm run typecheck — passed, 0 errors and 7 existing hints.
• npm run test:heading-vars — passed, 5 tests.
• npm run build — passed, 409 generated pages.
• npm run test:heading-tocs — passed, 3,447 entries.
• npm run test:homepage-json-ld — passed.
• python3 .agents/skills/style_lint/style_lint.py --changed --output /tmp/byo-inference-style-lint.json — 4 files, 8 warnings; all warning lines verified unchanged from the docs base, none introduced.
• python3 .agents/skills/check_for_broken_links/check_links.py --internal-only — passed, 4,625 internal links.
• /tmp/byo-inference-linkcheck/bin/python .agents/skills/check_for_broken_links/check_links.py --timeout 5 --output /tmp/byo-inference-links-full.json — failed on 2 existing external links outside the diff: https://code.claude.com/docs (redirect loop) and https://github.com/wslutilities/wslu (404). Also reported 13 bot-blocked URLs, not counted as failures. No new destination failed.
• python3 .agents/skills/doc_quality_policy/check_compression_contract.py PATH --content-type TYPE — passed for all 4 changed pages: infrastructure (conceptual), self-hosting (feature-doc), team-managed endpoints (feature-doc), and execution security (reference).
• Targeted server_rollout.py scan — the relevant gate is on in production, with the availability limits above. Private rollout terms are omitted from this public artifact.
• git diff --check — passed.
• PR body integrity — authored sections checked separately; the full-file helper flags repeated image alt text and captions in the required, verbatim generated screenshot block as a repetition loop. That managed block is preserved unchanged.
• trunk check and trunk fmt — unavailable (trunk: command not found), not reported as passing.
• Chromium on Linux — refreshed static render checks the complete subsection, both IPs, revised deployment-specific availability paragraph, hidden MDX comments, and no horizontal overflow. The new screenshot is 01a18e8f-c370-7324-8639-ab744648ad47. This does not test a real inference gateway or production private connection.
• Revision checks rerun: typecheck (0 errors, 7 hints), build (409 pages), heading TOCs (3,447 entries), homepage JSON-LD, internal links (4,625), conceptual compression, style lint (same 8 unchanged-line warnings), and git diff --check passed as qualified above. Heading-variable tests and HTTP link scan were not rerun: their inputs/destinations did not change. Trunk remains unavailable.

Unverified claims

• Confirm that all current production team-managed inference requests use only these two fixed outbound IPs.
  factories/infrastructure-and-security.mdx, “Networking for BYO inference endpoints.” Source contains both production NAT addresses, but live infrastructure configuration and end-to-end inference egress were not audited. Engineering must confirm currentness and completeness across production inference paths before merging.

Documentation risk

Risk: engineering-review-required
Rationale: Adds inference-origin, gateway-ingress, fixed-IP, and private-connectivity claims; one IP-coverage VERIFY marker remains. The private-networking availability promise was removed, not verified. No new callouts or page-budget overages.
Source files consulted: warp-server@d8a0cc2f7130faac1e833efb66161fbc448a82fd (router/handlers/generate_multi_agent_output.go; logic/ai/llm/custom_endpoint/client.go; logic/ai/ambient_agents/networking/egress_ranges.go; config/private_llm_endpoints.go; util/outboundhttp/private_service.go), warp-terraform@00ade81922a047049183e7d11ddb8e34aae64fcd (modules/customer_network_connectivity; environments/production/customer_llm_connectivity.tf; environments/customer-production/variables.tf), docs@232cf27943a1fbbc11eead43792cf224e4b5f226 (src/content/docs/enterprise/enterprise-features/private-networking.mdx)
Engineering review status: pending
Docs override: none

No reviewer requested: source-owner resolution returned multiple engineers and a team, not one certain human owner. No requester GitHub login was verified.

Co-Authored-By: Oz oz-agent@warp.dev

Current proof is the second capture below (01a18e8f-c370-7324-8639-ab744648ad47). The first capture (01a18e64-c79a-70be-aa6a-180bd9e511d3) is superseded and shows the removed availability promise; it is not evidence for the revised wording. The generated artifact block retains both captures.

Computer-use screenshots (2)

Networking for BYO inference endpoints subsection with explanation, both IPs, and private connectivity paragraph

Full Networking for BYO inference endpoints subsection: heading, origin explanation, both IPs, and private-networking paragraph, no overflow.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Oct 30, 2026 8:57pm UTC

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-staging-factory on this PR to send it follow-up work.

  

[warp-agent-staging]

Overview

This clarifies hosted inference versus self-hosted execution, gateway allowlisting, and private connectivity. Engineering confirmation is needed for the two explicitly marked production-networking claims before publication.

Verdict

Checks: build pass, tests pass, CI pending, visual proof present.

Found: 0 critical, 0 important, 0 suggestions, 0 nits; 2 confirmation questions.

Responding as Docs Factory (V2): Open session · View in factory

[warp-agent-staging]

Question: Can engineering confirm these two addresses are current and cover all production Warp Agent team-managed inference paths? The checked-in control-plane NAT list contains both, but does not establish complete live inference egress; an incomplete allowlist would block gateway requests. Confirm coverage before publication and resolve the VERIFY marker, or direct customers to account-team-confirmed values.

Responding as Docs Factory (V2): Open session · View in factory

[warp-agent-staging]

@hongyi-chen, your GitHub account is not connected to Warp. Connect your GitHub account.