Skip to main content

Dashboard

The Gig'MCP dashboard is a Next.js app that runs as a pure frontend in its own container (the web service in the compose stack, port 3000). It holds no state and owns no sessions — every action is a call to the gateway's REST API, authenticated by the gateway-issued gig_session cookie.

note

The dashboard requires the OIDC control plane to be configured on the gateway. If GIG_OIDC_* is unset, /api/* returns a descriptive 404 and the login page surfaces a setup hint instead of a sign-in button. See authentication.

How it talks to the gateway​

The dashboard never does cross-origin requests. next.config.ts defines server-side rewrites:

/api/:path*  →  ${GATEWAY_INTERNAL_URL}/api/:path*
/mcp/:path*  →  ${GATEWAY_INTERNAL_URL}/mcp/:path*

From the browser's point of view, the gateway API is same-origin on port 3000, so the httpOnly gig_session cookie flows automatically — no CORS, no credentials: 'include'. The frontend's API client builds only relative /api/... paths, encodes every dynamic path segment, and parses the gateway's {"error":{"code","message"}} envelope into typed errors. Data fetching and cache invalidation use TanStack Query.

warning

GATEWAY_INTERNAL_URL is evaluated at build time and baked into the standalone Next.js build; the runtime environment variable is ignored. The compose file sets it as a build arg (http://issuer-proxy:8080). Rebuild the web image if the gateway's internal address changes.

Pages​

Navigation is role-aware: the Users page is shown only to admins; everything else is visible to every signed-in user.

Overview (/)​

Stat cards (profiles, servers, credentials, and — for admins — users) plus a recent-activity table of audit events, with color-coded kind and decision badges (allow is the only non-alarming decision).

Servers (/servers)​

Lists installed MCP servers. Admins can:

  • Install a server by registry ref (e.g. name@version) via POST /api/servers/install — the gateway resolves it against the signed registry index
  • Uninstall via DELETE /api/servers/{name}

Non-admins get a read-only list.

Profiles (/profiles)​

Lists your profiles (admins see all) and creates new ones (name + slug). The profile detail page (/profiles/{id}) has three cards:

  • Endpoint — the profile's MCP endpoint path (/mcp/p/<slug>) with a copy button
  • Bundle — checkbox selection of which installed servers the profile exposes, saved as a replace-all PUT /api/profiles/{id}/servers
  • Rotate token — issues a fresh profile bearer token; the plaintext is revealed exactly once in a dialog and never retrievable again

See profiles & tool routing for the underlying model.

Credentials (/credentials)​

Per-server credential entry for the vault. Secrets are write-only: the list shows metadata only (server, injection header/format, placeholder, allowed hosts) — never the secret. The form validates:

  • server name: ^[a-z0-9][a-z0-9_-]{0,63}$
  • injection header: ^[A-Za-z0-9-]+$
  • allowed hosts: ^(\*\.)?[a-z0-9.-]+$

The advanced fields (inject_header, inject_format, placeholder, allowed_hosts) are transitional: once manifest sourcing from the registry fully lands, the body shrinks to just the secret and the manifest supplies the rest.

Users (/users) — admin only​

Read-only user list with role badges. Roles come from the identity provider and cannot be edited here (they refresh on every login). Admins can start view-as impersonation of another user; while active:

  • a persistent banner shows who you are viewing as, with a "stop viewing" action
  • the entire dashboard switches to read-only — mutations are blocked by the gateway (403) and the UI disables the corresponding controls

Audit (/audit)​

Newest-first audit log with keyset pagination (GET /api/audit?before=&limit=). Kind filter chips (egress / auth / admin) are applied client-side — the server API has no kind filter. Non-admins see only their own events; admins see everything and can filter by user.

Login (/login)​

A single "Sign in" button that sends the browser to the gateway's GET /api/auth/login, which 302s to the identity provider. The page first probes GET /api/me: already signed in redirects home; a control_plane_disabled error shows which environment variables to set.

UI details​

  • Theme switcher (light/dark) and language switcher — i18n is cookie-based via next-intl, with no locale routing.
  • Token reveal dialog — used wherever a plaintext token is shown once (profile create, token rotation).
  • Impersonation banner — driven by GET /api/me, which returns the effective user plus the real admin identity while view-as is active.