Skip to main content

Exchange API Key IP Allowlisting

VolatiCloud does not support IP allowlisting for exchange API keys, and we have no egress IP list to publish. Bots on our infrastructure do not have a fixed outbound IP address, so there is nothing you could put in your exchange's IP restriction field that would keep working.

This is a consequence of how the platform runs bots, described in Why there is no IP list below. It is not a pending feature.

Do not allowlist IP addresses you discover yourself

If you inspect your exchange's API access logs and find the addresses VolatiCloud currently connects from, do not put them in an IP allowlist. Those addresses can change at any time, without notice, and they change while your bot is running.

The failure mode is the dangerous one: a bot that has been trading happily for weeks starts getting authentication rejections from the exchange mid-session, with open positions it can no longer manage. The addresses being stable for months is exactly what makes this trap convincing.

Resolving our domain names will not give you a usable answer either. The address our public site answers on is not the address a bot connects to your exchange from.

What to Do Instead​

A key connected to VolatiCloud is protected by a control we enforce, not one you have to remember to configure.

Disable withdrawals — this is the one that matters​

VolatiCloud only accepts exchange API keys with the withdrawal permission disabled. The backend probes the exchange's permission API when you save a connection and rejects any key that can move funds off-exchange. You cannot store a withdrawal-capable key here even if you try.

That gives you a concrete guarantee: in the worst case anyone can construct — your key leaking, our database being exfiltrated in full — the holder of that key can attempt adverse trades, but cannot withdraw your funds. The outcome is bounded at "what could someone do to my open positions", not "my balance is gone".

This is the substantive protection. IP allowlisting was only ever the second layer, and losing it does not change the fund-drainage guarantee at all. See The Withdrawal-Disabled Rule for how the check works.

Scope the key down​

Turn off every permission your strategy does not use — futures for a spot-only bot, margin and borrowing for a long-only bot. A smaller scope is a smaller blast radius, and unlike an IP allowlist it holds regardless of where the request comes from. See Permission Scoping.

Use a dedicated sub-account​

Most exchanges let you create a sub-account and fund it with only the capital you intend to trade. A key issued against that sub-account cannot reach the rest of your balance. This is the closest available substitute for the containment people are usually reaching for when they ask about IP allowlisting, and it is stronger in one respect: it limits what the key can touch even from an address you trust.

Rotate on a schedule​

Rotate exchange keys every 90 days so any undetected leak has a bounded lifetime. The procedure is in Rotation Cadence.

Why There Is No IP List​

Bots on VolatiCloud-operated infrastructure run as containers on a pool of cluster nodes. Outbound connections are translated to the public address of whichever node the bot happens to be running on, and nothing pins a bot to a particular node:

  • The node pool autoscales, so the set of possible addresses grows and shrinks with load.
  • A bot is rescheduled onto a different node routinely — during deploys, node replacement, or rebalancing — and its outbound address changes with it. This happens on every reschedule, not only when a node is retired.
  • We hold no reserved or dedicated IP addresses that would let us pin outbound traffic to a stable set.

So there is no such thing as "the VolatiCloud egress IPs". There is a set of addresses that happens to be in use right now, which is a different thing, and building a security control on it would hand you a bot that breaks without warning.

Supporting IP allowlisting properly would mean routing all bot and control-plane traffic through dedicated fixed-address egress infrastructure. That is an architectural change, not a list we have not got around to writing down. If it ever ships, this page will describe it — we are not going to promise it here in the meantime.

If Your Exchange Requires an IP Allowlist​

Some exchanges make an IP restriction mandatory for the key type or permission set you need, or expire keys that have no IP restriction. Policies differ by venue and change over time, so check your exchange's own API documentation before you fund an account for bot trading.

If your exchange will not issue a usable trading key without an IP allowlist, that exchange cannot be used with VolatiCloud. There is no workaround, and you should know that before you wire up funds rather than after. The symptom, if you connect one anyway, is an authentication failure the moment you try to save the connection — and no amount of re-entering the key will fix it.

Running your own runner does not change this. A Docker or Kubernetes runner executes the Freqtrade container on infrastructure you control, and your server's address is stable — but it is not the only address the key gets used from. VolatiCloud's control plane calls the exchange directly as well: to probe the key's permissions when you first save the connection, to re-scan connected keys for withdrawal capability afterwards, and every time you use Test Connection. Those calls leave from our infrastructure, with the same non-fixed address as everything else, so an allowlist holding only your runner's address will reject them.

  • API Key Handling — Withdrawal-disabled enforcement, at-rest encryption, permission scoping, rotation.
  • Threat Model — The actors we model, what we defend against today, and the gaps we publish.
  • Runners Overview — Running bots on your own Docker host or Kubernetes cluster.
  • Exchanges Overview — How to add an exchange connection to VolatiCloud.
Last updated on