Access & security
Deckgauge authenticates through Keycloak and controls access per board with three roles, plus fine-grained controls for sensitive data.
Authentication
Sign-in is handled by Keycloak (OpenID Connect) via NextAuth. The login page offers "Continue with Keycloak" and self-registration. The web app authenticates to Keycloak; the API verifies the resulting JWT on every request and maps it to a local user record. You can federate Keycloak to Microsoft Entra ID for corporate SSO.
Board roles
Access is granted per board at one of three levels:
| Role | Can do |
|---|---|
| Viewer | Read the board and its dashboards; all edit controls are hidden. |
| Editor | Everything a viewer can, plus create/edit items, columns, and roadmaps. |
| Owner | Everything an editor can, plus manage sources, sharing, and board settings. |
- Ranking is
Viewer < Editor < Owner; the API enforces the minimum role on every board action. - A board must always keep at least one owner — removing the last owner is refused.
Sharing
Board owners grant access from the board's share controls — add a registered user at viewer, editor, or owner level, change a role, or revoke access. Roadmaps have their own access checks. An org-wide admin role (cockpit-admin) exists for platform administrators.
Data handling & privacy
- Open source: the app, databases, and analytics store (ClickHouse) are all open and inspectable. Deckgauge doesn't phone home with your data.
- Read-only connectors: Deckgauge only reads from Jira, GitHub, GitLab, and Azure DevOps — it never writes back.
- Secret masking: stored tokens (Jira, GitHub, GitLab, ADO) are never returned in full — they appear as
***in the UI and API. - Least privilege: connect each source with a token scoped to only what Deckgauge needs to read.