🇪🇺 Sovereign AI. Fixed EU egress.

🇪🇺 Static IP for Melious AI

Calling Melious open-weight models from containers or serverless? Every redeploy shifts the IP, breaking IP-restricted keys and your sovereign-AI audit story. Route your Melious traffic through two fixed static EU IPs.

chat.py

from openai import OpenAI

# leaves through static EU IP

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

client = OpenAI(

  base_url="https://api.melious.ai/v1",

  api_key="sk-mel-...")

Why Melious traffic needs a steady source IP

Melious is built to be sovereign and EU-resident, so where your calls come from is half the compliance story. Rotating egress makes it hard to tell that story cleanly.

Keys restricted to a source address

Teams lock their Melious API key to specific IPs. When a pod, container, or function moves to a new address, requests to api.melious.ai come back unauthorized, and chat and completion calls silently stop working.

A new address on every scale event

Cloud functions and Kubernetes assign a fresh outbound IP on each deploy and autoscale. RAG pipelines and chat features that worked at noon fail at midnight with no code change, because the source IP shifted underneath them.

Sovereign-AI and GDPR audits

Processing prompts and model output is data handling under GDPR, and the EU AI Act adds transparency duties. Auditors want a documented, stable egress for AI calls, not an address list that changes every release.

60+ models, one moving target

An app often mixes several open-weight models across services. Each call from each environment rides a different rotating IP, so there is no single, predictable address to whitelist or audit.

When the security review asks

"Which IP addresses do our Melious API calls come from?"

You want one fixed answer, not "it depends which pod served the request."

The Solution

Send Melious calls through a fixed EU IP

Your AI app

HTTPS Proxy

(Static EU IP)

Melious API

Melious sees your calls from the same pair of EU addresses every time, across all 60+ open-weight models. Two IPs back the account, and if one is down the other takes over.

One env var covers every endpoint you hit at api.melious.ai, with no SDK rewrite. The OpenAI client works as-is.
The address holds across pod restarts and autoscaling, so whitelists and audit answers stay valid.
TLS passes straight through, so prompts, completions, and your sk-mel- key stay unreadable at the proxy.

What this gives a Melious deployment

Two fixed EU addresses to whitelist, with automatic failover between them. You stop chasing rotating egress and give Melious one stable thing to trust.
EU to EU end to end. Melious is built as sovereign European AI, and the proxy runs in EU infrastructure, so your model traffic stays within the same jurisdiction.
Lines up with GDPR and the EU AI Act. A documented, stable egress is exactly what a data-protection or AI-governance review wants to see.
Covers the whole model lineup. All 60+ open-weight models leave through the same pair of IPs, so one whitelist covers every model you use.
Works with the OpenAI SDK, requests, fetch, and anything that honours the standard proxy environment variables.

Who it's built for

AI engineers

Building chat, RAG, or tool-using features on Melious open-weight models who need their key to keep working through every container restart.

EU SaaS builders

Shipping EU products on sovereign AI who need IP-whitelisted, GDPR-aligned access across dev and prod.

Public-sector teams

Running workloads on sovereign European AI that require a documented, EU-only outbound path for every model call.

Data protection leads

Accountable for where AI prompts and output are sent, who want a documented EU egress rather than a moving address.

Implementation

Set HTTPS_PROXY and your Melious calls leave through your fixed EU IP. No rewrite to your chat or completion code.

Python (OpenAI SDK)

Melious is OpenAI-compatible, so point the standard OpenAI client at api.melious.ai/v1. With HTTPS_PROXY set, the request leaves through your static IP.

# .env or shell
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
MELIOUS_API_KEY=sk-mel-...

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.melious.ai/v1",
    api_key=os.environ["MELIOUS_API_KEY"],
)

# the SDK honours HTTPS_PROXY from the environment
response = client.chat.completions.create(
    model="gpt-oss-120b",
    messages=[{"role": "user", "content": "Summarize this document."}],
)

print(response.choices[0].message.content)

Node.js (OpenAI SDK)

