null·hub v2026.5.29

Operate

Updates and rollback

verified · v2026.5.29 .md edit on github ↗

NullHub updates the components it manages: it checks upstream for new releases, downloads them, migrates config, and rolls back when an update fails. You never hand-edit a component's install to move it forward.

Check what's stale#

nullhub check-updates

This compares each installed instance against the component's latest release. The dashboard shows the same information on the status cards.

Update#

# one instance
nullhub update nullclaw/main

# everything at once
nullhub update-all

An update is three steps, in order:

  1. Download — the new version's platform binary is fetched into ~/.nullhub/.
  2. Migrate — the instance's config is carried over to the new version.
  3. Verify or roll back — if the update fails, NullHub restores the previous version rather than leaving the instance broken.

The web UI exposes the same flow as one-click updates per instance.

Version numbers#

The whole family uses calendar versioning — v2026.5.29 is a date, not a maturity signal. Two consequences worth internalizing:

  • There is no semver contract. A new release may change config shape or CLI flags; the migration step exists precisely because of this.
  • "Latest" moves often. check-updates is cheap — run it routinely, or script it via nullhub api.

Updating NullHub itself#

nullhub update handles managed components, not the hub binary. To update NullHub, replace the binary the same way you installed it — pull the newer Docker tag, download the newer release asset, or rebuild from source. State under ~/.nullhub/ is separate from the binary and survives the swap.

If you registered NullHub as an OS service, restart it after the swap:

nullhub service status

When something goes wrong#

  • nullhub status <c>/<n> shows single-instance detail, including health.
  • nullhub logs <c>/<n> -f follows the instance's logs live.
  • The supervisor restarts crashed instances with backoff, so a bad update that starts-then-dies is visible as a crash loop in the logs rather than a silent absence.

A failed update that triggered rollback leaves the previous version running. Fix the cause (often a config value the new version rejects — nullhub config <c>/<n> --edit), then update again.