LiveKit Cloud agents call your backend APIs, but LiveKit confirmed it has no fixed CIDR range for hosted agents. Your WAF blocks them. Route those outbound calls through two fixed EU IPs with one env var, so agents stop getting blocked.
# Self-hosted agent env var
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
import requests
r = requests.post(
"https://backend.your-app.eu/api/handle",
json={"text": transcript})
)
LiveKit staff confirmed: there is no fixed CIDR range for hosted agents. Agent requests come from dynamic IPs that your firewall can't predict.
LiveKit staff confirmed on their forum: "We do not currently have a fixed CIDR range for LiveKit-hosted agents." Even the EU IPs in the docs don't cover all outbound calls from agents. Your WAF can't allowlist what it can't predict.
When an agent in LiveKit Cloud calls your backend API to look up data, trigger a function, or hand off context, that request comes from whatever IP the cloud infra assigned at that moment. Your WAF sees an unknown source and blocks it.
LiveKit suggests using token auth instead of IP allowlisting, but many enterprises require both. Security policies mandate IP allowlisting for backend APIs behind a WAF, and token auth doesn't satisfy that requirement on its own.
LiveKit suggests self-hosting agents as a workaround to control the IP, but that means managing infrastructure, scaling, and uptime yourself. You wanted the simplicity of LiveKit Cloud, not a deployment project.
"The agent tried to call our backend API, but the WAF blocked it because we don't know what IP it will come from."
You need a fixed address the agent always calls from, so your WAF can allowlist it once.
LiveKit agent
HTTPS Proxy
(Static EU IP)
Your backend API
Every outbound call your LiveKit agent makes to your backend API leaves from the same pair of EU addresses. Your WAF allowlists both once, and every future agent call passes. Two IPs with automatic failover.
HTTPS_PROXY in the agent runtime and every API call routes through your fixed IPs.Building LiveKit agents that call backend APIs behind a WAF, who are tired of dynamic IP blocks breaking conversations mid-call.
Managing the WAF that protects backend APIs, who need a predictable IP to allowlist for LiveKit agent access.
Running LiveKit agents for EU-regulated workloads who need agent API calls to leave from European infrastructure.
Designing zero-trust access for backend APIs, who need IP allowlisting to work alongside token auth for LiveKit agents.
Set HTTPS_PROXY in your self-hosted LiveKit agent runtime. Outbound API calls to your backend then leave through your fixed EU IP.
If your agent uses requests to call backend APIs, setting HTTPS_PROXY is all you need.
# env var in agent runtime
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
BACKEND_API_TOKEN=your_token
import os
import requests
# requests honours HTTPS_PROXY from the environment
r = requests.post(
"https://backend.your-app.eu/api/handle",
headers={"Authorization": f"Bearer {os.environ['BACKEND_API_TOKEN']}"},
json={"text": transcript},
)
print(r.status_code) # 200, from your fixed EU IPIn Node, pass the proxy explicitly with https-proxy-agent.
// env var set in the agent runtime
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
// Every backend API call leaves through your fixed EU IP
const res = await fetch('https://backend.your-app.eu/api/handle', {
method: 'POST',
headers: { 'Authorization': 'Bearer ..' },
body: JSON.stringify({ text: transcript }),
agent,
});Two IPs, no WAF chasing
Your account comes with two static IP addresses (for example 51.xx.xx.10 and 51.xx.xx.11). Allowlist both on your WAF. If one proxy node is briefly unavailable, traffic shifts to the other. Your LiveKit agent never sees a disruption.
📖 Want the longer version? Worked examples, error handling, and other languages are in the Python SSL Proxy Guide, Node.js Guide, and the rest of the docs.
If your backend runs in the EU, your LiveKit agent's API calls should stay in Europe too.
The proxy runs in EU data centres, so your LiveKit agent's outbound API calls leave from European infrastructure.
Because TLS passes straight through, the proxy never decodes transcripts, API tokens, or agent payloads. It forwards encrypted bytes; it doesn't read them.
Agent API traffic doesn't bounce through US infrastructure on its way to your backend, keeping the data path inside the EU.
When your WAF team asks what IP the agent calls from, the answer is two fixed EU addresses that never change.
Two addresses for your WAF to allowlist, with automatic failover. No dynamic IP chasing.
Set one env var in the agent runtime and your existing API call code starts routing through the proxy.
European data centres and a GDPR-conscious setup, giving your agents a predictable EU address.
Stay on LiveKit Cloud for WebRTC. Only route the agent's outbound API calls through the proxy.
TLS passthrough means the proxy can't read your traffic. Transcripts and tokens stay private.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Stop letting LiveKit's dynamic IPs break your WAF rules. Give your agents one stable pair of EU IPs for outbound API calls.
€19/month starter plan • 7-day refund policy • Direct founder support
No. LiveKit staff confirmed on their community forum: "We do not currently have a fixed CIDR range for LiveKit-hosted agents." Agent requests come from dynamic IP ranges. Even the EU IPs in the firewall documentation don't cover all outbound calls from agents. They're working on it, but it's not available today. OutboundGateway fills the gap with a fixed pair of EU IPs.
The proxy works in the agent's outbound code, so it applies to self-hosted agents that you run alongside LiveKit Cloud (which is what LiveKit recommends for IP control). You keep LiveKit Cloud for WebRTC and room management, and route the agent's outbound HTTPS API calls through OutboundGateway. Set HTTPS_PROXY in the agent runtime and the standard HTTP clients pick it up.
Token auth is good practice, but many enterprises require both token auth AND IP allowlisting for backend APIs behind a WAF. If your security policy mandates IP allowlisting, token auth alone doesn't satisfy it. OutboundGateway gives you the IP control LiveKit Cloud agents lack, so your WAF sees a known source on every request.
Happy to talk through how a two-IP EU egress fits your LiveKit agent setup, whether it's a voice bot, a customer support agent, or an internal assistant.
Contact Our Founders →