null·hub v2026.5.29
Menu

CONTROL PLANE — LOCAL STACK MANAGEMENT  ·  beta

One console and API for your whole local agent stack

A management console for the Null stack: one binary with a built-in web dashboard and CLI that installs NullClaw agents, NullBoiler workflows, NullTickets task queues and NullWatch tracing, keeps them running with health checks and restart backoff, and updates them with rollback. The same HTTP API also fronts the agents themselves — chat, memory, cron jobs and logs all go through the hub. Everything stays on your machine — all state lives in ~/.nullhub, nothing goes to a hosted service.

Continue reading

and restart backoff, and updates them with rollback. The same HTTP API also fronts the agents themselves — chat, memory, cron jobs and logs all go through the hub. Everything stays on your machine — all state lives in ~/.nullhub, nothing goes to a hosted service.

Download Documentation GitHub 
docker run --rm -p 19800:19800 -v nullhub-data:/nullhub-data ghcr.io/nullclaw/nullhub:latest

Overview

The useful part, at a glance.

In plain words

What it is
A management console and API front door for locally run Null services, shipped as a single Zig binary of about 2.5 MB with the web dashboard compiled in. It serves at http://nullhub.localhost:19800, announces itself as nullhub.local over mDNS, and exposes the same 108 HTTP routes to the dashboard, the CLI, and anything you script. It installs, supervises, and updates NullClaw (agents), NullBoiler (workflows), NullTickets (task queues), and NullWatch (tracing), and proxies their APIs so one port fronts the whole stack.
Where it fits
The control plane — add it once you run more than one Null service and want install, health, logs and updates behind one dashboard and one API.
Why it exists — and when you need it
Why it exists
Running four separate daemons by hand means four install procedures, four configs with the same API keys pasted into each, four things to restart when they crash, and four update paths. NullHub collapses that into one supervisor with 15-second health checks and capped restart backoff, one guided install wizard with SHA256-verified downloads, one credential vault for 17 LLM providers and 18 messaging channels, and one `update-all` that rolls back to the previous binary if an update fails. Everything stays in ~/.nullhub on your machine — there is no hosted service in the loop.
When you need it
You are setting up the Null stack on a laptop, a home server, or a spare mini-PC and want components added through a wizard, watched in a browser, and updated with one command instead of four. Or you want to script the stack — agent chat, memory, cron jobs, logs, and the sub-product APIs — through a single HTTP port, discovered with `nullhub routes --json`. Remote access from other machines works over a tailnet such as Tailscale via explicit --allowed-origin allowlisting.

How it works

From zero to running.

NullHub is the installer, supervisor, and API front door for the Null stack — a family of self-hosted services for running AI agents (NullClaw), workflows (NullBoiler), task queues (NullTickets), and tracing (NullWatch). It ships as one binary with two faces: run it bare and it becomes the server with an embedded web dashboard; run it with any subcommand and it becomes an HTTP client to that server. Everything below is the same API whether you type it, click it, or script it.

  1. Start the server

    Running `nullhub` with no arguments starts the HTTP server on 127.0.0.1:19800, publishes the mDNS alias nullhub.local, and opens the dashboard in your browser at http://nullhub.localhost:19800. This one process is a prerequisite for almost everything else — every subcommand except serve, service, and report talks to it over HTTP, and prints 'nullhub is not running' if it can't connect.

    nullhub
  2. Install components through the wizard

    Each component ships a manifest that tells NullHub how to install, configure, launch, and health-check it. The terminal wizard and the browser wizard run the same manifest-driven flow; release binaries are fetched from GitHub with SHA256 verification and deleted on mismatch. Everything lands under ~/.nullhub — binaries, per-instance configs, logs, state.

    nullhub install nullclaw
  3. Run and watch

    Start everything at once, then check health and read logs from the same CLI. A supervisor thread health-checks each instance over HTTP every 15 seconds, restarts crashes with capped backoff (max 5 restarts), and re-adopts instances that were already running when the hub itself restarts.

    nullhub start-all
nullhub status
nullhub logs nullclaw/default --lines 100
  4. Update with rollback

    Check for new releases across all installed components and apply them in one command. If an updated binary fails to come up, NullHub re-resolves the previous version and restarts it — a real best-effort rollback, not just an error message.

    nullhub check-updates
nullhub update-all
  5. Make it survive reboots

    Install the hub as an OS service so the whole stack comes back after a restart — launchd on macOS, a systemd user unit on Linux. For access from other machines, add origins explicitly with --allowed-origin or NULLHUB_ALLOWED_ORIGINS; a tailnet such as Tailscale is the intended path, and origins are strictly validated.

    nullhub service install

