Dashboard
A Supabase-style admin SPA served at /dashboard. React, Vite and shadcn/ui, with its own
build.
Two ways in
Section titled “Two ways in”Through the control plane. The normal path: sign in with a platform account, pick a
project, and the dashboard exchanges your membership for a project token per project you open.
On a fresh deployment it first probes setup-status and renders an install wizard instead of
the sign-in form.
Key-only. A grove dev server has no control plane — it has exactly one project, and the
key embeds its id. So the CLI prints:
http://localhost:8099/dashboard?key=gb_sk_proj_dev.…#/The dashboard stores the key and strips it from the address bar so it does not linger in
history. After the first visit, http://localhost:8099/dashboard#/ is enough.
Sections that need the control plane — Connections, Environments — are hidden in that mode rather than left to fail with a 401 you cannot act on.
Sections
Section titled “Sections”Grouped in the sidebar as Project, Build and Manage.
| Section | What it does |
|---|---|
| Overview | Project summary and quick stats. |
| Collections | The schema builder and the collection creation wizard — Define, Access, Review. The Access step writes correct policy rules from a template. |
| Data browser | Browse and edit documents. This uses the admin routes, which bypass policy filters (they still validate against the schema). |
| Users | End users: create, edit, and the activate/deactivate/block transitions. |
| Roles · End-user roles | The two role namespaces, edited separately. |
| Auth providers | Per-project Google and GitHub config, plus the redirect allowlist. Each card shows the exact callback URI to register. |
| Functions | The Monaco code editor, version history and rollback, run logs, stored tests, and the visual flow builder. |
| Integrations | Provider config, with a test modal that defaults to dry mode. |
| Storage | Buckets, files and access. |
| API keys | Mint, rotate and revoke. The raw secret is shown exactly once. |
| API docs · API explorer | The OpenAPI spec, typed to your project, and a request runner. |
| Audit logs | The append-only action log. |
| Environments | Create environments and promote config between them, with the semantic diff rendered. |
| Connections | The org and project connection registry. |
| MCP server | Wiring instructions for the MCP admin server. |
| Local | Only under grove dev — how your bundle differs from the real project. |
| Settings | Project name, appearance, file-size limit. |
Operator-only pages (Billing, Customers, Plans, Operators) render only when
GET /control/me reports the operator role.
The Local section
Section titled “The Local section”Worth understanding because of where the work happens. The comparison between your bundle and the deployed project needs the project’s admin key — and that key must never reach a web page.
So grove dev runs the comparison itself, writes a credential-free snapshot to
.grove/local-status.json, and the dashboard merely renders it. Applying stays in the
terminal.
Building it
Section titled “Building it”dashboard/dist/ is git-ignored and built in Docker and CI. Locally:
make dashboard # or: cd dashboard && bun run buildmake dashboard-dev # Vite dev server, proxying /api to localhost:8080Without a build, bun run dev falls back to a legacy embedded page.
For a compiled @groveback/server binary the dashboard is embedded at build time with a
content-hashed manifest, so a self-hosted binary serves it with no extra step.
Other built-in pages
Section titled “Other built-in pages”| Path | What |
|---|---|
/docs · /p/:pid/docs |
Swagger UI. |
/graphiql · /p/:pid/graphiql |
The GraphQL IDE. |
/examples/oauth |
A minimal OAuth login tester. |
/auth/login |
A hosted sign-in page your app can redirect to. |
/reset-password |
The hosted password-reset form. |