Keep the node running
The node updates itself and checks its own health. Your admin keeps Ubuntu and its kernel current, and can pick the moment Incus and cloudflared move.
Check it with doctor
sudo detachbox-node-host doctor
doctor checks the node end to end and changes nothing. Each check has 20 seconds and prints its line as it finishes:
- that detachbox still takes the node's token, node-host and its version, and the server's last answer;
- the tunnel's connections to Cloudflare and the way back in through it, to node-host and to the terminal gateway;
- outbound HTTPS and TLS to api.detachbox.com;
- Incus and its hold, and whether newer builds of Incus or cloudflared wait;
- the ZFS module loaded now and the one the next kernel will load, deduplication, the pool's health and how full it is;
- your private networks against the terminals' firewall;
- the base image and when its last build started.
Each ✗ comes with its fix. A part that hangs, such as Incus or ZFS, reads … within 20 s on its ✗ line, and the later checks of that part read not checked: … did not answer above instead of waiting. A … marks what does not fail the check: what cannot be known yet, such as the server's first answer in the minutes after node-host restarts, or an update that waits. The updates line reads ✓ Updates Incus <version>, cloudflared <version>: the newest builds apt knows of, or … Updates not yet: …; <build> waits: sudo detachbox-node-host upgrade installs it (node-host does on a day no terminal runs).
sudo detachbox-node-host doctor --report sends the result to detachbox, so your detachbox contact sees what you see.
What updates itself
- node-host updates itself within minutes of each detachbox release. It installs only what detachbox's release key signed, and puts the previous release back if the new one does not come up.
- The base image of your terminals is rebuilt every 6 hours with Ubuntu's updates and the latest Claude Code, Codex and OpenCode. It goes live only after a smoke test; a build that fails leaves the last good one in place. Running terminals keep the image they started on, and a new or restarted terminal gets the current one.
Incus and cloudflared
Both stay on hold in apt, and the hold is never lifted: your own apt upgrade leaves them alone. A restart of cloudflared cuts every connection through the node's tunnel once (terminal tabs, previews, uploads), and a restart of Incus cuts the connections of open terminal tabs. Either way they reconnect by themselves within seconds, and the terminals keep running, with their tmux sessions, agents and every process in them. A terminal started or stopped in those seconds fails once and goes through when asked again, and a base image build running then fails and is built again within 6 hours. So they move only at a moment you pick, or on a day no terminal runs.
sudo detachbox-node-host upgrade --check # asks the two vendors' repositories; nothing changes
sudo detachbox-node-host upgrade # says what is newer and what happens to the terminals, asks [y/N]
sudo detachbox-node-host upgrade --confirm # upgrades without the question
upgrade lists what is newer, how many terminals run and what the restarts do to them, then asks. Run without a terminal to ask on, it refuses and names --confirm. Once the packages start installing, the upgrade runs to its end whatever happens to your session; sudo tail -f /var/lib/detachbox-node/install/install.log follows it. It ends with doctor and ✓ Upgraded: …, after about a minute on our test node.
node-host tries the same upgrade once a day, the first time 15 minutes after it starts, and only when nothing but the edge runs: no terminal, no base image build. With a terminal running it writes in its log that the upgrade waits, and tries a day later. A node where some terminal always runs never upgrades by itself: doctor keeps showing the update until you run upgrade.
Kernel updates
Ubuntu and its kernel are yours to update. Install each new kernel with its linux-headers, and DKMS builds the node's ZFS 2.4.4 for it by itself; on our test node that took about 4 minutes. doctor then shows a ZFS for <kernel> line for the running kernel and one for the newest installed kernel, the one the next boot loads. Both must read ✓ before you reboot; after a reboot into the new kernel, the node comes back by itself.
If a kernel ever boots without the node's ZFS, node-host turns deduplication off before a terminal writes a byte, and says so in doctor and to detachbox. It turns deduplication back on at the first start on a fixed module.
Reboots
A reboot stops running processes and tmux sessions. node-host and the tunnel start with the server, and your terminals come back by themselves with their files, apt packages and Docker images in place; Docker containers with a restart: policy start again. Each agent comes back on its last conversation by itself and waits for its engineer. One that is not back starts there again with Restart terminal on this conversation.
When the node goes offline
A minute after the node stops answering, the dashboard reads Node offline since 14:02 in the top bar and on the Compute page, and an open terminal says it reconnects by itself once the node is back. Files stay on the server. After 10 minutes of silence the account that owns the node gets one email, which names the time and points at sudo detachbox-node-host doctor, and one more when the node answers again. A reboot or an update of node-host never takes that long.
More cores or memory
Add them to the server, then tell your detachbox contact. node-host reports the server's cores, memory and pool to detachbox, and your contact applies the new size; nothing changes by itself. The running Compute takes the new size without a restart, and Activity records it.
When detachbox takes the node off
If your node's enrollment is cancelled, doctor says so in one line, "✗ Account taken off", with what to do: sudo detachbox-node-host uninstall --confirm, or, if you did not expect it, send that line to your detachbox contact. Until then node-host stays quiet, with the tunnel and the edge as they are, and asks detachbox every 15 minutes, so a node refused by mistake is back within that time. A refusal that does not come in the detachbox server's words, such as a proxy that wants its own login, does not mean the node was taken off: doctor says so on the Account line. Let the node through that proxy without a login, or send the line to your detachbox contact.