Migration without downtime: how one-click relocate works

Every server move starts with the same quiet dread: the apt package that was installed by hand two years ago, the cron job nobody documented, the env var living only in a shell session. A migration is rarely hard because of the data. It's hard because a running server is a pile of undocumented state, and copying files doesn't copy state. One-click relocate is our attempt to treat the whole box as the unit of truth — capture it once, bring it up somewhere else, and rewrite the one thing that actually changes: the public IP.

A server is more than its files

When people say "I'll just rsync it over," they're copying the easy 80%. The hard 20% is everything that makes the box that box: installed system packages, Docker images and their tags, the Traefik config that knows which container answers for which hostname, TLS certs and their ACME account, firewall rules, the user accounts and SSH keys, the systemd units, and the application data sitting in volumes and databases.

HostSSH builds servers through a deterministic pipeline — HostPack → Docker → Traefik — and that's exactly why relocate is tractable. The HostPack is the declared recipe for the machine: what gets installed, how it's hardened, which services run. Docker holds the workloads. Traefik holds the routing and TLS. Because the box was assembled from known parts, it can be captured as known parts. You're not reverse-engineering a snowflake; you're serializing something the agent already understands.

What "capture into one encrypted image" means

Relocate starts by taking the server and producing a single encrypted image — the same artifact concept behind back up · clone · relocate. Conceptually it contains three layers:

• The recipe — the HostPack manifest plus any drift the agent has reconciled, so the target can be rebuilt the same way rather than block-copied.
• The workloads — Docker images (pinned by digest, not floating :latest), compose definitions, and the Traefik routing/TLS state.
• The data — application volumes, database dumps, and uploads, captured consistently rather than mid-write.

The point of one image is that there's a single thing to move and a single thing to verify. It's encrypted before it ever leaves the source box, and it lands in your storage — R2 or S3 you control — under whichever custody model you've chosen: agent-local, zero-knowledge, or escrow. Your data, your bucket, your exit. Relocate doesn't route your server's guts through someone else's vault as a toll booth.

Getting a consistent picture

You can't image a live database by copying its files out from under it. So capture is ordered: the agent quiesces or snapshots stateful services, takes consistent dumps where a snapshot isn't enough, then packages volumes. The aim is an image that represents a coherent moment, not a smear across several seconds of writes. For most stacks this means a brief, controlled pause on the data layer — measured in seconds — not the long blackout people associate with migrations.

The cutover, not the outage

Here's the distinction the title is making. A bad migration is an outage: you turn the old box off, and the service is dark until the new one is fully up, DNS has propagated, and you've finished firefighting whatever didn't come back. A relocate is a cutover: the new box is built and verified while the old one keeps serving traffic, and you flip the pointer only once the replacement is proven.

The sequence looks like this:

1. Capture the source into the encrypted image, source still live.
2. Provision a fresh VPS — any provider, that's the whole point of provider-agnostic.
3. Hydrate the target from the image: replay the HostPack recipe, pull the pinned Docker images, restore volumes and databases, restore Traefik routing and TLS state.
4. Bring services up on the new box and health-check them — on its own IP, before anyone is sent there.
5. Rewrite the public IP so the world starts talking to the new server.
6. Keep the old box as a warm fallback until you're satisfied, then retire it.

Steps 1–4 carry no user-visible risk because nobody is pointed at the new machine yet. The only sharp moment is step 5, and that's the part we want to make boring.

Rewriting the public IP

A server's identity to the outside world is a name resolving to an address. Relocate's job at cutover is to make that name resolve to the new address cleanly — that's the "public IP rewritten" in the description. In practice that's a DNS change: the A/AAAA records that pointed at the old box now point at the new one.

Two realities make this manageable rather than scary:

• TTL is a dial, not a fact. Before a planned move, you lower the record's TTL so caches expire fast. When you cut, resolvers pick up the new address in minutes, not hours. After things settle, you raise it back.
• Both boxes serve during the overlap. Because the old server stays up, clients still hitting the cached old IP get served correctly until their cache expires. There's no window where the name points at nothing. Traffic drains from old to new instead of being yanked.

That's why this reads as a controlled cutover. The new server is real and healthy before the switch; the old server is a safety net during it; the DNS change is the deliberate, reversible act in the middle. If something looks wrong, you point the name back — the old box is still there and still correct.

Why provider-agnostic matters here

The reason relocate exists at all is that "your exit" should be a real option, not a slogan. If your images live in your bucket and the agent can stand a server up from those images on any VPS, then leaving a host is a Tuesday afternoon, not a quarter-long project. The lock-in that keeps people on a bad provider is usually operational, not contractual — the fear of the move itself. Take that fear out and the relationship with your host becomes voluntary again.

This is also why it's the same machinery as backup and clone. A backup is a relocate you hope you never replay. A clone is a relocate to a new name instead of the same one. Relocate is a clone where you also move the identity over. One capture format, three uses — and none of them ask you to trust a storage layer you don't own.

A calm way to think about it

A migration feels dangerous because it's usually improvised: copy what you remember, hope you didn't forget anything, flip everything at once, and find out live. Relocate is the opposite posture. Capture the whole box as one verifiable thing. Rebuild and prove the replacement before it takes any traffic. Move the name last, with a short TTL and the old box still standing behind you.

Nothing here is magic — it's DNS, snapshots, pinned images, and a recipe you can replay. The value isn't a trick; it's the ordering. Do the steps in the right sequence, keep the old server warm, and a move stops being the day you brace for. It becomes a thing you do on purpose, on your terms, into storage you own.