Just Dashboard Roles and capabilities
What readonly, limited, and admin accounts can do in Just Dashboard.
Just Dashboard 0.8.4 has three roles. The first account is an administrator. An administrator manages later dashboard accounts under Account → Users. The API checks capabilities on its routes; hiding a button in the browser is not the security boundary. Each account can see its own role and capabilities under What this account can do on Account → Profile.
| Capability | readonly | limited | admin |
|---|---|---|---|
read — view host and dashboard information | ✓ | ✓ | ✓ |
metrics.read — scrape the recorded database metrics for Prometheus | ✓ | ✓ | ✓ |
service.control — start, stop, or restart services, containers, and processes; run deployments | ✓ | ✓ | |
file.write — change files and supported Git content | ✓ | ✓ | |
terminal — host shell and container execution | ✓ | ||
destructive — delete, prune, kill, or restore | ✓ | ||
system.admin — accounts, everyone's API keys, firewall, dashboard settings and updates, and other host policy | ✓ |
These are coarse capability groups. A specific operation can require more than one permission, and some actions are limited to a signed-in browser session. For example, a limited user can operate services and edit files but cannot open the terminal or restore a backup. An admin can do all of those things and change access settings. Destructive actions pause for confirmation; the few unrecoverable ones, such as deleting a database or a Git checkout or wiping the dashboard on uninstall, ask for a typed phrase checked by the server.
readonly still has broad read access. With the default JD_FILE_ROOTS=/, a read-only account can read permitted files on the host. Give it only to someone who should have that visibility, or narrow the file roots and matching container mounts for your installation. The database table browser, export, and value search refuse the tables that hold an engine's own credentials, such as PostgreSQL's pg_authid, whatever the role.
What some features need
| Feature | Who can use it |
|---|---|
| Remote Desktop | Administrators only. Seeing and adding computers needs system.admin; opening a session also needs terminal and a browser session, so an API key cannot open one. |
| Excalidraw drawings | Every role can open drawings. Creating and editing a drawing, its shape library, or a described diagram needs service.control (limited or admin). Deleting a drawing needs destructive. |
| SQL assistant | An administrator chooses its provider. Asking it needs service.control. |
| Database MCP server keys | Any account can make one at its own role or narrower. Write access to a database needs limited or admin. |
| Deployment notifications | Every role can read channels and their history. Creating or changing a channel needs system.admin. |
| Deployment credentials, audit log, system users | system.admin. |
Hiding a section from the sidebar under Account → Workspace never changes what a role allows, and a section the role cannot open is not offered there.
API keys
An API key carries a role no wider than its owner's. Its effective role is the narrower of the two, so demoting or disabling an account immediately narrows or stops every key it issued. Keys cannot use the routes that need a browser session: changing passwords, creating keys, managing dashboard accounts, and opening a Remote Desktop session.
Two kinds of key are limited further. A metrics key holds only metrics.read and reaches nothing but the database metrics endpoint. An MCP key opens only the MCP endpoint and only the databases it was given. See Sessions and API keys.
Two-factor and recovery
Roles do not bypass two-factor authentication. An enrolled user must provide a code or single-use recovery code at sign-in. JD_REQUIRE_2FA=true, or Require two-factor under Settings → Configuration, makes enrollment mandatory for unenrolled accounts. An administrator can reset another user's enrollment under Account → Users if that person loses the authenticator and recovery codes.