Release binaries

One binary, ready to run.

Cross-compiled by nullbuilder for supported platforms — no language runtime or system-wide installer required.

nullhub · v2026.5.29 · 2026-05-29 release notes

Exact digests come from the repository manifest. If a future release also publishes a checksum file or detached signature, that upstream evidence appears beside the asset.

Capabilities

What NullHub does.

One API behind everything

The web dashboard and the CLI drive the same HTTP API — every subcommand except serve is a thin client to the running server. All 108 routes describe themselves at /api/meta/routes: list them with `nullhub routes --json`, call any of them with `nullhub api`. Proxies for NullBoiler, NullTickets and NullWatch make the hub a single API front door for the whole stack.

Agent gateway proxy

Talk to managed NullClaw instances through the hub: chat and streaming chat, agent-to-agent (A2A) calls, audio transcription, memory read/write and reindex, cron jobs with pause/resume/run-now, and skill installs — all per instance, all on one port.

Provider and channel vaults

Store LLM provider keys (17 providers, from Anthropic and OpenAI to Ollama and OpenRouter) and messaging channel credentials (18 channel types, from Telegram to Signal) once, hub-wide. NullHub validates them live and syncs them into instance configs.

Manifest wizard, verified installs

Add a component through a guided setup flow — in the terminal or in the browser. Each component ships a nullhub-manifest.json that tells NullHub how to install, configure, launch and health-check it. Release downloads are SHA256-checked and deleted on mismatch.

Supervision, updates, rollback

A supervisor thread health-checks instances over HTTP every 15 seconds, restarts crashes with capped backoff, and re-adopts running instances after a hub restart. `nullhub update` migrates config and restarts the previous binary if the new one fails. Mission Control in the dashboard records operational state and can save, replay and recover incident scenarios.

Agents that run the hub

A bundled skill, nullhub-admin, installs into managed NullClaw workspaces and teaches the agent to administer NullHub itself: discover the API with `nullhub routes --json`, then act with `nullhub api`.

Use it for

Where it earns its place.

The whole Null stack on a fresh machine before lunch

You have a spare mini-PC or a home server and want agents, workflows, task queues, and tracing running on it. Start the hub, walk through four install wizards (each download SHA256-verified), start everything, and register the hub as an OS service so it survives reboots. From then on the supervisor restarts crashes and `nullhub update-all` keeps all four components current — with rollback to the previous binary if an update fails to come up.

nullhub install nullclaw
nullhub start-all
nullhub service install
A Telegram agent whose keys live in exactly one place

