Tour the dashboard

Product tour

The Greenlight dashboard is the single operational surface for IT — every app, integration, grant, user, and audit event in one place. This page is the five-minute visual map: what each screen shows, with a link to the page that explains how it works.

Apps

The fleet at a glance: every app with status, owner, last deploy, pipeline result, and a usage signal (requests and active users over the last week — sortable, so heavily used and idle apps are tellable apart), plus a health bar and alerts for anything that needs attention. This is where most of the day-to-day starts.

Clicking an app opens its detail page — itself a small dashboard grouped into five tabs: Overview (with a system map of the app’s workloads, provisioned resources, and connected integrations), Deployments (pipeline runs), Access (marketplace access requests, discoverability, permissions, RBAC, co-owners), Monitoring (resource metrics, usage analytics, and logs), and Configuration (environment variables) — plus a header power menu for the app’s lifecycle actions: suspend/restore and delete. → App deployment & isolation

The app detail page for Basis, showing the app icon, active status badge, repo link, description, a screenshot preview, and tabs for Overview, Deployments, Access, Monitoring, and Configuration.

Pipeline runs

Every pull request’s run with a per-check verdict — secret scanning, static analysis, container scan, policy engine, build, deploy — and the OPA decision in full. Deploy runs also carry release notes, captured from the merged pull request’s title and body, so you can tell what each release changed without opening GitHub. → Source control & the policy check

A pipeline run detail page showing commit a1b2c3d on main, status Passed, with six checks all green: gitleaks, semgrep, trivy, opa-policy, build, and deploy, followed by the OPA decision block showing allow: true.

Marketplace

Browse every live app your colleagues have built and open the ones you can access — one consumer-facing card per app, with its icon, cover, owner, tags, and summary. Off by default: an org admin turns it on for everyone under Settings → Organization.

Integrations

One tab for the org’s outbound integrations and the grants apps and people hold against them, with a control to switch between two sub-views:

Integrations — one card per upstream service, showing the registered base URL (or database host for connected DBs), its named credentials, how each reaches apps (proxied or injected), the Key Vault reference, availability toggle, and a per-credential count that expands into the access ledger: everyone — app or person — who has requested or holds that credential, with status and when. Making an integration inactive keeps it visible to IT while hiding it and its Knowledge from agents until reactivated. IT registers from a searchable, logo’d catalog (GitHub, Slack, OpenAI, Salesforce, Snowflake, …) that shows provider auth and credential placement read-only, or a Custom path where IT selects them for anything not catalogued. → Manage integrations
Grants — the org-wide inventory of which access holders — apps and people — hold which grants, grouped by integration or by access holder, with pending requests triaged in place. Personal requests (made through a user’s agent or CLI) land here beside app requests. This is where IT approves, denies, and revokes. → Governance & policy

The Integrations tab listing Snowflake — Analytics (proxied, user-delegated OAuth) and Reporting DB — Postgres (injected, connection string), each showing credential slugs, scopes, Key Vault references, and the number of access holders with grants.

The Grants sub-view of the Integrations tab grouped by integration, showing 3 grants awaiting review across Close, Fireflies, and Slack, with Approve and Deny buttons on each pending row and Revoked status on a previously removed grant.

Knowledge

Org- and app-scope entries plus the queue of pending agent proposals to review, accept, or reject. → Curate Knowledge

Audit

Audit health, live write throughput, and the queryable log of every governed action — filter by event, app, actor, and time range. → Observability & audit

Users & RBAC

The user directory and the group-to-role mapping table that turns IdP groups into Greenlight roles. Selecting a user opens an inspector with their identity and groups, the apps they own or co-own (each links straight to that app), and the apps they can reach through their groups. Org Owners can also Log in as an Admin or Builder here to see the dashboard under that person’s role (audited, with a Stop banner). → Identity, SSO & RBAC

Internal health

The control plane’s own health against its performance targets — MCP latency, queue depth, database connections, pod readiness, the status of the cloud resources backing your install (compute cluster, database, secrets vault, registry, storage, DNS), and component versions. A Fleet Reporting section shows exactly what your install shares with Shift: the one-time enrollment payload (installation id, key hash, org name, tenant id, region) and the latest health report delivery with its exact JSON — redacted operational summaries only, never customer data. → Install on Azure

Feedback

The channel where builder agents file platform-experience reports (bugs, friction, improvement ideas) and dashboard users file UX reports through the shell’s Send feedback dialog — available on every page. Org admins triage the combined list (filter by source, status, and category), read each report, and bulk-export selected items as a single Markdown file to hand to the platform team. Feedback content is treated as untrusted: capped, rendered inert, and rate-limited.

And the rest

Policy — the active policy bundle as editable rules, plus recent check results across all PRs. → Governance & policy
Settings — org-level configuration: SSO (including reconfiguring or swapping the identity provider), update policy, agent rollout snippets, notification destinations, and source control. Branch policy stays read-only (enforced at registration, not editable here), but the source-control tab also carries the GitHub App lifecycle actions: verify repo access, re-create the App, and migrate the org to a different GitHub organization. It also manages plugin marketplace repositories — create public or private sources, inspect all managed rows, or recreate one if it was deleted on GitHub. Agent setup lets you select an agent and any of those sources for tailored rollout instructions; the Claude organization snippet installs Greenlight, starts Auto Mode, and pre-approves all Greenlight MCP and CLI actions—including control-plane-hosted CLI installation and refresh—without weakening Claude’s controls for unrelated tools. Notifications cover health/anomaly alerts and pending permission requests only — deploy and pipeline failures are inspected on app and pipeline surfaces, not routed as alert categories.
Upgrades — current version, discovered releases, and upgrade history. → Upgrades

What’s not in the dashboard

A few things deliberately aren’t here, because they belong somewhere else:

App code — the source of truth is your SCM. The dashboard links out to the repo for every app.
Long-term log analytics — ship cluster logs to your own aggregator. The dashboard’s logs view is for the live tail.
Secret values — the dashboard shows that a secret exists; you read its value (if you have permission) through your cloud’s vault UI.
End-user analytics for an app — the app’s owner builds that into the app, or hooks the app up to a real analytics product.

How it works The five steps from idea to governed production.

Admin guide Install, configure, and operate Greenlight.

Security posture The one-page summary for security reviewers.