How we deliver a public IP in under 5 seconds.
Provisioning used to mean tickets, VPNs, and a support queue. We decided that wasn't good enough — so we rebuilt the experience from the customer backward.
The first time you add a Sidecar label to a Docker container, something happens that still surprises people when they see it for the first time: a real, routable public IP appears — not a proxy, not a tunnel alias, not a port forwarding rule — and it works in under five seconds. That speed is not accidental. It is the result of a deliberate engineering bet we made at the start of the project.
Why speed matters
Developer trust is earned in the first thirty seconds. If you ship a tool that makes someone wait while staring at a spinner, they start to question everything: Is it working? Did it hang? Should I restart it? That uncertainty erodes confidence before the product has had a chance to prove itself.
Traditional approaches to giving a container a public IP — standing up your own VPN server, configuring static port forwarding at the router or cloud firewall level, requesting a floating IP from your provider — all have one thing in common: they take hours at best, and they require you to understand a layer of infrastructure that has nothing to do with your actual application.
We set an internal target early on: provisioning a shared IP should feel as fast as pulling a Docker image. Provisioning a dedicated IP — one that belongs to you alone — should complete before your morning coffee cools down. Those targets became the yardstick against which we evaluated every decision in the provisioning pipeline.
The shared-IP path now completes in roughly five seconds. The dedicated-IP path, which involves allocating an address from our pool and completing configuration across our network, runs in about three minutes. Both are fully automated, zero-touch, and happen without any interaction from you after the initial label.
What the customer sees
From your side of the experience, provisioning looks like this:
You add one label to your docker-compose.yml — something like sidecar.enabled: "true". You bring the container up. Within a few seconds, the Sidecar dashboard shows a live IP address, and that address is already accepting traffic. You can open a browser, run a curl, or point your DNS at it immediately. There is no second step.
If you stop the container, the IP is released back to the pool (or, for dedicated customers, held in reserve). If you restart it, the same IP comes back — or a new one is assigned, depending on your plan. Either way, the state management is handled for you.
We deliberately kept the API surface at the label layer because that is where Docker developers already live. Adding a label to a service definition is a ten-second code change. We did not want the path to a public IP to require learning a new CLI, a new config format, or a new mental model for networking.
The no-config principle
Every piece of configuration we expose to customers is a piece of configuration they can get wrong. Our goal has been to drive that surface area toward zero.
We do not ask you to choose a port. We do not ask you to generate keys, distribute them, or rotate them. We do not ask you to select a relay region — the system picks the lowest-latency option for your host automatically, and you can override it with a single label if you have a reason to. We do not ask you to configure firewall rules on the relay side; isolation between peers is enforced at the infrastructure level.
The things that are genuinely complex — key exchange, relay selection, address allocation, route propagation, health monitoring — happen inside our provisioning pipeline. We have invested significant engineering effort into making that pipeline fast, reliable, and completely invisible to the person running the container.
The principle we return to when making product decisions is: if a customer has to think about how the IP works, we have failed. The IP should just work, the same way a DHCP address just works on a LAN. The only difference is that ours is globally routable, assigned in seconds, and backed by six relay regions across three continents.
Our confidence guarantee
We offer a full refund within the first 14 days, no questions asked. That policy exists because we are confident the provisioning experience will work exactly as described — and because we think the right way to earn a customer's trust is to take on the risk ourselves.
If you add the label and a public IP does not appear within 30 seconds on a shared plan, something has gone wrong on our end, and we want to hear about it. Our uptime monitors fire on provisioning latency as well as connectivity, so we often know before you do.
Speed is not a feature we market and then quietly walk back. It is something our monitoring enforces every day, against real traffic, across all six relay regions.
Related: Post-quantum security in production · Why we use RAM-only storage
Authors