You want a NullClaw agent (the Null stack's agent runtime) reachable from Telegram, backed by Anthropic, without pasting the same API key into three config files. Save the Anthropic key and the Telegram bot token once in the hub's vaults — via the dashboard or POST /api/providers and /api/channels — and NullHub validates both live and syncs them into the instance config. Spin up a second agent later and it draws from the same vault.

nullhub wizard nullclaw
Scripting agents, cron, and memory through one port

You want a shell script or CI job that talks to your agents without knowing where each daemon lives. Every managed instance is proxied through the hub on port 19800: chat and streaming chat, A2A calls, memory read/write and reindex, cron jobs with pause/resume/run-now, transcription, and the NullBoiler, NullTickets, and NullWatch APIs. Discover the surface with `nullhub routes --json`, then hit any of the 108 routes with `nullhub api` or plain curl.

nullhub routes --json
nullhub api POST /api/instances/nullclaw/default/agent --body '{"message":"summarize today"}'
An agent that administers its own infrastructure

NullHub bundles a skill called nullhub-admin and installs it into managed NullClaw workspaces. It teaches the agent to discover the hub's API with `nullhub routes --json` and act on it with `nullhub api` — so you can ask your agent in chat to check instance health, tail logs, or restart a component, and it operates the same routes you would.

What's inside Counted in the source, not the brochure. 73 listed

4 managed components

Each has registered defaults — port, launch command, minimum version — in the installer registry, and NullBoiler, NullTickets, and NullWatch get API pass-through routes so the hub is one front door for the whole stack.

  • NullClaw (agent runtime)
  • NullBoiler (workflows, beta)
  • NullTickets (task queues, beta)
  • NullWatch (tracing, alpha)

17 LLM providers in the credential vault

Keys are saved once, hub-wide, validated live via a running NullClaw instance, and synced into instance configs.

  • OpenRouter
  • Anthropic
  • OpenAI
  • Google
  • Mistral
  • Groq
  • DeepSeek
  • Cohere
  • Ollama
  • LM Studio
  • Claude CLI
  • Codex CLI
  • OpenAI Codex
  • Together
  • Fireworks
  • Perplexity
  • xAI

18 messaging channel types in the vault

Same vault model as providers: store the bot token or credentials in one place, validate them, and hand them to any agent instance.

  • Telegram
  • Discord
  • Slack
  • WhatsApp
  • Matrix
  • Mattermost
  • IRC
  • iMessage
  • Email
  • Lark
  • DingTalk
  • Signal
  • LINE
  • QQ
  • OneBot
  • MaixCam
  • Nostr
  • Webhook

108 self-described API routes

The full registry is machine-readable at /api/meta/routes; `nullhub routes --json` lists it and `nullhub api <METHOD> <PATH>` can call any route raw.

  • Health and status
  • Components and manifests
  • Setup wizard
  • Provider and channel vaults
  • Instance lifecycle (start, stop, restart, update)
  • Agent chat and streaming chat
  • A2A (agent-to-agent) calls
  • Audio transcription
  • Memory CRUD and reindex
  • Cron jobs (run, pause, resume)
  • Skills and MCP introspection
  • Logs and SSE log snapshots
  • NullBoiler, NullTickets, NullWatch proxies
  • Mission Control state and replays
  • Issue reporting

19 CLI subcommands

All but serve, service, and report are thin HTTP clients to the running server — the CLI and the web dashboard drive exactly the same routes.

  • serve
  • install
  • start
  • stop
  • restart
  • start-all
  • stop-all
  • status
  • logs
  • config
  • wizard
  • routes
  • check-updates
  • update
  • update-all
  • api
  • service
  • uninstall
  • report

Quickstart

Up and running.

Full walkthrough in the docs — verified with v2026.5.29.

Start the server, then add components from the same binary. Every command other than serve is an HTTP client to the running server, and the terminal wizard and the web UI run the same manifest-driven flow.

# start the server and open the dashboard
nullhub
# → http://nullhub.localhost:19800

# add components (terminal wizard)
nullhub install nullclaw
nullhub install nullwatch

# run and inspect
nullhub start-all
nullhub status

Common questions

Questions, answered.

Do I need the server running to use the CLI?

Yes. Every subcommand except serve, service, and report is an HTTP client to the server on port 19800 — `nullhub install`, `nullhub status`, even `nullhub config` all call the REST API. If the server is down you get a plain 'nullhub is not running' message. Start it first with `nullhub` (serve is the default command).

Is `nullhub logs -f` real live streaming?

Not yet. The /logs/stream endpoint returns a snapshot of the current log tail over SSE rather than a continuous stream, and `logs -f` itself tells you it is 'not stream-backed yet'. You get the recent tail on demand; true follow-mode streaming is still to come.

Does it run on Windows?

Partially. Windows x86_64 and aarch64 binaries ship with every release and the server itself runs, but `nullhub service install` returns UnsupportedPlatform there — OS service integration currently covers macOS (launchd) and Linux (systemd user units) only. On Windows you start the hub manually or with your own scheduler.

Can I reach the dashboard from another machine?

Yes, but you must opt in per origin. The hub binds to 127.0.0.1 by default and guards every /api path against DNS rebinding, so remote origins have to be allowlisted explicitly via --allowed-origin flags or the NULLHUB_ALLOWED_ORIGINS env var (validated: http/https only, no paths). The intended setup is a tailnet such as Tailscale rather than exposing the port to the internet.

How stable is this?

It is pre-1.0 and calendar-versioned (currently v2026.5.29), so config formats and CLI flags may change between releases. Of the managed components, NullBoiler and NullTickets are beta and NullWatch is alpha. The counterweight: 726 test blocks in the source tree, atomic fsync-then-rename state writes, and updates that roll back to the previous binary on failure.

What does it depend on?

Nothing external. The build manifest declares zero dependencies — the HTTP server, mDNS publishing, JSON API, and SSE are all Zig standard library plus libc, and the entire Svelte 5 dashboard is compiled into the binary at build time. A release binary is 2.4–2.9 MB with the whole web UI inside.

Works with

Pre-1.0 and calendar-versioned (v2026.x.y): config and CLI may change between releases. OS service install covers macOS (launchd) and Linux (systemd); Windows binaries ship, but `nullhub service` is not supported there yet.