Photo by Brett Sayles on Pexels.

Every outbound call SimpleWP makes to a hosting partner has to arrive from somewhere that partner’s own system already trusts. At SimpleWP, calls to WordPress.com’s WP Cloud platform and to DotRoll’s cPanel hosting both rely on one static egress IP address, run by the engineers behind SimpleWP as a relay the team built and operates itself. This is the story of how that relay was designed, what one missing access path revealed once it shipped, and how the design evolved without ever changing what actually keeps it safe. A static egress IP relay sounds like a small piece of plumbing until the day a partner’s allowlist is the only thing standing between a working integration and a silent one.

Why SimpleWP Built a Static Egress IP Relay

Both WP Cloud and DotRoll’s cPanel hosting allowlist callers by source IP address, so every server calling into either platform has to send its traffic from an address the partner has already approved ahead of time. The team’s own hosting platform doesn’t make that simple on its own — like most modern hosting platforms, outbound IP addresses aren’t guaranteed to stay the same across every redeploy, which means a server’s own address can shift without warning. That is a perfectly reasonable way for a hosting platform to work, and it’s also exactly the kind of moving target a partner’s allowlist can’t tolerate. Routing every WP Cloud and DotRoll call through one shared, purpose-built relay solved that mismatch at the source, giving both partners a single static egress IP address to allowlist instead of a moving target they would otherwise have to keep re-approving.

Designing a Static Egress IP Address Relay, Private by Design

The relay’s first design was deliberately narrow in scope: no public listener of any kind, reachable only over the team’s own private network, with a WireGuard peer planned so engineers could reach it securely from their own laptops too. That was an explicit requirement from the start, not a gap the team discovered later — the relay was never meant to be something the open internet could even find. On top of that network-level privacy, the team layered a second control from day one: per-caller authentication and a short, explicit allowlist of destination hosts. That second layer existed specifically because the private network the relay sits on is shared with other, public-facing services, so network isolation on its own could never fully guarantee who could reach it. Two controls doing different jobs, kept deliberately separate, is a pattern that holds up well later in this story.

A Planned WireGuard Access Path That Wasn’t There Yet

The documented WireGuard access path for local development was one piece of the original design that was never actually set up, so the private-only route planned for engineers’ own machines simply didn’t exist once the relay shipped. A design can be correct on paper and still have a step nobody finished. Because the WP Cloud and DotRoll client code was deliberately built with no fallback to a direct connection if the relay couldn’t be reached — a no-fallback principle the team holds to on purpose, so a quiet failure never masquerades as a working one — every WP Cloud call made from a developer’s own machine simply couldn’t reach its destination. The symptoms that followed pointed everywhere except the real cause: sites reporting as degraded, an empty media library, and a newsletter-composition feature failing before it ever reached the AI model behind it. None of those symptoms look like a networking problem on the surface, which is exactly why the no-fallback principle earns its keep: it turns a silent gap into a loud, traceable one instead of letting it hide behind a cluster of unrelated-looking failures.

Evolving the Relay to a Public Listener, With the Real Controls Kept

Once the cause was found, the team’s call was to extend the original design rather than start over: give the relay a public listener after all, while keeping per-caller authentication and the destination allowlist as the controls that actually mattered, rather than leaning on network privacy as the only line of defense. That is the heart of this story — the relay’s real protection was never the fact that nobody outside the private network could find it. It was always the combination of who is allowed to call and where they are allowed to call to, and that combination didn’t have to change at all for the relay to become reachable from outside. The relay only has a shared, non-dedicated public IP address available on its hosting platform (Fly.io), and that platform’s own networking rules mean a shared address can only serve a port other than the two standard web ports, through the platform’s own TLS proxy — which is exactly why the newly public relay listens on a nonstandard port, with the platform terminating encryption at its edge.

Proving the New Design Holds

Verifying a design decision like this one means proving a negative, which is a harder thing to demonstrate than proving a positive. The team ran the check from a machine with no access to the hosting platform’s own private network at all, so the proof would mean something to anyone sitting where an outside caller actually sits. An unauthenticated attempt and a wrongly authenticated attempt were both refused; a correctly authenticated attempt aimed at a destination outside the allowlist was refused too; only a correctly authenticated, allowlisted request ever went through. Four test cases, one outcome each, and only one of the four actually worked — which is the whole point of keeping authentication and an allowlist as the real controls rather than treating a public listener as something to be afraid of on its own.

Two Configuration Improvements From the First Real Deployment

Design and verification are not the end of the story; a first real deployment has its own way of finding what a design review can’t. A separate, pre-existing configuration gap meant the relay’s own listening port had a hardcoded fallback value built into the code, rather than being a required, explicit setting — a shortcut the team’s own no-hardcoded-defaults rule exists specifically to catch, and one that had simply never been caught before. The team closed it by making the port a required setting that fails the service’s startup loudly if it’s ever missing, rather than quietly falling back to a guess that might not match what’s actually deployed. The relay’s first real deployment turned up two more configuration details worth fixing on the spot: the server was listening in a way the hosting platform’s own internal network couldn’t actually reach, defeating the point of a private-reachable relay, and a missing configuration secret meant the service was reading its own encrypted configuration as literal, unencrypted text instead of decrypting it first. Both were caught and fixed in that same first deployment, which is its own small proof that a first deployment is worth treating as part of the design process rather than the end of it.

What’s Different Now for the Fly.io Static Egress IP Relay

The relay’s real controls today are the same ones the team layered in from day one: per-caller authentication and a destination allowlist, not network privacy by itself. What changed is reach — a public listener instead of a private-only one — and what stayed constant is the static egress IP address itself, steady for every WP Cloud and DotRoll call regardless of how the hosting platform redeploys things underneath it. It’s the same discipline behind another engineering story from around the same stretch of infrastructure work: a design that looked finished can still have a gap worth finding, and finding it is what makes the next version better rather than something to be defensive about. SimpleWP’s own prompt gateway has a similar story, asking the same question this one does — whether a design had stopped one step short, not whether it was wrong. If you’re evaluating a hosting partner on more than a features list, see how SimpleWP works with partners like WP Cloud and DotRoll and judge the engineering for yourself.