Verda (formerly DataCrunch) gives you elastic European GPU compute, but each new deployment leaves through a newly assigned public IP. Route training and inference traffic through two fixed static EU IPs with one HTTPS_PROXY variable.
# on the instance, e.g. in ~/.bashrc
export HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
export NO_PROXY=localhost,127.0.0.1
import requests
# requests and httpx read HTTPS_PROXY
r = requests.get(
"https://api.partner.eu/datasets",
headers={"Authorization": "Bearer ..."})
Verda is built for elastic AI compute: spin up H100s for a training run, tear them down, let serverless containers scale with inference traffic. But every deployment arrives with a fresh public address, and IP whitelisting does not stretch that far.
A Verda user asked on the Verda forum how to keep instance IPs static, because their external services enforce IP whitelisting and, in their words, "I shouldn't have to whitelist a new IP every time." Each new instance deployment receives a newly assigned address, so every redeploy means another allowlist update on someone else's console.
Auto-scaling serverless containers, per-job clusters, instances created and destroyed on demand: scaling out is not an incident on Verda, it is the normal operating mode. An allowlist pinned to specific instance addresses breaks at exactly the moment the platform is designed for.
Fine-tuning and inference workloads rarely run in isolation. They pull from data platforms, call partner APIs, post to webhooks, and hit LLM endpoints, several of which filter by source address. A redeploy partway through a long run quietly changes who your job claims to be.
In that same forum thread, the Verda team confirmed: "We currently don't support this feature but it is planned on the roadmap." Roadmaps are honest intentions, but a partner security review or a banking integration scheduled for this quarter needs a stable source address today.
Your GPU Workloads
instances, clusters, containers
HTTPS Proxy
(Static EU IP)
Partner APIs
with IP allowlist
Whether your workload runs on a fresh GPU instance, a job cluster, or an auto-scaled container, it presents the same two EU addresses to the outside world. Whitelist once, then deploy and tear down as aggressively as your training schedule demands.
Teams doing AI work on Verda who still need the outside world to recognize them.
Your fine-tuning runs pull from data platforms and partner APIs that filter by source address. Give every job, on every instance, the same stable identity.
Serving traffic from serverless containers that scale with demand? Calls into payments, partners, and internal APIs should not depend on which replica answered.
You picked European GPU compute on purpose. European egress completes the picture, with no detour outside the EU to reach an allowlisted endpoint.
Verda alongside other clouds? One proxy pair standardizes egress everywhere, so allowlists reference two addresses instead of one range per provider.
Set the variable in the environment your workload already runs in. The next process or container that starts egresses from the fixed pair.
Add the export to your shell profile so every SSH session and job launcher picks it up, then source it or reconnect. Keep the credentials out of committed files.
# ~/.bashrc or ~/.zshrc on the instance
export HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
export NO_PROXY=localhost,127.0.0.1
# apply without reconnecting
source ~/.bashrcFor Docker-based workloads, pass the variable when the container starts. The same pattern applies to container definitions for serverless deployments: provide the environment, the app reads it.
# docker run
docker run -e HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443 \
-e NO_PROXY=localhost,127.0.0.1 \
your-inference-image
# docker-compose.yml
services:
trainer:
environment:
- HTTPS_PROXY=${OGW_PROXY_URL}
- NO_PROXY=localhost,127.0.0.1requests and httpx read HTTPS_PROXY from the environment automatically. No code changes.
import os
import requests
# picked up from HTTPS_PROXY in the instance environment
r = requests.get(
"https://api.partner.eu/datasets",
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/datasets', {
headers: { 'Authorization': 'Bearer ..' },
agent,
});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 workloads online, whatever Verda instance or container 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 Verda already says something about where your AI workloads live. 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 allowlisted API.
Traffic to partner APIs leaves from EU addresses through EU infrastructure, which simplifies the data-processing story you tell customers and auditors.
European GPU compute 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 between deployments.
Instances, clusters, and serverless containers all present the same pair, with automatic failover between them.
Tear down and recreate instances freely. The whitelisted addresses stay attached to your account, not to any machine.
European data centres and a GDPR-conscious setup, so egress matches where your GPUs already are.
Python, Node, and any runtime that honours HTTPS_PROXY. One pair covers scripts, jobs, and services alike.
TLS passthrough means the proxy never sees plaintext. Tokens, payloads, and model traffic remain private.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Stop re-whitelisting every deployment. One environment variable, and every instance, cluster, and container you run egresses through the same two fixed EU IPs.
€19/month starter plan • 7-day refund policy • Direct founder support
Not yet. In the Verda forum thread on static IPs, the team confirmed: "We currently don't support this feature but it is planned on the roadmap." They also noted that each instance keeps its IP for the duration of its existence, but a new deployment means a newly assigned address. A proxy fills the gap in the meantime: your whitelisted identity belongs to your account, not to any instance.
Within one instance's lifetime, yes: Verda says the address stays static while the instance exists, even if it is shut down for maintenance. The boundary is deployment. Create a new instance, scale out a serverless container, or launch a fresh job cluster, and that workload gets a new public address. Routing outbound traffic through the proxy removes that dependency entirely.
For Python workloads using requests or httpx, no: they read HTTPS_PROXY from the environment automatically, so exporting the variable on the instance or in the container is enough. Node's built-in fetch ignores proxy environment variables, so Node services need a small change with https-proxy-agent, shown in the implementation above.
Happy to talk through how a two-IP EU egress fits your Verda setup, from a single prototype instance to a full training cluster.
Contact Our Founders →