Auto-assigned vs reserved IPs

_{Updated May 8, 2026} Raff has two distinct lifecycles for a public IP. The dashboard, the API, and the billing system all treat them as different first-class objects — choose the wrong one and you’ll either pay too much for an address you don’t need to keep stable, or lose an address you wanted to preserve. This page is the side-by-side reference. Most of what’s here is repeated in the quickstart guides; the difference is that this page is just the model, no walkthrough.

​

The two lifecycles

The simplest way to remember it: auto-assigned = the VM owns it, reserved = your account owns it.

​

Why two lifecycles exist

Cloud providers used to give every VM “a public IP” and called it a day. The problem is that two very different needs were sharing one mechanism:

• The “I just want this VM on the internet” need — short-lived, replaceable, no commitment. Free is good. Whatever IP you got is fine.
• The “I have published this IP somewhere I can’t easily change” need — DNS records, customer firewalls, certificate-pinned clients, partner whitelists. The address is a contract. It can’t change without coordinated work.

Mixing the two in one bucket means either:

• Charging for everything so the addresses survive (everyone pays even though most don’t care), or
• Releasing on detach so the free path works (and breaking everyone who cared about stability)

Splitting them — auto-assign for transient, reserve for stable — lets each get the right behavior. You only pay $3/month when you opt into stability; everyone else gets free public IPs without a meter.

​

The lifecycle, picture by picture

​

Auto-assigned

Detaching is terminal — the IP doesn’t come back to your account. If you re-add a public IP to the same VM later, you get a different address.

​

Reserved

The IP stays yours through every state except after Release. Billing runs continuously through every state except after Release.

​

When to pick which

Rule of thumb: if you’d write a runbook step that says “update DNS record” when the IP changes, you should be on a reserved IP and not have that step at all.

​

Cost framing

A reserved IP costs $3/month — $36/year. That’s roughly equivalent to:

• One hour of a small VM
• One terabyte-month of object storage above the free tier
• Half a tank of coffee at most cafés

For anything in production, it’s well below the cost of an outage caused by a partner’s whitelist breaking after a VM rebuild. Don’t optimize against $3/month at the cost of address stability — it’s not a sensible trade-off for production workloads.

​

What’s the same regardless of type

Both auto-assigned and reserved IPs share these properties:

• IPv4 and IPv6 are both supported (one of each per VM from the dashboard; more via support)
• Both are routable on the public internet — same upstream, same MTU, same gateway
• Both can have a Firewall attached to filter inbound traffic (see Firewall when written)
• Both bill the same way — continuous accrual, settled month-end on the 1st (auto-assigned just bills at $0)
• Both are region-locked — an IP allocated in us-east can only attach to us-east VMs
• Both count toward the same per-VM cap — one IPv4 and one IPv6 per VM from the dashboard

The only thing the type affects is what happens when the IP is detached or the VM is deleted.

​

What about Gateway IPs?

A third category exists in the Public IPs list — gateway IPs that belong to a VPC’s Internet Gateway. These are tagged Gateway and aren’t directly assignable to VMs:

• They’re allocated automatically when you Enable a Platform Router (free, returned on Disable) or Deploy a Firewall Appliance (rolled into the appliance VM’s price)
• They can’t be moved by hand, reserved, or released through the Public IPs tab — they’re tied to their gateway’s lifecycle
• They appear in the Public IPs list for visibility, not for direct management

If you delete the gateway, the gateway IP returns to the pool the same way an auto-assigned IP does.

​

Related