Does an IP Address Change? Yes, and Here Is What Depends On It

Yes — most IP addresses change, and the more useful question is which of yours does, on what trigger, and what in your setup silently depends on it staying the same.

The distinction people are usually reaching for is static versus dynamic, but that framing hides the part that actually matters operationally: an address can be stable for years and still change on a trigger you did not anticipate, and the things that break when it does are rarely the things you were watching. Here is which addresses change and what to do about the dependencies.

Table of contents

• Which addresses change, and on what trigger
• What breaks when an address changes
• Building so it does not matter
• Static addresses: when you actually need one
• How this fits the rest of the stack
• FAQ

Which addresses change, and on what trigger

You have several addresses and they behave differently. Confusing them is the source of most of the confusion around this question.

• Your home or office public address. Assigned by your ISP, usually dynamic. Changes on router reboot, on lease expiry, during maintenance, or when the ISP renumbers. Some ISPs keep the same address for months; others rotate frequently. Neither is a guarantee.
• Your device’s local address. Assigned by DHCP from your router, typically in a private range. Changes when the lease expires, when you reconnect, or when the router restarts. Never visible from the internet.
• A mobile device’s address. Changes constantly — between cell towers, between networks, and often within a session. Frequently shared with many other subscribers through carrier-grade NAT.
• A cloud server’s public address. Depends on how it was allocated. An ephemeral address is released when the instance stops and a different one assigned on start. A reserved or elastic address persists until you release it.
• A cloud server’s private address. Usually stable for the life of the instance, and not routable from outside.

The cloud case catches people most often: an instance that has had the same address for six months gets stopped and started for a resize, and comes back with a different one. It was never static; it just had not been stopped.

The corresponding fix is to reserve the address explicitly, and to understand that a reserved address usually costs money while not attached to anything — which is the provider’s way of discouraging hoarding, and a small recurring charge people forget about.

What breaks when an address changes

The failures are predictable and they share a characteristic: they happen quietly, at a moment unrelated to any change you made.

• Firewall allowlists. Your address is permitted to reach a database, an admin panel, a partner’s API. It changes, and access disappears with an error that reads like the service is down.
• DNS A records. Pointing a domain at an address that has moved means the domain now points at whatever took over that address, which is worse than pointing at nothing.
• Third-party allowlists. A payment provider, a bank, or a partner that restricts API access by source address. Often the slowest to fix, because it requires someone else to make a change.
• Mail reputation. A new sending address starts with no reputation. If you send mail from an address that changed, deliverability degrades until the new one is established.
• Licences bound to an address. Some software licensing keys to a host address and stops working when it moves.
• Anything with a hardcoded address in configuration. Which, in any system old enough, there is.

The pattern worth internalising: none of these fail at the moment of change in a way that points at the change. They fail later, when something next tries to use the path, and the error describes the symptom rather than the cause. That gap is what makes address changes disproportionately expensive to debug.

Building so it does not matter

The general principle is to depend on names rather than numbers, and on identity rather than location. Concretely:

1. Use DNS everywhere. Services reference each other by hostname, never by address. Then a change is one DNS update rather than a search through every configuration file.
2. Keep TTLs sane. Low enough that a change propagates quickly, high enough that you are not paying resolution latency constantly. Five minutes for records you might change, longer for ones you will not.
3. Authenticate rather than allowlist. An IP allowlist is a weak control that breaks on legitimate change. Mutual TLS, signed requests or a VPN identify the caller regardless of where it connects from, and are both stronger and more stable.
4. Reserve addresses that others depend on. If a third party has your address on their allowlist, that address must be one you control explicitly, not one attached to an instance that might get stopped.
5. Use dynamic DNS for genuinely dynamic locations. A home server behind a residential connection should run a client that updates a DNS record when the address changes.
6. Never hardcode. Addresses in configuration go in environment variables or a service registry, so a change is one edit.

The third point deserves emphasis. Teams often reach for an IP allowlist because it is quick, and it becomes a permanent operational tax: every new office, every remote worker, every cloud migration produces a ticket. Authentication scales; location does not.

Static addresses: when you actually need one

A static address is worth arranging for a small set of specific reasons, and worth skipping otherwise.

You need one when: you send email directly rather than through a provider, since reputation attaches to the address; a third party allowlists you and will not accept a hostname; you run a service others connect to inbound; or a compliance requirement names a fixed address.

You do not need one when: your service is behind a load balancer or proxy, which is what the world connects to; you use DNS properly and can update a record; you send mail through a provider whose addresses carry the reputation; or you only make outbound connections.

For a residential connection, static addresses are usually a business-tier upsell. Dynamic DNS achieves most of the practical benefit for nothing, with the caveat that it depends on the update client running and on TTL-length propagation — so it is not suitable for anything where a few minutes of staleness is unacceptable.

And a note on IPv6, since it changes the framing: addresses are abundant enough that every device can have a globally routable one. Privacy extensions rotate the interface portion regularly by design, so IPv6 addresses on client machines change more often than IPv4 ones, deliberately. Any allowlist built on IPv6 client addresses will not work the way you expect.

How this fits the rest of the stack

Most of the fragility above comes from services being reached by address rather than by name, which is a deployment shape rather than a networking problem. The RunxBuild hosting calculator covers what the managed shape costs across the service, database, storage and bandwidth. On RunxBuild services are reached by hostname with the custom domain and certificate handled at deploy, and managed databases sit on private networking — so an instance moving is not something the rest of the stack has to notice.

Useful related references:

• hostname -i: Print the Host’s IP Address (and the Caveats)
• Check IP Address on Ubuntu: The 6 Commands That Always Work
• How to Check Your IP Address in Ubuntu (And Which One You Actually Want)
• Services on RunxBuild

FAQ

Does my IP address change?

Most do. A home or office public address is usually dynamic and changes on router reboot, lease expiry or ISP maintenance. Mobile addresses change constantly. A cloud server’s public address depends on allocation — an ephemeral one changes when the instance is stopped and started, while a reserved one persists until released.

Why did my cloud server’s IP change after a restart?

Because it was an ephemeral address rather than a reserved one. Ephemeral addresses are released when an instance stops and a different one is assigned on start. It appeared static only because the instance had not been stopped. Reserve the address explicitly if anything depends on it.

What breaks when an IP address changes?

Firewall allowlists, DNS A records pointing at the old address, third-party allowlists at partners and payment providers, mail sending reputation, address-bound licences, and anything with a hardcoded address in configuration. These all fail quietly and later, which is what makes them expensive to diagnose.

Do I need a static IP address?

Only if you send email directly, a third party allowlists you and will not accept a hostname, you run an inbound service others connect to, or a compliance rule names a fixed address. If your service sits behind a load balancer or you use DNS properly, you generally do not.

Do IPv6 addresses change?

Yes, and client addresses change more often than IPv4 ones by design. Privacy extensions rotate the interface portion of the address regularly to prevent tracking. Any allowlist built on IPv6 client addresses will behave differently from what you expect.