Support#

No plan includes support, and no support channel has been published yet. What follows is what a subscription does and does not include, what a lapsed router can still do, and the one command that collects everything a diagnosis starts from before anyone writes in.

What a plan includes#

No plan includes support, and support is not sold separately. Homelab, Lab and Business buy the same software with different router counts and use rights — the product site has the figures. None carries a response time, a ticket count or an agreement to answer. What every subscriber has is the documentation and, once it is published, a mailbox read on a best-effort basis with nothing promised about when.

A lapsed subscription is not a brick. A router whose key has expired signs you in, shows every page, counter, log and audit entry, and refuses only to change configuration.

A security vulnerability does not go to support. Use the disclosure route instead, and do not open an ordinary support thread describing the flaw — Reporting a vulnerability.

Before you write in#

Take a support bundle. It is one file, and it carries what anyone diagnosing a fault will ask for, so the collecting is not yours to do.

Inside is one gzipped archive of up to nineteen entries: what this box says it is, the running configuration as set commands, the service subtree, interfaces, routes, uptime, memory, storage, CPU and the commit history, the agent's settings and licence state, and the most recent 500 audit entries. Two of the nineteen never appear together — the agent's own log exists only in a bundle taken from the running daemon, and the journal only in one taken at the console, where the wrapper pipes it in — so no bundle carries all nineteen. README.txt says what each entry is and manifest.json names every source that failed, was empty, was truncated at its cap or was left out on purpose, with the reason. A bundle from a router whose API is unreachable is still a bundle: every failed read becomes a line in the manifest saying so.

If you can reach the API but not the console#

The same material, one call at a time — useful for a quick look, or when nobody is at the box. Everything except /health needs authentication: use an API token with the viewer role (Admin → API tokens) in an Authorization: Bearer wh_… header rather than a copied session cookie. A cookie fails on any request that changes something, because every mutation also has to echo the X-Wheelhouse-CSRF header the browser sends and a token does not.

R=https://<router>:8443
T=wh_...                                    # an API token with the viewer role

wheelhouse-agent --version                  # on the router: the exact build
curl -sk  $R/health                         # liveness and the agent version, no auth
curl -sk -H "Authorization: Bearer $T" "$R/api/audit?limit=300"   # who changed what, when
curl -sk -H "Authorization: Bearer $T" "$R/api/history"           # the router's commit revisions
curl -sk -H "Authorization: Bearer $T" "$R/api/fleet"             # multi-router status, or enabled:false with a note

GET /health answers {"status":"ok","version":"…"} — the agent's own build, and nothing else about the box. No host name, no licence state, no router reachability; those need a session.

GET /api/audit returns the most recent 300 entries unless ?limit= says otherwise.

If nothing answers at all#

wheelhouse-rescue diagnose, at the console or from the install medium's rescue boot entry, says in one screen why the agent will not start: whether the binary runs, what systemd last said about the unit, whether first boot finished, whether the data directory has room and its secret files are present and the right mode, whether the state file parses and holds an administrator, whether anything still holds the directory's lock, and whether the key the agent holds is the key the router has — Locked out.

Getting the version#

The log#

On a Wheelhouse appliance the agent's log is the journal. A bundle taken with wheelhouse-support already carries the last 5,000 lines of it, which is the reason that wrapper exists — the agent logs to stderr and never shells out, so its record of anything before the current process is in the journal and nowhere the agent itself can reach. To read it yourself:

sudo journalctl -u wheelhouse-agent --since '1 hour ago'

/opt/wheelhouse/agent.log exists only on a developer install without systemd, not on the shipped image.

What to tell us#

• Versions — both of them, from the table above.
• What you did and what happened. For a configuration problem, the exact set or delete path the editor showed you, and the router's own error text if it refused.
• How to reproduce it. wheelhouse-agent --demo starts without router credentials, so anything that answers before the router is consulted — sign-in, roles, sessions, the licence gate, the shape of an API response — can be reproduced with no router at all. It is not a mock: there is no fixture data, and every router read fails, so a panel that reads the configuration shows its error state. A minimal desired-state file or fleet.json is enough for the reconcile and fleet paths.
• The audit entries and the journal lines around the timestamp.

Known gaps that generate tickets#

Listed so nobody spends an afternoon proving one:

• A failed upgrade is recoverable, but not from the browser. The documented recovery order is the previous image; beyond that, wheelhouse-rescue at the console — or the install medium's Rescue an installed Wheelhouse system boot entry — says why the agent will not start, resets a password, clears a second factor, re-runs first boot and restores a configuration. A factory reset is on the System page and at the console (Factory reset).
• A lost second factor is no longer a hand-edited state file, but the way back has to have been arranged in advance or performed by somebody else: one of the ten recovery codes issued at enrolment, an administrator clearing the factor from Admin → Users, or wheelhouse-rescue totp --user NAME at the console. The codes are shown exactly once. An administrator cannot clear their own factor.
• App images are pinned by digest. An install stages name:tag@sha256:…, so the same catalogue installs the same bytes today and next month. The other side of that: a pinned image does not pick up an upstream security fix until the catalogue is re-pinned and shipped.
• A capture outlives the page for about twenty seconds. Diagnostics → Capture starts a real tcpdump on the router. With Stop it when nobody is watching — on by default — it ends 20-25 seconds after the last time a page asked how it was doing, and at its limits regardless: at most 300 seconds. Unticked, only the limits end it. The pcap is deleted 15 minutes after the capture ends.

The longer list is on What is finished, and what is not.

Beta#

The beta is closed and invite-only while the image is exercised on more than one kind of hardware. Seats go to operators willing to install on real hardware and report what breaks. The terms, the seat count and how to apply have not been decided, so there is nothing to apply to yet.

Reporting an error in this documentation#

Same route, and the same gap: there is no address published yet. When there is, a documentation report is most useful as the page's URL, the sentence that is wrong, and what the router does instead — About this documentation.

See also#

• What is finished, and what is not — before you open a ticket for something that was never built.
• Reporting a vulnerability — the other route, for security.
• The Wheelhouse licence — what is and is not promised.
• API tokens — issuing the viewer token the commands above use.
• If it goes wrong — the first things to check before writing in.
• Locked out — the recovery order when you cannot sign in.