Dashboard

Every level of the Manager UI opens on a read-only dashboard: the platform overview when you sign in, and a project, tenant or application overview at the top of each of those pages. Dashboards answer "is it healthy, what changed, what needs me" at a glance and link into the regular pages for every action. Nothing is edited on a dashboard itself.

All dashboard data comes from four GraphQL queries, dashboardHome, dashboardProject(projectId), dashboardApplication(applicationId) and dashboardTenant(tenantId), each returning every widget's data in one round trip. Every count and list is scoped to what you are allowed to see: a dashboard never shows an aggregate of things you could not list directly.

Platform overview (home)

The start page (/, "Platform overview"). If you have no projects yet it shows a welcome card with a View projects button instead.

• Stat tiles: Projects, Tenants, Applications, Deployments, Users. The Projects tile links to the project list.
• Backend health: every registered backend as <application> · <environment> with its version and a status: Healthy, Stale (last heartbeat older than twice cron.backend_heartbeat_timeout), No heartbeat (registered but never heartbeated) or Inactive.
• Proxy config status: State (Healthy, Unverified, Drift, Push failed or Unknown, with the age of the last attempt), Rendered hash, Applied hash, Verified and Last error. Applied hash is what the proxy is running, or a dash when nothing is known; Verified is a sentence saying where that number came from, which is the difference between a check and an assumption. A hash match with no proxy_metrics_url reports Unverified, never Healthy. When proxy_admin_url is not set the panel renders an empty state rather than rows, deliberately the same thing a non-administrator sees, because install-wide proxy state is admin-only and the gate must not leak the install's state through its own behaviour.
• Sync now: system administrators can push proxy configuration from that panel. It renders the current state and pushes it, blocking until the push settles, then reports which of three outcomes occurred: pushed, already current, or another instance holds the push lock. It is the same syncProxyConfig mutation pfy proxy sync calls, and writes the same audit row.
• Trigger outcomes (24h): Fired / Delivered / Failed counts and recent failures. Per-run outcomes are not recorded, so this panel shows "Trigger run outcomes are not recorded yet" with zero counts.
• Recent activity: the latest audit-log entries in your scope. Each entry links to the entry in the audit log.

Project overview

The top of every project page (/<project-slug>, "Project overview").

• Stat tiles: Tenants, Applications, Environments, Pending invites.
• Deployment matrix: applications × environments. Each cell shows whether a deployment exists (Deployed / Not deployed), its domains, the registered backend's version and heartbeat health, a drift flag, and the health of each managed data store (postgres/redis) in that environment, including one entry per dedicated tenant.
• Tenant application coverage: which tenants have which applications enabled (Tenant2Application).
• Recent activity: project-scoped audit entries. Only project owners can read the project audit log, so other members see "Project audit activity is visible to project owners."

Tenant overview

The top of every tenant page (/<project-slug>/<tenant-slug>, "Tenant overview"), and also the home screen of the tenant-admin shell (/tenant-admin/<tenant-id>). One component serves both: the server fills only the widgets the caller may see, and hides the rest.

• Members: count and members by role, plus recent joins.
• Pending invites: with expiry.
• Enabled applications and Application domains per environment.
• Recent activity: membership, role and invite events for this tenant (Invite, User2Tenant, Tenant, TenantRole audit entries).

A tenant admin without a given permission sees "You do not have permission to view this section." in that panel.

Application overview

The top of every application page (/<project-slug>/applications/<application-slug>, "Application overview").

• Deployments: one panel per environment: image, ports, resources, scaling, domains, upstream, spec hash and migration setting from the deployment spec; the registered backend's version and heartbeat; a Rendered config preview with the Caddy vhost block exactly as the renderer emits it (copyable), its config hash and a drift state (In sync, Drift detected, Drift unknown when no applied hash is known, or Unverified when the hashes match but nothing read the applied one back from the proxy, which is what an install without proxy_metrics_url gets); and a Spec history link to the audit entries for the deployment.
• Triggers: the application's triggers with their schedule and enabled state. Last-run outcome is not recorded, so that column is empty.
• Enabled tenants: each enabled tenant and whether its role is forwarded to the backend (Role forwarded / Role not forwarded).

Where things are edited

Seen on a dashboard	Edited at
Deployment spec, domains, upstream override	Application → Deployments (or pfy deployment set)
Tenant ↔ application enablement	Application page → Tenant access (or pfy application enable)
Members, roles, invites	Tenant → Members / Invites, or the tenant-admin shell
Triggers	Application → Triggers
Proxy sync	Both: Sync now on the Platform overview's proxy panel (system administrators only), or pfy proxy sync. Same admin-gated syncProxyConfig mutation, same audit row. Configuration (proxy_admin_url and friends) stays in the Manager configuration
Platform-level proxy settings (OIDC portal, globals)	install.yaml + pfy platform render; file-managed, not in the UI

Related

• Projects, Tenants, Applications: the pages the dashboards link into
• Audit Logs: the source of every activity feed
• Triggers: what the trigger panel summarises