Skip to content

Dashboard host

The quickest way to see what this product does is to watch it proxy something, and the one upstream every deployment already has is the dashboard you are reading it in. Setup offers to switch this on, with the domain filled in.

It is managed: generated from Settings → Dashboard Host every time the configuration is applied, rather than stored as a row in Proxy Hosts. Nothing can delete it by accident, and there is no second copy to drift from the setting.

It is also built ahead of the stored hosts. Routes are ordered by host specificity, which settles every overlap except one - two hosts claiming the same exact domain - and in that tie the managed route wins. A host somebody creates for the dashboard’s domain cannot shadow the route the dashboard is reached through.

The last setup step has a Dashboard host card with a switch and the domain. It opens with DASHBOARD_DOMAIN if you set it, otherwise the hostname in BASE_URL - the address you are already reaching CPM at - and failing both, the address you opened setup at. A localhost address says nothing about the name the instance will answer to, so that leaves the switch off.

If you migrated from an earlier installation and one of its proxy hosts already serves the domain you choose, setup says so: the dashboard host wins that tie, so the old host would stop answering on it. Copy the settings from … is on by default. It brings the old host’s certificate, access list, agents, HTTPS and every other option across to the dashboard host, then:

  • disables the old host, if the dashboard’s domain was its only one, or
  • removes that domain from it, if it serves others.

The old host’s upstream is not copied - the dashboard host always points at the controller - and neither is CPM forward auth (see below). Switch the copy off to start the dashboard host clean; the old host is then left as it was, shadowed on that domain.

Settings → Dashboard Host → Proxy options has the same options as an ordinary proxy host: certificate, access list, agent assignment, redirects, rewrites and location rules, path rules, error pages, raw Caddy config, external forward auth, Authentik, Tailscale, load balancing, DNS resolution, upstream timeouts, rate limiting, geo-blocking, CrowdSec, WAF, mTLS trust and the HSTS subdomains and hostname-validation toggles. Pinning it to agents works the way it does for a stored host - nothing ticked means every agent.

A few things stay fixed, because the dashboard needs them to work at all or because they belong to a stored host:

Option Why it is not offered
Name, domains, upstreams The upstream is always the controller; the domain is the setting above
Websockets, preserved Host header Always on - the dashboard streams, and sign-in checks the host
HTTPS and HSTS Follow the Serve it over HTTPS switch
CPM forward auth Its grants are stored against a proxy host, and the dashboard is the sign-in it would redirect to
mTLS access rules Also stored against a proxy host; the mTLS trust settings themselves are available
Maintenance mode It would lock out the administrator who has to turn it off
Bot challenge Every agent and API client reaching the dashboard would be sent the challenge
Discourage search engines Always off
Compression override Follows the global switch in Settings → Network → Compression

It comes up on HTTP. Forcing HTTPS before the domain reaches you would mean a fresh install’s first act is a certificate order failing on a name nobody has pointed at it yet.

Settings → Dashboard Host offers a reachability check: it sends a request to the domain and looks for a signature only this instance can produce. Any server can return 200 and echo a nonce back; only yours can sign it.

What the check finds What happens
The request came back, signed HTTPS on - DNS, the network and Caddy’s route all work
The domain resolves but arrives elsewhere HTTPS off, with the address it currently points at
Nothing answers for the name HTTPS off - create the record and check again

Nothing is asked of a third party. The trade-off is that the request is made from the deployment itself, so it cannot see through split-horizon DNS (passes, and ACME still fails) or a network without NAT hairpinning (fails, though the outside world reaches you fine). The toggle is a default you can override in both.

Settings → Dashboard HostPick what the domain points at, then check it. Change the domain and the check waits for a save.DemoNothing you change here is saved

Dashboard host

Serves this dashboard through the Caddy this instance manages, as a host it maintains for you.
DASHBOARD_DOMAIN
The name this dashboard answers on, once it is served through Caddy.
Forces HTTPS and asks Caddy for a certificate. Only useful once requests to the domain arrive here.
You cannot lock yourself out with this
This host is generated from the settings above rather than stored in Proxy Hosts, so nothing can delete it by accident. The controller also publishes its own port, so http://<host>:3000 reaches this page whatever happens to the route.

This will end your current connection

The dashboard stays reachable on the controller's own port - http://<host>:3000 - which is where you would turn this back on.

The controller publishes its own port, so http://<host>:3000 reaches the dashboard whatever the route is doing. Turning the host off warns you first if you are reading the page through that very domain.