Coolify deploys your apps to your own servers, so outbound traffic exits from whichever machine an app lands on. Route the whole fleet through two fixed static EU IPs with one HTTPS_PROXY variable in the Coolify UI.
# Coolify: app > Configuration > Environment Variables
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
NO_PROXY=localhost,127.0.0.1
import requests
# the container runtime reads HTTPS_PROXY
r = requests.get(
"https://api.partner.eu/orders",
headers={"Authorization": "Bearer ..."})
Coolify gives you a Vercel-style dashboard over your own servers. The trade-off: your outbound identity is whatever your servers happen to be, and IP whitelisting breaks the moment that changes.
Coolify's strength is managing many servers from one dashboard: a Hetzner box for production, an OVH box for staging, a mini PC at home. Each one exits through its own public IP, so a partner API allowlist has to be maintained per server. Move an app between servers and it silently loses its whitelisted identity.
Coolify makes it painless to rebuild a server, switch providers, or re-provision a VPS. The new machine comes with a new address. Endpoints that filter by source IP start returning 403s and nothing in the deploy log points you at the cause, because the deployment itself succeeded.
Plenty of Coolify installs run on residential or small-business lines with dynamic addressing. Your ISP renews the lease, the router re-dials, and automations that call IP-filtered APIs stop passing the filter until someone notices.
Budget cloud subnets are shared and recycled. The address your new Coolify server inherited may already sit on a WAF blocklist or an API vendor's abuse list because of whatever the previous tenant did with it, and appeals take longer than a re-provision.
Apps on the Hetzner box, the OVH box, and the mini PC under your desk all present the same two EU addresses to the outside world. Whitelist once, and it holds no matter where a workload runs.
Your servers
Hetzner • OVH • homelab
Apps & one-click services
HTTPS_PROXY set per app
OutboundGateway
two fixed EU IPs
Destinations
partner APIs • webhooks
Coolify users moved off managed platforms to own their infrastructure. An EU egress pair finishes the job.
You run Coolify for the control and the price. When a partner API asks for a stable source address, you shouldn't have to go back to a managed cloud to get one.
Each client gets its own server, so each client's integrations currently need their own allowlist entry. Collapse the fleet to one address pair and onboarding a client stops touching firewall rules.
n8n workflows, bots, and scheduled jobs that call IP-filtered services deserve better than a dynamic residential address that drops out after a router reboot.
Your servers are in Europe and your compliance story should be too. Egress stays inside the EU, which keeps GDPR conversations short.
Set the variable where Coolify already manages your app configuration. Redeploy, and outbound traffic egresses from the fixed pair.
Open the application, add the variable under Configuration > Environment Variables, leave it a runtime variable, and restart the app so the container is recreated with the new environment. Use Developer view to paste several lines at once.
# Coolify app environment (Developer view)
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
NO_PROXY=localhost,127.0.0.1
Create the proxy URL at team, project, or environment scope, then reference it from any app. One edit updates every application that points at it.
# In each app's Environment Variables
HTTPS_PROXY={{environment.OGW_PROXY_URL}}
requests and httpx read HTTPS_PROXY from the container environment automatically. No code changes.
import os
import requests
# picked up from HTTPS_PROXY set in Coolify
r = requests.get(
"https://api.partner.eu/orders",
headers={"Authorization":
f"Bearer {os.environ['PARTNER_TOKEN']}"},
)
Node's fetch does not follow proxy environment variables on its own. Wire it explicitly with https-proxy-agent.
const { HttpsProxyAgent } = require('https-proxy-agent');
const agent = new HttpsProxyAgent(process.env.HTTPS_PROXY);
const res = await fetch('https://api.partner.eu/orders', {
headers: { 'Authorization': 'Bearer ..' },
agent,
});
Coolify detects ${...} references in your Compose file and surfaces them as application variables, so the URL never sits hardcoded in the repository.
# docker-compose.yml, deployed through Coolify
services:
api:
environment:
- HTTPS_PROXY=${OGW_PROXY_URL}
- NO_PROXY=localhost,127.0.0.1
Whitelist both IPs, everywhere
Your account includes two fixed IP addresses. Add both to every allowlist you maintain. Traffic balances across the pair, and if one proxy node drops out the other keeps your apps online, on any server they run on.
📖 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.
Choosing Coolify already says something about where you want your workloads. OutboundGateway keeps the outbound leg consistent with that choice: European data centres, GDPR-conscious handling, and no detour through overseas infrastructure just to reach an API.
Traffic to partner APIs leaves from EU addresses through EU infrastructure, which simplifies the data-processing story you tell customers and auditors.
Your servers, your Coolify instance, and a European egress pair. No part of the outbound path depends on a non-EU provider.
Two stable addresses make your integrations auditable: partners can pin exactly where your traffic comes from, and it stops moving.
Every server Coolify manages presents the same pair, with automatic failover between them.
No iptables, no WireGuard, no NAT rules. The change lives in Coolify's environment settings, where you already work.
European data centres and a GDPR-conscious setup, so egress matches where your servers already are.
Python, Node, and any runtime that honours HTTPS_PROXY. One pair covers web apps, APIs, and one-click services alike.
TLS passthrough means the proxy never sees plaintext. Tokens, payloads, and customer data remain private.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Stop maintaining allowlists per server. One environment variable, and every app on every server you manage egresses through the same two fixed EU IPs.
€19/month starter plan • 7-day refund policy • Direct founder support
No. Coolify deploys applications as Docker containers on servers you connect, so outbound traffic uses whatever public address each server has. Coolify manages the deployment, not your egress identity. A proxy fills that gap without touching the servers themselves: apps keep running where they are and present a fixed pair of EU addresses instead.
For Python apps using requests or httpx, no: they read HTTPS_PROXY from the container environment automatically, and Coolify injects that variable when it recreates the container. Node's built-in fetch ignores proxy environment variables, so Node apps need a small change with https-proxy-agent, shown in the implementation above.
Yes. Create the proxy URL once as a Coolify Shared Variable at team, project, or environment scope, then reference it (for example {{environment.OGW_PROXY_URL}}) in each application's environment. Update the shared value and every referencing app picks it up on its next restart, whether it runs on your cloud VPS or your homelab machine.
Happy to talk through how a two-IP EU egress fits your Coolify setup, from a single VPS to a mixed fleet spread across providers.
Contact Our Founders →