Skip to content

Enterprise > Enterprise features

Connecting private services to Warp

Open in ChatGPT ↗
Ask ChatGPT about this page
Open in Claude ↗
Ask Claude about this page
Copied!

Connect private LLM gateways and MCP servers to Warp through cloud private endpoints, VPNs, or on-premises interconnects.

Private networking lets Warp reach an LLM gateway or MCP server without exposing the service to the public internet. You keep the service, access controls, and network policy in infrastructure you manage.

Private networking applies to services that Warp calls from its hosted services:

  • Private LLM endpoints - Connect a team-managed, OpenAI-compatible endpoint such as an internal LiteLLM gateway. See team-managed LLM API keys and endpoints for endpoint and model configuration.
  • Private MCP servers - Connect a URL-based managed MCP installation that uses a Warp-managed connection. Include private OAuth or identity provider endpoints in the onboarding scope when the MCP server depends on them. See MCP servers for cloud agents.

Self-serve custom inference endpoints remain device-level settings and require a public URL.

Direct url configurations use a different network path; see direct URL MCP servers for their connectivity requirements.

Prepare these items before onboarding:

  • Service details - Provide the endpoint type, service hostname, and HTTPS port for each LLM endpoint or MCP server.
  • TLS certificate - Serve the endpoint over HTTPS. Provide CA certificates when the endpoint doesn’t use a publicly trusted authority.
  • OAuth endpoints - For an OAuth-protected private MCP server, provide any private authorization, token, registration, or identity provider endpoints it uses.

Match the service location to a connection method:

Service locationConnection method
Google CloudPrivate Service Connect
AWSAWS PrivateLink
AzureAzure Private Link
On-premises or colocation networkOn-premises interconnect
Network with a public VPN gatewayRoute-based IPsec VPN

Set up Google Cloud Private Service Connect

Section titled “Set up Google Cloud Private Service Connect”
  1. Put the service behind a load balancer supported by Private Service Connect.
  2. Publish a regional service attachment in the region Warp specifies. See the Google Cloud guide to publishing a service with Private Service Connect.
  3. Configure explicit approval for the Warp consumer project supplied during onboarding.
  4. Give Warp the service attachment URI, service hostname, and HTTPS port.

Warp and your team confirm that the private connection is ready before you configure the LLM endpoint or MCP server.

  1. Put the service behind a VPC endpoint service, normally backed by a Network Load Balancer. See the AWS guide to creating an endpoint service.
  2. Enable the AWS region Warp specifies during onboarding.
  3. Allow the Warp AWS principal supplied during onboarding and accept Warp’s connection.
  4. Give Warp the endpoint service name, AWS region, service hostname, and HTTPS port.

Warp confirms when the consumer endpoint is connected and ready for an application test.

  1. Put the service behind an Azure Standard Load Balancer. Configure its frontend IP, backend pool, health probe, and load-balancing rule.
  2. Disable private link service network policies on the subnet you will use for source NAT.
  3. Create an Azure Private Link Service that references the load balancer’s frontend IP configuration, then select the source NAT subnet and IP configuration. Follow Microsoft’s guide to creating an Azure Private Link Service.
  4. Give your Warp account team the Private Link Service alias or resource URI, Azure region, service hostname, and HTTPS port.
  5. After the private endpoint request appears in Azure, approve the connection and test the service.

Use an interconnect for an on-premises or colocation network connected through a network provider:

  1. Choose a network provider and agree on the locations, capacity, and redundancy with Warp.
  2. Give Warp the service hostname, HTTPS port, and network information requested during onboarding.
  3. Provision the interconnect with your provider using the connection details exchanged during onboarding.
  4. Coordinate routing with your Warp account team.
  5. Confirm that the agreed connections and routes are available before testing the service.

Use a route-based IPsec VPN for a network with a compatible public VPN gateway:

  1. Give your Warp account team the public VPN endpoint, service hostname, HTTPS port, and network ranges requested during onboarding.
  2. Configure a route-based IPsec VPN whose gateway and routing use BGP.
  3. Coordinate the gateway and routing values with your Warp account team.
  4. Confirm that the private route is available before testing the service.

After Warp confirms that the private connection is ready, configure the service with its private hostname:

Then validate the connection:

  1. Confirm the LLM gateway or MCP server is healthy on its private hostname and port.
  2. For an LLM gateway, select a model configured on the team endpoint and send a test prompt.
  3. For an MCP server, invoke a read-only tool through the managed MCP installation.
  4. Check your service and network logs for the request, authentication result, and response.
  5. If your policy requires private-only access, verify that the service isn’t reachable from the public internet.

If a test request reaches your service but fails, check the HTTPS certificate, authentication configuration, and MCP OAuth hosts before changing routes.