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 A reserved IP can be moved from one VM to another without changing the address. Detach it from VM A, attach it to VM B — the IP stays the same, your DNS records stay valid, partner whitelists stay correct, and the only thing that changes is which server traffic lands on. This is the standard pattern for blue/green deploys, manual failover, and “promote a candidate VM by repointing the IP” workflows. This page covers reserved IPs only. Auto-assigned IPs cannot be moved — when you detach an auto-assigned IP, it returns to the regional pool and may be allocated to someone else. If you need this workflow, reserve an IP first.

​
Before you start

  • A reserved IP — the Type column on the Public IPs tab will say “Reserved” (not “VM” or “Gateway”)
  • A target VM in the same region as the IP — IPs are region-locked
  • The target VM should not already have a public IP of the same type (IPv4 ↔ IPv4, IPv6 ↔ IPv6) — remove its existing one first, or assign the moved IP to the IPv6 slot if it’s free

​
1. Detach from the source VM

Two equivalent paths — pick whichever is closer:
FromHow
VM detail → Network tabClick Remove Public IP on the IP’s card. Confirm the dialog (it shows “reserved IP — will stay in your account”).
Networking → Public IPsFind the IP’s row, click ⋮ → Detach from VM.
Networking diagramClick the blue IP chip floating above the source VM → Detach from VM.
The IP detaches in seconds. On the Public IPs tab, the row’s Assigned To column now reads — (or Unassigned) and the IP is ready to re-attach. The address stays the same. Active SSH/RDP/HTTP sessions to the IP drop because they’re now hitting nothing — that’s expected. DNS records pointing at this IP keep resolving correctly; they just temporarily don’t have a backend until you complete step 2.

​
2. Check the target VM — and remove any existing public IP of the same type first

The target VM must not already have a public IP of the same type (IPv4 or IPv6). A VM holds at most one public IPv4 and one public IPv6 from the dashboard — if you try to attach a reserved IPv4 to a VM that already has an IPv4 (auto-assigned or reserved), the attach is rejected with VM already has an IPv4. Same rule for IPv6.Open the target VM’s detail page → Network tab. If the IPv4 (or IPv6) card already shows an address, click Remove Public IP on that card before moving on to the attach step:
VM Network tab IPv4 public IP card with eth0 - Public Network, Public + Primary tags, the existing IP, MAC, Gateway, a Firewall row, and a red Remove Public IP button at the bottom — this is the button to click before attaching the reserved IP
Two important nuances:
  • Auto-assigned IP on the target → Remove returns it to the pool, permanently. You won’t get the same address back. Acceptable in nearly every move-an-IP workflow because the whole point is to use the reserved IP instead.
  • Reserved IP on the target → Remove detaches it but keeps it in your account (still billing at $3/mo). It’s now floating, ready to attach somewhere else, or release if you don’t want it. Don’t accidentally double up on reserved IPs you’ll keep paying for.
If the target VM uses only IPv6 today and you’re moving a reserved IPv4, you can skip the remove step — the IPv4 slot is empty and the attach will succeed directly.
Once the target VM’s same-type slot is empty, attach via one of three equivalent paths:
FromHow
VM detail → Network tab (target VM)Click Add Public IP → choose Reserved IP → pick this IP from the list
Networking → Public IPsFind the IP’s row, click ⋮ → Attach to VM → pick the target
Networking diagramClick the unattached IP node → Attach to VM → pick the target (when this entry point is wired in the diagram)
The IP attaches to the new VM, the new VM picks it up via cloud-init / DHCP, and outbound traffic from the IP starts originating on the new VM. Inbound traffic to the IP starts arriving on the new VM as soon as the move completes — typically within a few seconds.

​
What this does not change

  • The IP address itself — same 1.2.3.4 before and after
  • DNS records — anything pointing at the IP is still valid; you don’t need to update DNS
  • TLS certificates pinned to the IP — still valid
  • Partner whitelists by IP — still match
  • Your billing for the IP — $3/month continues uninterrupted

​
What it does change

  • The MAC address behind the IP — it’s now the new VM’s NIC
  • Active TCP connections — drop on detach. Clients reconnect; the new VM serves them
  • Outbound source IP — outbound traffic from the new VM now appears to originate from the moved IP
  • The Public IPs tab’s Assigned To column — points at the new VM
  • The diagram — the blue IP chip moves above the new VM card

​
Blue/green deploy pattern

The canonical “swap the green VM in” workflow:
  1. Build a fresh VM (the “green” candidate) — runs in parallel, no traffic
  2. Test green via its own auto-assigned IP, an internal VPC IP, or a hosts-file override
  3. When ready, detach the reserved IP from the current “blue” VM
  4. Attach it to the green VM — traffic immediately flips
  5. Keep blue running for a rollback window. If green is healthy, delete blue (or the reverse if not)
The whole switch is one detach-then-attach, taking under a minute. Rollback is just running the same two steps in reverse.

​
Failover pattern

When a primary VM is unhealthy and you keep a warm-standby:
  1. Standby VM exists in the same region, configured identically, with no public IP
  2. Detect failure (manually or via monitoring)
  3. Detach the reserved IP from the failed primary
  4. Attach to the standby
  5. Standby starts serving the same address; clients reconnect
There’s no managed failover product on Raff today; this is the do-it-yourself pattern. Automate steps 3–4 with the Change IP API if you need it scripted.
What Raff does not provide. The reserved-IP move is a control-plane action — it requires an explicit detach + attach call. Raff does not ship any of the in-guest, sub-second failover mechanisms you may know from on-prem networking:
  • No VRRP / keepalived — the IP is bound to one VM at a time at the platform level. Two VMs in the same VPC cannot share a public IP via heartbeat-driven floating-IP scripts; the second VM cannot ARP for an IP the platform has not attached to it.
  • No anycast / BGP failover — Raff does not announce customer IPs to multiple endpoints
  • No managed health-check + automatic failover — detection of “primary is down” is your responsibility (monitoring, status checks, custom watchdog)
Sub-second failover patterns from on-prem (keepalived + a VIP shared between two NICs) won’t work and trying to configure them inside two Raff VMs leads to silent breakage — only one VM ever receives traffic, and it’s the one Raff has the IP attached to.If you need automatic failover today, build it on top of the Change IP API — your monitoring detects the failure and your script calls the API to repoint the reserved IP. The detach + attach round-trip typically completes in under a minute, which is the practical floor on RTO with this approach.

Reserve a static IP

Make an IP movable by reserving it.

Manage from a VM

Per-VM Network tab walkthrough.

Release an IP

Stop billing when you don’t need the IP.
Last modified on May 8, 2026