opper.ai gives your agents one EU-hosted front door to 700+ models behind a single API key. Keep the hop in front of that door just as tidy: two fixed static EU IPs, so every call to api.opper.ai leaves from one stable European origin.
from openai import OpenAI
import os
client = OpenAI(
base_url="https://api.opper.ai/compat/openai",
api_key=os.environ["OPPER_API_KEY"],
)
# egress pinned by HTTPS_PROXY
# in the same environment
You chose Opper for its EU hosting and its one-key simplicity. Both of those choices quietly raise the stakes on the network your own traffic uses.
Opper runs in AWS Stockholm and tags models by region so you can keep processing inside the Union. But the hop before Opper is yours: a workload scheduled in a non-EU region, or a serverless platform with no fixed exit, quietly puts a foreign address at the start of an otherwise European chain.
That is the pitch, and it is also the exposure: OPPER_API_KEY spans a catalog of 700+ models across 13+ providers and the credits that pay for them. A key that powerful, usable from any address on earth, deserves a network story: known egress points, keys that never leave controlled environments.
Opper is built for agents, and agents run on the infrastructure du jour: serverless functions, autoscaled pods, CI runners. Each deployment hands your API traffic a different datacenter address, so the gateway's abuse systems and per-IP rate limits meet a new stranger on every cold start.
Opper normalizes the model hop beautifully. Around it, your agents still call tool APIs, partner endpoints, and webhooks that were never gatewayed, and those destinations judge you by source address. Fixing your egress fixes the whole outbound estate at once, not just the LLM calls.
Your agents & apps
OpenAI SDK, LangChain, Vercel AI
HTTPS Proxy
(Static EU IP)
Opper API
Stockholm, 700+ models
From Stockholm's point of view, your whole agent fleet becomes one repeat customer calling from two permanent European addresses: predictable for rate limits, boring for abuse systems, and perfectly in step with the residency you are paying for.
OPPER_API_KEY stays sealed in its TLS envelope end to end; the relay between you and Stockholm carries ciphertext and nothing else.Opper keeps the model side of the journey inside the Union. A fixed European exit does the same for your side, so the residency claim covers the whole path instead of the second half.
Swap models, swap frameworks, try the newest release Opper adds to the catalog: none of it touches your network setup, because the addresses ride along in the environment every client already reads.
Redundancy without novelty: the standby address is on file with every allowlist before it is ever needed, so a failover reads as routine maintenance rather than a new device showing up.
Teams who picked a European gateway on purpose.
Teams whose DPIA and residency documentation leans on Opper's Stockholm hosting and EU-tagged models, and who need the first hop to be just as defensible.
Serverless and container-platform teams whose Opper calls originate from ever-changing addresses, and who want the gateway to see one steady customer instead.
Shops using Opper's BYOK, spend caps, and no-markup pricing to keep AI costs honest, and who apply the same discipline to where keys and traffic may travel.
Consultancies building client agents on Opper who want the network posture settled once, as a reusable part of every delivery.
Point the SDK at Opper as usual. The fixed exit travels in the environment.
The OpenAI SDK sits on httpx, which reads the standard proxy variables from the environment. Set them, and every request to Stockholm leaves through your fixed pair.
import os
from openai import OpenAI
# HTTPS_PROXY is honoured automatically
client = OpenAI(
base_url="https://api.opper.ai/compat/openai",
api_key=os.environ["OPPER_API_KEY"],
)
r = client.chat.completions.create(
model="anthropic/claude-sonnet-4-5",
messages=[{"role": "user", "content": "Say hello in one sentence."}],
)In Node, install the proxy once per process with undici's ProxyAgent; the OpenAI SDK, LangChain, and anything else on the same runtime inherit it.
import OpenAI from "openai";
import { ProxyAgent, setGlobalDispatcher } from "undici";
setGlobalDispatcher(new ProxyAgent(process.env.HTTPS_PROXY));
const opper = new OpenAI({
baseURL: "https://api.opper.ai/compat/openai",
apiKey: process.env.OPPER_API_KEY,
});Agent container, Opper key, and proxy configuration live together in a git-ignored env file, so no secret ever lands in a compose manifest.
# .env.opper (git-ignored)
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
NO_PROXY=localhost,127.0.0.1
OPPER_API_KEY=op-your-keyservices:
agent:
build: .
env_file: .env.opperOn the pod spec, the pair arrives via secretKeyRef next to the Opper key, never inline in the manifest.
env:
- name: HTTPS_PROXY
valueFrom:
secretKeyRef:
name: outboundgateway
key: proxy-url
- name: OPPER_API_KEY
valueFrom:
secretKeyRef:
name: opper
key: api-keyA pair, not a single point of failure
The proxy URL you store resolves to two independent European nodes. Connections ride whichever is healthy; if one drops for maintenance, its twin absorbs the traffic and your allowlists, logs, and rate-limit history never meet an address they have not seen before.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.
Opper keeps the model hop in the Union. Give the first hop the same address, and residency stops being a footnote hunt.
Prompts with personal data travel from a named European address to a European gateway to EU-tagged models. The transfer description in your records finally describes the whole route.
Deployers of AI systems are asked to document operational safeguards. A fixed, auditable egress for model traffic is one of the easier paragraphs in that file.
Rate limits, abuse heuristics, and provider logs all see the same two addresses every time, which is how well-behaved API clients look.
OpenAI SDK, LangChain, Vercel AI SDK, curl: anything that can read the environment gains the fixed exit, including Opper's newer compatibility endpoints.
Maintenance on one node hands off to the other registered address; no surprise source IP ever appears mid-incident.
Your exit, the gateway, and the models can now all be pinned to the Union, which shortens every residency conversation you will ever have.
With egress confined to known addresses and controlled environments, your 700-model master key gets the perimeter its blast radius deserves.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
You standardized the model hop. Standardize the network hop with two permanent EU IPs and let the rest of the stack stop guessing where your agents call from.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Opper's public documentation centers authentication on API keys and does not advertise source-IP restrictions on them, so treat key-level allowlisting as something to confirm for your specific account or contract. Either way, a fixed egress remains worth having: your requests arrive from known addresses, your EU chain stays intact, and if Opper introduces key-level IP pinning you are already pre-registered with two stable ones.
All of them, because the egress is attached to your environment rather than to any URL. Whether you use the drop-in OpenAI compatibility endpoint at https://api.opper.ai/compat/openai or the newer /v3/compat surface that integrations like LangChain target, requests leave through the same two European addresses.
The relay speaks HTTPS CONNECT and passes the encrypted stream through without decrypting or buffering it, and the exit sits in the EU next to Opper's Stockholm hosting, so the added distance is minimal. Model generation time dwarfs the milliseconds the hop adds, and the pair is redundant enough that latency is the least interesting property to fail over.
Tell us which SDKs and compatibility endpoints your stack uses. We will map out the fixed egress for your whole outbound estate, serverless or Kubernetes.
Contact Our Founders →