Koyeb doesn't publish static outbound IPs, and each Service gets dynamic egress as it scales. That breaks calls to IP-whitelisted HTTPS APIs. Add two fixed static EU IPs via an HTTPS proxy set as an env var.
# env on the Koyeb Service
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
# app.py - calling an IP-whitelisted API
import requests
r = requests.get(
"https://api.partner.eu/orders",
headers={"Authorization": "Bearer .."}
)
The catch with Koyeb isn't your code. It's that the platform gives your Services a moving egress and offers no way to pin it.
Koyeb's own FAQ is clear: it does not provide a list of static outbound IPs your Services deploy to. If an API only allows known addresses, there is no platform setting that hands you one.
Koyeb scales Services up and down across shared infrastructure, so the source IP changes between runs. A call that reached an IP-whitelisted API at noon can be blocked by midnight with no change to your service.
A lot of what people call from Koyeb (payment providers, B2B partner APIs, IP-restricted SaaS) demands a known source IP. Without one, the integration is either wide open or simply unreachable.
A typical Koyeb account runs several Services across regions. Each leaves from a different rotating address, so there is no one IP to hand a partner or to point at in an audit.
"What IP will your Koyeb app call from, so I can allow it?"
You want one fixed answer that holds across every scale event, not "whichever instance Koyeb happened to run."
Koyeb Service
HTTPS Proxy
(Static EU IP)
Whitelisted API
Every outbound HTTPS call from your Koyeb Service leaves from the same pair of EU addresses, whether it's a partner API or a payment endpoint. Two IPs back the account, and if one is down the other takes over.
requests, fetch, and axios honour HTTPS_PROXY with no code changes.
Running Koyeb Functions and Services that need to reach IP-whitelisted partner APIs behind an allowlist.
Fast-growing European companies on Koyeb that need consistent, GDPR-aligned outbound access across Services.
Connecting Koyeb-hosted apps to enterprise APIs that only accept traffic from known source addresses.
Accountable for where their Koyeb Services send data, who want a documented EU egress rather than an ever-changing address.
Set HTTPS_PROXY as an environment variable on your Koyeb Service. Outbound calls then leave through your fixed EU IP, with no service rewrite.
Add HTTPS_PROXY in the Koyeb console (Service > Settings > Environment variables). The requests library reads it automatically, so a normal call to an IP-whitelisted API already leaves through your static IP.
# Koyeb Service environment variable
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
PARTNER_API_TOKEN=your_token
import os
import requests
# requests honours HTTPS_PROXY from the environment automatically
r = requests.get(
"https://api.partner.eu/orders",
headers={"Authorization": f"Bearer {os.environ['PARTNER_API_TOKEN']}"},
)
print(r.status_code) # 200, from your static EU IP
Node's fetch doesn't read the env var on its own, so pass the proxy explicitly with https-proxy-agent.
// Koyeb Service environment variable
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
PARTNER_API_TOKEN=your_token
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
// This GET leaves through your static EU IP
const res = await fetch('https://api.partner.eu/orders', {
headers: { 'Authorization': `Bearer ${process.env.PARTNER_API_TOKEN}` },
agent,
});
console.log(res.status); // 200Add it as a Service environment variable in the Koyeb console, and store the proxy URL in a Koyeb Secret so it never sits in plaintext.
# Koyeb console: Service > Settings > Environment variables
HTTPS_PROXY = @secret:OUTBOUNDGATEWAY_PROXY_URL
# Koyeb Secret (created under Secrets):
OUTBOUNDGATEWAY_PROXY_URL = https://user:pass@eu-01.outboundgateway.com:8443
# In code, read it like any env var
proxy = os.environ["HTTPS_PROXY"]Two IPs, so a scale event doesn't break your integration
Your account comes with two static IP addresses (for example 51.xx.xx.10 and 51.xx.xx.11). Whitelist both on your partner API. If one proxy node is briefly unavailable, traffic shifts to the other, so a Koyeb autoscale isn't the thing that severs your connection.
📖 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 Koyeb Services send data to partners, controlling where it leaves from matters. EU-hosted egress keeps that path predictable.
The proxy runs in EU data centres, so your Koyeb Service's outbound traffic leaves from European infrastructure rather than wherever the instance happens to be scheduled.
Because TLS passes straight through, the proxy never decodes your API tokens or request payloads. It forwards encrypted bytes; it doesn't read them.
Traffic doesn't bounce through US infrastructure on its way to your partner API, which removes a common wrinkle from GDPR data-transfer reviews.
When a partner asks where your Koyeb app calls from, the answer is two fixed EU addresses, not a list that changes with every scale event. The failover pair covers maintenance windows.
Two addresses to register, with automatic failover, so your traffic isn't riding on a single point of failure.
Add one env var in the Koyeb console and your existing requests or fetch code starts routing through the proxy.
Since Koyeb offers no native static egress, this is how your Services reach IP-whitelisted APIs at all.
Functions, Apps, and Services all leave through the same stable pair of IPs, across every region.
TLS passthrough means the proxy can't read your traffic. Tokens and request data stay private the whole way.
Starting from €29/month. Flexible plans for every scale. Cancel anytime.
Stop letting Koyeb's dynamic egress block your IP-whitelisted APIs. Put your Services' outbound traffic behind one stable, GDPR-conscious address.
€29/month starter plan • 7-day refund policy • Direct founder support
No. Koyeb's own FAQ states it does not provide a list of static outbound IPs that your Services deploy to. Each Service gets dynamic egress that shifts as it scales. That's exactly why teams add a proxy: to supply the fixed pair of EU addresses Koyeb doesn't offer natively.
Add HTTPS_PROXY as an environment variable on your Service in the Koyeb console (Service > Settings > Environment variables). Store the proxy URL in a Koyeb Secret and reference it, so it isn't in plaintext. Standard clients like requests then honour it automatically; in Node, pass it to https-proxy-agent.
Yes, that's the main use case. If a partner API only accepts calls from known IPs, you whitelist the two fixed EU addresses on their allowlist. Your Koyeb Service then calls through the proxy, so the request arrives from an allowed source even as Koyeb scales your instances. Note this is for outbound HTTPS only, not SOCKS5 or raw TCP, so it suits HTTP-based APIs rather than direct database connections.
Happy to talk through how a two-IP egress fits your specific Koyeb setup, whether it's a partner API or a payment endpoint.
Contact Our Founders →