Dashboard (Planned)
Not yet implemented
This feature does not exist in the Manager UI today. The pages described below are a design for a future release — see Known Issues: No overview dashboard. Until it ships, the Manager opens on the Projects list, and per-project/tenant/application status is only available by browsing to those pages directly.
The plan is for every level of the hierarchy to have a dashboard as its landing view — read-only, at-a-glance answers to "is it healthy, what changed, what needs me". Dashboards would link into the regular pages for every action; nothing would be edited on a dashboard itself.
Home (planned)
The Manager's start page would show:
- Counts — projects, tenants, applications, deployments, users (scoped to what you can access; each tile links to its list page)
- Backend health — registered backends with heartbeat age and version; stale or never-heartbeated registrations are flagged
- Proxy config status — last rendered config hash, last push time and result, and a drift flag; a rejected push shows the rejection reason
- Trigger outcomes — fired / delivered / failed over the last 24 hours, with the most recent failures
- Recent activity — the latest audit-log entries in your scope
Project (planned)
The landing tab of every project would center on a deployment matrix — applications × environments, each cell showing that deployment's status (backend heartbeat, version, drift) and domains; cells without a deployment would read "not deployed". Alongside it:
- Tenant / application / environment counts and pending invites
- Enablement grid — which tenants have which applications enabled, linking to the enablement editor
- Project-scoped activity feed
Tenant (planned)
The landing tab of a tenant — and the home screen tenant admins would see in their scoped view. Would show members by role, pending invites with expiry, the tenant's enabled applications, and tenant-scoped activity (membership, role, and invite events). Content would be permission-scoped: tenant admins would see exactly their organization, operators would see the same page with full detail.
Application (planned)
The landing tab of an application. Per environment, it would show:
- Deployment panel — spec summary (image, ports, resources, scaling), domains, upstream (auto-derived from the rendered job, or the manual override), backend heartbeat and version
- Rendered-config preview — the vhost block and Nomad job exactly as the renderer emits them, with the spec hash and a drift indicator against what's running (the UI face of
pfy deploy diff) - Spec history — who changed what, field-level before/after, from the audit log
Plus the application's triggers with their last-run outcome, and the enabled tenants with an effective-config preview — the merged Project → Tenant → Tenant × Application configuration exactly as that tenant's users would receive it.
Where things would be edited
Dashboards are designed to be read-only; all editing would continue to happen on the existing pages:
| Seen on the dashboard | Edited at |
|---|---|
| Deployment spec, domains, upstream override | Application → deployment editor (or pfy deployment set) |
| Tenant ↔ application enablement | Application → Tenants tab / Tenant → Applications tab (or pfy application enable) |
| Members, roles, invites | Tenant → Members / Invites |
| Triggers | Application → Triggers |
| Platform-level proxy settings (OIDC portal, globals) | install.yaml + pfy platform render — file-managed, not in the UI |
In the meantime
Until the dashboard ships, the equivalent information is available by browsing directly: