One-click relocate: moving a live Coolify box to a new IP
Relocating a server that's actively serving traffic is a choreography problem, not a copy problem. Here's how HostSSH moves a live Coolify box to a new IP with a clean cutover and a real rollback.
Moving a server that's powered off is easy. Moving one that's live — handling requests, taking writes, holding active sessions — is where relocation gets interesting. The data has to arrive complete, the new IP has to propagate, and the switch has to happen at a moment where nothing in flight is lost.
HostSSH treats a live relocation as a sequenced cutover with a rehearsed rollback. The goal is not heroics; it's a boring, repeatable move you'd happily do on a Wednesday afternoon.
The hard part isn't the copy
Copying a Coolify box's contents — the brain, databases, volumes, secrets — is well-trodden ground. The genuinely hard parts are timing and addressing.
Capturing a moving target
A live database changes while you back it up. A naïve dump taken over several minutes can be internally inconsistent — half the rows from before a transaction, half from after. HostSSH captures a point-in-time consistent image so the restored database reflects one coherent moment, not a smear across the backup window.
The IP problem
The reason relocation feels scary is that a server's IP is referenced in more places than anyone remembers: service configs, connection strings, webhook registrations, reverse-proxy rules, and TLS material. The trick that makes HostSSH relocations clean is separating two kinds of reference:
- Internal references — services on the box talking to each other.
- Public references — the outside world reaching the box.
When internal services address each other over a WireGuard overlay (10.10.0.x), those addresses are IP-stable. They don't move when the public IP moves. So a relocation only has to rewrite the public references — a small, enumerable set — and can leave the entire internal mesh untouched.
The cutover, step by step
A live move runs as a staged sequence. Each stage is reversible until the very last one.
1. Stand up the target in parallel
HostSSH provisions the fresh VPS and restores the latest consistent image onto it while the old box keeps serving. Nothing is switched yet — you now have two boxes, one live and one warm.
# Relocate a live Coolify box to a fresh target, rewriting the public IP
hostssh migrate --live --new-ip --target provision:hetzner/cx32
2. Sync the delta
Between the image capture and the cutover, the live box took new writes. HostSSH replays that delta onto the target so the two systems converge, shrinking the final switch window to seconds rather than minutes.
3. Rewrite public references — and only those
Public IP references are rewritten deterministically on the target: DNS records staged, webhooks re-pointed, proxy rules updated. Internal 10.10.0.x addresses are left alone because they never changed.
4. Reissue TLS and verify
Certificates are reissued for the new box and HostSSH runs the same checks a restore-drill would: domains return 200, row counts match, TLS chains validate. The target proves itself before it takes traffic.
5. Flip DNS
With the target verified, DNS cuts over. New connections land on the new box; the old box drains its remaining in-flight requests and goes quiet.
Rollback is a first-class path
The reason a live cutover is safe is that, until DNS flips, the old box is untouched and authoritative. If verification on the target fails, you simply don't flip — and you're exactly where you started, with zero customer impact.
Even after the flip, the old box is kept intact (not decommissioned) until you confirm the new one is healthy under real traffic. Reverting is flipping DNS back, not rebuilding from scratch.
Why this matters for the renewal treadmill
The recurring real-world case is mundane: a VPS plan is up for renewal, a provider is changing terms, or you simply want a cheaper box. Historically each of those meant a tense, manual, IP-rewriting migration that people deferred for months.
When relocation is a verified one-click cutover with a real rollback, the calculus flips. Moving a live box stops being a project and becomes a button — and your infrastructure stops being anchored to wherever it happened to land first.