Dashboard

The Caplets Dashboard is the browser administration surface for a Current Host. Use it when you need to approve remote clients, inspect installed Caplets, review catalog updates, manage Vault state, or check runtime and activity from the Current Host itself.

Who it is for

The dashboard is for an Operator Client, not an ordinary access session.

• Access Client -> runtime access such as Remote Attach, MCP, and Project Binding
• Operator Client -> host administration such as dashboard access, remote-client approval, Caplet and catalog administration, Vault administration, and runtime control

If you only need an agent to use Caplets remotely, use Remote Attach. If you need to administer the host, use the dashboard.

Open the dashboard

Open /dashboard on the Current Host Origin:

http://127.0.0.1:5387/dashboard
https://caplets.example.com/dashboard

GET / redirects to /dashboard. Browser pages and hashed assets stay beneath /dashboard and /dashboard/_astro/*; browser-private login, session, logout, and reveal ceremonies stay beneath /dashboard/api/*. Ordinary administration requests use /api/v2/admin/*.

The dashboard targets current evergreen browsers with JavaScript enabled. It is served by the Caplets HTTP runtime; the stdio-only caplets attach Adapter has no dashboard. Dashboard paths are fixed at the origin root. A reverse proxy must expose the canonical namespaces directly; prefix-only hosting is unsupported.

Approval flow

An unauthenticated browser sees an operator approval screen first. Selecting Authorize this browser creates a pending login and shows the host-side approval command. On the host, approve that operator code from the same user configuration that selects Authoritative Host State:

caplets remote host approve <code> --yes

The deprecated --state-path option no longer selects credential state. Remote clients, pending logins, and dashboard sessions are stored in the host’s configured SQL backend.

After approval, the browser receives an operator dashboard session and can administer the Current Host.

Dashboard login issues a host-only, HttpOnly, SameSite=Lax cookie at Path=/. A request with any Authorization header selects bearer authentication instead of the cookie; an invalid or underprivileged bearer never falls back to the dashboard session. Unsafe session-authenticated Admin and private ceremony requests require the current X-Caplets-CSRF.

Session restore migrates an existing cookie scoped to Path=/dashboard: it validates the same durable session, reissues the same credential at Path=/, and expires the old path without changing session identity, CSRF value, or absolute expiry. Logout and acting-client revocation or demotion expire both paths. A cookie scoped to an arbitrary removed custom prefix cannot reach the canonical restore route and requires a fresh dashboard login.

What the dashboard can do

The first release focuses on the Current Host:

• Access -> review pending remote logins, approve or deny them, revoke clients, and change roles
• Caplets -> inspect installed Caplets and update readiness
• Catalog -> review installable or updatable catalog entries before mutating the host
• Vault -> inspect stored keys and grants, add or remove values, and perform explicit reveal actions
• Runtime -> inspect host health, diagnostics, logs, and restart availability
• Activity -> review recent operator activity on the host
• Settings -> inspect the current dashboard session and host connection details

Vault and dashboard administration

The dashboard can administer Caplets Vault state on the host, but Vault safety rules still apply. Raw Vault Reveal is available only at /dashboard/api/private/vault-reveals; it requires the Dashboard Session Credential, current CSRF value, and exact confirmation, and returns Cache-Control: no-store. It is not an Admin API or bearer/SDK operation.

For CLI-based Vault workflows and setup guidance, see Caplets Vault.

Current Host model

The dashboard is host-scoped. It administers the Current Host that served the active dashboard session. This release is not a multi-host control plane.

Local no-auth mode

Development no-auth mode exists for local iteration, but it is not the normal production flow. In that mode the browser skips operator approval so you can iterate on the UI and host-admin flows locally. Do not treat it as the deployment model for Current Host administration.

Related docs

• Install -> install the CLI and open local or remote Current Hosts
• Remote attach -> use Access Clients and Remote Login without the dashboard
• Configuration -> configure Current Host origins and public request identity
• Caplets Vault -> CLI Vault setup, grants, and diagnostics