Same client in Node. The SDK routes through your static EU IP once HTTPS_PROXY is set.

// .env or shell
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
MELIOUS_API_KEY=sk-mel-...

import OpenAI from 'openai';

const client = new OpenAI({
  baseURL: 'https://api.melious.ai/v1',
  apiKey: process.env.MELIOUS_API_KEY,
});

// routes through your static EU IP
const res = await client.chat.completions.create({
  model: 'gpt-oss-120b',
  messages: [{ role: 'user', content: 'Summarize this document.' }],
});

console.log(res.choices[0].message.content);

Docker / Kubernetes / Lambda

Set the variable in your platform config, the same approach in every environment. Never paste the proxy string in plaintext.

# Docker Compose: load a .env file
services:
  app:
    env_file:
      - .env

# Kubernetes: pull it from a Secret
env:
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: outboundgateway-proxy
        key: proxy-url

# AWS Lambda: function environment variables
HTTPS_PROXY=${OUTBOUNDGATEWAY_PROXY_URL}

Two IPs, so a chat call doesn't depend on one box

Your account comes with two static IP addresses (for example 51.xx.xx.10 and 51.xx.xx.11). Register both against your Melious key. If one proxy node is briefly unavailable, traffic shifts to the other, so an overnight redeploy isn't the thing that breaks your AI features.

📖 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.

EU egress for sovereign AI

Melious is built to keep AI in Europe, so the outbound path should stay in Europe too.

European infrastructure

The proxy runs in EU data centres, so your Melious API traffic stays within European borders rather than wherever a container happens to be scheduled.

GDPR and EU AI Act aligned

Processing prompts and model output is data handling. A stable, documented EU egress is the kind of detail both a GDPR review and an AI-governance review ask for.

No transatlantic detours

Traffic doesn't bounce through US infrastructure on its way to Melious, which keeps the sovereign-AI promise intact and removes a wrinkle from data-transfer reviews.

An egress you can name

When a reviewer asks where your Melious calls originate from, the answer is two fixed EU addresses, not a list that changes every release. The failover pair covers maintenance windows.

Why teams route Melious through OutboundGateway

A pair of fixed IPs

Two addresses to register against your key, with automatic failover, so your traffic isn't riding on a single point of failure.

No app rewrite

Add one env var and the OpenAI SDK pointed at Melious starts routing through the proxy. Your chat code stays as-is.

EU-hosted

European data centres and a GDPR-conscious setup, so your Melious traffic leaves from a predictable EU address.

All open-weight models

All 60+ models on Melious go out through the same stable pair of IPs, so one whitelist covers every model you use.

Encrypted end to end

TLS passthrough means the proxy can't read your traffic. Prompts, completions, and your sk-mel- key stay private the whole way.

Flexible plans

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

Give your Melious calls a fixed EU egress

Stop letting pod restarts and autoscaling decide which IP your model calls come from. Put Melious behind one stable, GDPR-conscious address.

€29/month starter plan • 7-day refund policy • Direct founder support

Frequently asked questions

Does this work with the standard OpenAI SDK?

Yes. Melious is OpenAI-compatible, so you use the normal OpenAI Python or JavaScript client and point its base URL at https://api.melious.ai/v1 with your sk-mel- key. Setting HTTPS_PROXY routes those calls through the proxy without changing how you build the request.

Will an IP-restricted Melious key keep working after a redeploy?

That's the main reason teams add the proxy. Melious keys can be tied to specific source IPs, but containers and functions get a new address on every deploy, which would normally break that restriction. By routing outbound calls through a fixed pair of EU addresses and registering both against the key, the key keeps authorising requests no matter how often your deployment restarts.

Does it cover all the open-weight models, not just one?

Yes. The proxy isn't model-specific. Any call your app sends to api.melious.ai, across all 60+ open-weight models, leaves through the same fixed pair of EU IPs, so one whitelist covers your whole model lineup.

Still weighing it up?

Happy to talk through how a two-IP egress fits your specific Melious setup, whether it's chat, RAG, or agents.

Contact Our Founders →