Six problems.
One /32.
One dedicated premium Los Angeles IPv4 /32, tunneled to a server you already run. Here is what people actually do with it.
What problem are you solving?
Serve users in China without moving your server
The problem: your app runs fine from Europe or North America, but visitors in China see timeouts and dial-up speeds. Ordinary transit into China is congested, especially at peak hours.
With Pathfabric: tunnel a service to the server you already have and publish its Pathfabric IP. Traffic to and from China rides premium CN2 GIA, CMIN2, and China Unicom Premium routes through Los Angeles. The server itself never moves.
Fit: any tunnel · metered for spiky traffic, unmetered for steady load
No server migration. Publish the new IP.
Take your IP with you when you change providers
The problem: every server move means DNS changes, propagation delays, re-issued allowlists, and a weekend of watching for stragglers hitting the old address.
With Pathfabric: publish the Pathfabric /32 instead of the provider’s address. When you switch providers, run the install script on the new machine and the same IP answers there. DNS never changes; nobody’s allowlist breaks.
Fit: WireGuard makes moves easiest · works with GRE/IPIP too
The paperwork happens once.
A real static IPv4 behind CGNAT
The problem: your homelab or office box sits behind carrier-grade NAT. No inbound connections, no port forwarding, no static address, and your ISP will not sell you one.
With Pathfabric: WireGuard dials out from behind the NAT, and the dedicated /32 terminates on your machine. Run anything on any port, TCP or UDP, exactly as if the box had its own public address, because now it does.
Fit: WireGuard · NAT and roaming friendly
Self-hosted services, game servers, home automation you can actually reach, SSH without a relay, and demo environments on hardware you own.
Premium path only for the traffic that matters
The problem: your provider’s bulk bandwidth is cheap and fine for backups and updates. Paying premium rates for all of it makes no sense, but a few services genuinely need the better route.
With Pathfabric: the installer’s default mode keeps your provider as the ordinary route. Only connections bound to the Pathfabric IP use the premium path, and inbound traffic to the /32 always arrives through the tunnel. One server, two routes, each doing what it is good at.
Fit: metered · pay per GiB only for the traffic you steer
Each route does what it is good at.
An IP with no noisy neighbors
The problem: on shared or NATed egress, someone else’s abuse gets your traffic blocklisted. You find out when your users do.
With Pathfabric: the /32 is assigned exclusively to your service while it is active. Other customers do not share the address.
Fit: any tunnel · any plan
APIs and webhooks that must not be collaterally blocked, services scored by IP reputation, and anything where “it works for everyone except…” costs real money.
A fixed source IP for partner integrations
The problem: a bank, partner, or upstream API requires a fixed source IP for its allowlist, but your infrastructure redeploys, autoscales, or just changes providers occasionally.
With Pathfabric: bind outbound connections to the /32 and the partner sees the same address forever, regardless of where the workload actually runs this quarter. The paperwork happens once.
Fit: any tunnel · metered because integration traffic is usually small
Payment and banking APIs, SFTP drops, partner VPN peers pinned to an address, and compliance environments that audit source IPs.
Sound like your problem?
See full pricing →From $0.99/mo + transfer · prepaid vouchers · no card on file