🇪🇺 Fixed egress for AI agents

🇪🇺 Static IP for LangGraph

Your LangGraph agent's tool calls keep getting blocked because your cloud platform rotates IPs and breaks the API whitelist. Route all outbound LLM and tool calls through two fixed EU IPs with one HTTPS_PROXY env var.

Get Your EU Static IP See How It Works

agent.py

# .env

HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443

import requests

def search_api(query):

# requests honours HTTPS_PROXY

r = requests.get(

f"https://api.partner.eu/search?q={query}")

return r.json()

The Problem

LangGraph agents call external APIs for tool use, RAG retrieval, and function calling. Partner APIs enforce IP whitelisting, and your cloud platform's rotating IPs keep breaking it.

Tool calls get blocked mid-agent-run

When a LangGraph agent calls a tool function that hits an external API with IP whitelisting, and the cloud platform has rotated your outbound IP, the call returns a 403. The agent either retries endlessly or fails the entire workflow.

Each tool node has the same problem

LangGraph agents have multiple tool nodes in a graph. Each one calls a different API (CRM, payment, knowledge base). All of them share the same dynamic egress IP, so all of them break when the IP rotates.

LLM calls need IP allowlisting too

Some enterprises restrict which IPs can call their LLM provider APIs (OpenAI, Anthropic, Mistral). If your LangGraph deployment runs on cloud infra with dynamic IPs, even the core LLM completion calls get blocked.

No networking control in the agent runtime

LangGraph runs your agent code in a managed Python runtime. You don't get a VM or a container shell to configure VPC connectors or NAT rules. The only lever you have is what your tool code sees as environment variables.

The Solution

Route all agent outbound calls through a fixed EU IP pair

Every outbound call your LangGraph agent makes, from LLM completions to tool API lookups, leaves from the same pair of EU addresses. Partner APIs see one predictable source. Two IPs with automatic failover.

One env var in your agent runtime. If your tool functions use requests or httpx, setting HTTPS_PROXY is all it takes.

No VPC, no Cloud NAT, no routing tables. The proxy is application-level, so it works inside the managed runtime.

TLS passthrough. Your API tokens, tool payloads, and LLM prompts stay unreadable at the proxy.

Implementation

Set HTTPS_PROXY and your existing LangGraph code works as-is.

Python (LangGraph tool function)

Your existing tool code works as-is. requests reads HTTPS_PROXY automatically.

# .env
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
PARTNER_API_TOKEN=your_token

import os
import requests
from langgraph.graph import StateGraph

# Tool function: requests honours HTTPS_PROXY automatically
def search_partner(state):
    r = requests.get(
        "https://api.partner.eu/search",
        params={"q": state["query"]},
        headers={"Authorization":
            f"Bearer {os.environ['PARTNER_API_TOKEN']}"},
    )
    return {"results": r.json()}

# Build the graph as usual
graph = StateGraph(State)
graph.add_node("search", search_partner)

Node.js (LangGraph.js)

If you use LangGraph.js, pass the proxy explicitly with https-proxy-agent.

// .env
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443

const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);

// Tool function: every fetch uses the proxy agent
async function searchPartner(state) {
  const res = await fetch('https://api.partner.eu/search', {
    headers: { 'Authorization': 'Bearer ..' },
    agent,
  });
  return { results: await res.json() };
}

Docker / Kubernetes / env

Set it wherever your LangGraph agent runs.

# Docker Compose
services:
  agent:
    env_file: .env

# Kubernetes: Secret
env:
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: outboundgateway-proxy
        key: proxy-url

Two IPs, no agent rewrite

Your account comes with two static IP addresses. Whitelist both on every partner API. If one proxy node is briefly unavailable, traffic shifts to the other. Your agent keeps running.

📖 Complete Documentation: For detailed examples, error handling, and other Python libraries, see the Python SSL Proxy Guide, Node.js Guide, and all other language guides.

Why LangGraph developers choose OutboundGateway

A pair of fixed IPs

Two addresses to whitelist on every partner API, with automatic failover.

No agent rewrite

Set one env var and your existing tool functions and graph nodes work as-is.

EU-hosted

European data centres and a GDPR-conscious setup, giving your agents a predictable EU address.

All tool nodes

Every tool function, API lookup, RAG retrieval, and LLM call. One pair covers the whole graph.

Encrypted end to end

TLS passthrough means the proxy can't read your traffic. Prompts, tokens, and payloads stay private.

Flexible plans

Starting from €19/month. Flexible plans for every scale. Cancel anytime.

Frequently Asked Questions

Does this work with LangGraph tool functions and graph nodes?

Yes. LangGraph tool functions and graph nodes are just Python functions that make HTTP calls. If they use requests or httpx, setting HTTPS_PROXY as an environment variable covers every tool node in the graph automatically. No changes to your graph definition or node configuration.

Does this also cover LLM provider calls (OpenAI, Anthropic)?

Yes. The proxy isn't endpoint-specific. Whether your LangGraph agent calls OpenAI, Anthropic, Mistral, or any other LLM provider, all of it routes through the same fixed pair of EU IPs. This is useful if your enterprise restricts which IPs can call the LLM provider.

Does this work with LangGraph deployed on LangGraph Cloud?

If you run LangGraph Cloud and can set environment variables in your deployment, then yes. If you self-host LangGraph, set HTTPS_PROXY in the container or server environment. Either way, Python's requests and httpx read it automatically.