Re-adopt workloads
When a node is reconnected to a panel that has lost its records — a database reset, a restore from an older backup, or a move to a fresh panel — discover what's still running on the box and bring those instances and sites back under management.
The panel is a control plane, not a runtime. The instances on a node, the sites inside them, and the node's web server all run as their own services on the box — they do not depend on the panel to keep running. So if the panel itself goes away for a while, nothing on your nodes stops.
What the panel does hold is the record of what it manages. Almost always that record is safe. But in a few situations the panel can come back not knowing about workloads that are still very much alive on a node — and Re-adopt is how you reconcile the two.
When you need this (and when you don't)
Most restarts need nothing — you just keep going
If the panel server reboots, the panel container restarts, or you redeploy it — and the panel database is intact — there is nothing to do. The agents reconnect on their own within seconds and the panel already knows every node, instance, and site. Re-adopt is not part of that path.
Re-adopt is for the narrow case where the panel's database no longer matches reality:
| Situation | The nodes themselves | What the panel knows | Action |
|---|---|---|---|
| Panel reboot / redeploy, database intact | Kept running | Everything | Nothing — agents reconnect, you carry on |
| Database reset, or restored from an older backup | Kept running | Missing the lost instances/sites | Re-adopt |
| Node moved to a fresh panel | Kept running | Nothing about this node yet | Re-enroll, then Re-adopt |
In each "Re-adopt" row the workloads never stopped — the box kept serving traffic the whole time. The only thing missing is the panel's memory of them, which is what this brings back.
Discover, then adopt
Re-adopt is a tab on the node workspace, and it works in two deliberate steps.
Discover. A read-only pass reads what is physically on the box — every running instance, and the sites deployed inside them — and compares it to what the panel knows. It changes nothing; it only looks.
Review. Each workload is sorted into one of three states so you know exactly what you're looking at before anything is written:
| State | Meaning |
|---|---|
| Adoptable | The panel isn't managing this — it's a candidate to bring back. |
| Already managed | The panel already knows about it. Nothing to do. |
| On another node | The name exists in the panel but bound to a different node — flagged, never silently overwritten. |
Adopt selected. Pick the adoptable workloads and adopt them. The panel re-creates its records for those instances and sites and claims the addresses they already hold, so the workload is managed again — and a future new instance can never be handed an address that's already in use.
Adopting is explicit, and audited
Discovery is read-only and safe to run any time. Adopting writes — it re-creates records — so it only ever acts on workloads you select, refuses anything not cleanly adoptable, and writes an audit entry. It is never automatic.
What gets adopted
Re-adopt brings back instances and the sites inside them — the workloads that keep running independently of the panel. It deliberately does not try to re-derive domains, routes, or certificates; those are reconstructed the normal way once the instances and sites are back under management.
It reads the box using the same read-only channel the panel always uses — there is no extra access to grant and nothing new installed on the node to make this work.
Belt and braces: keep the database safe
Re-adopt is a recovery tool, not a backup strategy. The cleanest recovery from a panel failure is always to bring the panel's database back — then there's nothing to re-adopt at all. See disaster recovery for the recovery kit, restoring the panel, and claiming agents that call home; use Re-adopt for the cases where the database is genuinely gone but the nodes kept running.
IPv4 edge proxy
Reach an IPv6-only origin from the IPv4 internet with your own self-hosted edge — a box that owns a public IPv4, terminates the TLS, and reverse-proxies to the v6 origin over IPv6. Your own equivalent of a Cloudflare proxy, no third party in the request path.
Instances
Create an isolated VM or container on one of your nodes — the home your sites live in — and manage it from the instance workspace.