🇪🇺 Fixed egress for self-hosted deployments

🇪🇺 Static IP for Coolify

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.

Configuration > Environment Variables

# 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 ..."})

The Problem

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.

Every server in your fleet has a different IP

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.

Migrations and rebuilds churn your egress

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.

Homelab connections rotate

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.

Cheap VPS ranges arrive pre-flagged

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.

The Solution

One fixed EU IP pair for every server Coolify manages

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

An environment variable, not a networking project. Coolify already injects variables into every container it deploys; the proxy just rides along.
Scope it per app, or define it once as a Shared Variable and reference it from every application in the project.
TLS passthrough. API tokens, webhook payloads, and customer data stay unreadable at the proxy.

Who this is built for

Coolify users moved off managed platforms to own their infrastructure. An EU egress pair finishes the job.

Self-hosters who left Vercel and Heroku

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.

Agencies with a VPS per client

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.

Homelab and automation operators

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.

EU teams with data-residency concerns

Your servers are in Europe and your compliance story should be too. Egress stays inside the EU, which keeps GDPR conversations short.

Implementation

Set the variable where Coolify already manages your app configuration. Redeploy, and outbound traffic egresses from the fixed pair.

Per app: Configuration > Environment Variables

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

Whole fleet: define it once as a Shared Variable

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}}

Python apps

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.js apps

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,
});

Docker Compose deployments

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.

Self-hosted in Europe, egressing from Europe

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.

GDPR-aligned routing

Traffic to partner APIs leaves from EU addresses through EU infrastructure, which simplifies the data-processing story you tell customers and auditors.

Sovereignty end to end

Your servers, your Coolify instance, and a European egress pair. No part of the outbound path depends on a non-EU provider.

Predictable origin

Two stable addresses make your integrations auditable: partners can pin exactly where your traffic comes from, and it stops moving.

Why Coolify operators choose OutboundGateway

Two addresses, whole fleet

Every server Coolify manages presents the same pair, with automatic failover between them.

No server reconfiguration

No iptables, no WireGuard, no NAT rules. The change lives in Coolify's environment settings, where you already work.

EU-hosted

European data centres and a GDPR-conscious setup, so egress matches where your servers already are.

Works across the stack

Python, Node, and any runtime that honours HTTPS_PROXY. One pair covers web apps, APIs, and one-click services alike.

Encrypted end to end

TLS passthrough means the proxy never sees plaintext. Tokens, payloads, and customer data remain private.

Flexible plans

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

Give your Coolify fleet a fixed EU IP

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

Frequently Asked Questions

Does Coolify provide static outbound IPs?

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.

Do I need to change my Dockerfiles or app code?

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.

Can I apply the proxy to every app on every server at once?

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.

Still deciding?

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 →