Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.rafftechnologies.com/llms.txt

Use this file to discover all available pages before exploring further.

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

Auto-assignedReserved
Allocated fromRegional poolReserved out of the pool, held in your account
Cost while attachedFree$3 / month
Cost while unattachedN/A — auto-assigned IPs are always attached$3 / month (continues)
What “detach” doesReturns the address to the pool. Anyone may get it nextRemoves the IP from the VM but keeps it in your account, ready to re-attach
What VM delete doesReleases the IP back to the pool with the VMIP survives — stays in your account
Movable between VMs?No (each detach gets a different address from the pool)Yes — detach + re-attach keeps the same address
Stable across VM rebuild?NoYes
Eligible for DNS / partner whitelisting?Risky — you might lose it on any detachYes — that’s the whole point
API type fieldauto_assignedreserved
Surfaced in dashboard as”Public” tag on the VM’s Network tab”Reserved” tag, shown on Public IPs tab + VM Network tab
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

WorkloadPick
New VM, not in DNS yet, no external dependency on the addressAuto-assigned
Test environment, frequently rebuilt, no contract on the addressAuto-assigned
VM behind a load balancer or reverse proxy where the IP is internal-onlyAuto-assigned
Production web server with an A record pointing at itReserved
API gateway whitelisted by partners by IPReserved
Mail server (MX and PTR records baked in)Reserved
Blue/green deploys — need to swap IPs between candidate VMsReserved
HA / failover where the address must survive a VM rebuildReserved
Anything where “the IP changing” would be a customer-visible incidentReserved
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.

Auto-assign a public IP

Free pool IP for non-stable addresses.

Reserve a static IP

Hold an IP across VM rebuilds for $3/mo.

Features & limits

Concrete numbers — pricing, regional pools, caps.
Last modified on May 8, 2026