Goal
Avoid deleting or trusting a node without checking the operational details that matter.Prerequisites
- A connected node
Workflow
1
Read operation progress, provider request identity, cleanup state, retryability, and next attempt.
2
Check certificate expiry and WireGuard handshake before runtime metrics.
3
Check heartbeat sequence and age, then Node Guard, runtime, Caddy, disk, memory, and CPU.
4
Refresh only the selected node when provider drift is suspected.
5
Clear every structured blocker before requesting deletion again.
Health is a chain
- Enrollment belongs to the exact tenant and node and was consumed once.
- The SPIFFE-style certificate is valid, not revoked, and outside the eight-hour rotation window.
- The WireGuard handshake is fresh and the overlay route is collision-free.
- TCP 8443 listens only on the overlay address.
- The latest monotonically sequenced heartbeat was accepted.
- Node Guard, runtime, and Caddy are ready and the node is not draining, deleting, or operation-blocked.
Deletion blockers and order
- A 409 response contains blocker type, ID or name, state, and count for direct rendering.
- Move or delete projects and stacks first, then migrate or remove databases.
- Delete snapshots before detaching and deleting their volumes.
- Request deletion again with a new idempotency key after every blocker is cleared.
- For BYOCloud, identity is revoked only after provider instance absence is confirmed; tombstones remain for 90 days.
Support evidence
Include node ID, operation ID, provider request ID, current step, error code, and last provider-sync time. Never include enrollment tickets, SSH credentials, private keys, registry grants, or decrypted provider tokens.Expected result
Node cleanup and diagnostics become deliberate, not reactive.