Quick answer: rebooting never changes your IP address on any line we sell. Stopping and then starting an Amazon EC2 instance does change its public IP. If your EC2 address changed after a stop/start cycle, that is expected platform behavior, not a fault.
What persists
On our VPS lines the IPv4 address assigned at provisioning stays with the server through reboots, and on most lines through OS reinstalls as well, because the underlying instance keeps existing and the address belongs to it. Day to day you can treat your address as static: firewall rules, DNS records and third-party whitelists built on it will keep working.
The EC2 exception
Amazon EC2 handles public addresses differently from every other line we sell. When an EC2 instance is stopped, its public IP is released back to the pool; when the instance is started again, it receives a new one. Note the distinction:
- Reboot: the operating system restarts, the instance never stops, the IP is kept.
- Stop, then start: the instance is powered off at the platform level and the public IP changes on the way back up.
If your workload depends on a stable address, on DNS entries, mail configuration, or a partner's firewall whitelist, avoid stop/start cycles on EC2 and use reboots instead. If you genuinely need to stop the instance or need a permanently stable address on that line, open a support ticket and we will go through the address options available for your server.
Planning DNS around any IP change
If an address change is ever planned (for example you are moving to a new server), lower the TTL on the relevant DNS records to something like 300 seconds a day in advance. Old cached answers then age out quickly and the cutover is painless. Raise the TTL again once you are settled.
Additional and reserved addresses
Several of our lines offer extra addresses as paid options in the catalog:
- Vultr lines (Linux, Windows, GPU): additional IPv4 or IPv6 addresses from $15 per month, and the Windows and GPU lines also list a basic IPv6 option from $2.
- Amazon EC2: additional IPv4 addresses from $15 per month.
- DigitalOcean: reserved IPs from $10 per month.
- Hetzner Cloud: floating IPs from $13 per month.
- Our custom Linux line: extra IPv4 addresses from $10 per month.
These are arranged for your service after ordering: open a support ticket telling us which server needs the address and what for, and we will set it up with the provider. Availability can vary by region, so treat the catalog entry as the starting point of the conversation rather than an instant self-service toggle.
What floating and reserved IPs are for
A floating or reserved IP is an address that exists independently of any single server and is pointed at one. The classic use is failover: if the server behind the address dies, the address is remapped to a standby and clients never notice. It is also a clean way to keep a stable public identity while you rebuild or replace the machine behind it.
What we cannot do
We cannot hand-pick a specific address for you, guarantee an address's history or reputation, or promise that a replacement address lands in a particular range. Providers allocate from their own pools. If you have a reputation problem with an address, contact us via a support ticket and we will look at what can be done for your specific line, but be aware the mechanics differ per provider.
Checking your address from the server
ip -4 addr show
curl -4 ifconfig.meThe first shows what the OS has configured; the second shows the public address the outside world sees. On most lines they match. On EC2 the OS typically sees a private address while the public one is mapped at the platform edge, which is normal and nothing to fix.
Public versus private addresses on EC2
One nuance worth knowing on the EC2 line: while the public IP changes across a stop/start, the instance's private address stays put. If you run several EC2 servers that talk to each other, wire them together on their private addresses and only the outside world is affected by a public IP change. Your internal configuration keeps working untouched.
Binding services sensibly
Configuration that hardcodes a public IP breaks twice: once when the address changes, and again when you migrate. Where possible, bind services to all interfaces or to a hostname rather than a literal address:
listen 0.0.0.0:443; # instead of listen 203.0.113.10:443;Then point DNS at the server and let every other system reference the name. When an address does change, you update one DNS record instead of hunting through config files.
