fly ips allocate-egress fails in nrt for me with what looks like a pool-capacity error, and I
can’t tell from the outside whether this is expected, temporary, or something I should design around.
$ fly ips allocate-egress -a livebot-mainnet -r nrt -y
Error: failed to run mutation($input: AllocateEgressIPAddressInput!) { allocateEgressIpAddress(input: $input) { v4, v6 } }: No more egress IPs available for allocation in (nrt)
flyctl v0.4.73, org personal, 2026-07-23 (~09:40–10:30 UTC).
It is not a “the app has no Machines yet” problem. That was my first theory, so I retried on a
second app that already has a Machine in nrt:
| App | Machines in nrt | Result |
|---|---|---|
livebot-mainnet |
none (fresh app) | same error, 3 attempts |
livebot-paper |
1 (deployed, stopped) | same error |
Every other APAC region allocates instantly. I probed and released all three within a couple of
minutes, so this looks specific to nrt rather than a problem with my account or org:
sin: Allocated egress IPs for region sin: 209.71.80.70
bom: Allocated egress IPs for region bom: 209.71.68.71
syd: Allocated egress IPs for region syd: 209.71.97.213
Questions:
- Is the
nrtegress IP pool actually exhausted, or does this error mean something else? - Is more capacity planned for
nrt, and is there any rough sense of timescale? I’m happy to poll,
I just don’t want to poll indefinitely if the answer is “not soon”. - Is there anything I can do from my side — a different allocation path, a request queue, anything?
Why nrt specifically: the app is a single always-on Machine that talks to an external API which
requires a static, allowlisted source IP. Another region is technically fine latency-wise, but the
allowlist is tied to a jurisdiction I’ve already validated from Tokyo, so moving the Machine is a
much bigger change for me than it looks — it isn’t just a region swap.
One small thing regardless of the answer: this failure mode isn’t mentioned on
Egress IP addresses · Fly Docs — the page covers the per-region requirement, the $3.60/mo
price and the 64-Machines-per-IP limit, but not that an allocation can fail because a region is out.
A line there would have saved me a while of debugging my own setup.
Thanks!