Skip to main content
Version: v2 (current)

PanDev Metrics on-prem overview

TL;DR. PanDev Metrics on-prem is the self-hosted distribution of the platform. It ships as Docker Compose and Kubernetes deployments, runs a single organization per installation, and supports LDAP / AD for SSO. This page explains the architecture, when to choose on-prem over Cloud, and where to go next.

What on-prem means in PanDev Metrics

PanDev Metrics on-prem is the same product as the Cloud version — same backend, same frontend, same dashboards, same DORA computation — packaged for deployment in your own infrastructure. Customers own the database, control the network perimeter, and run upgrades on their own schedule.

The on-prem distribution differs from Cloud in two ways. First, on-prem runs one organization per installation — there is no multi-tenant separation, because the entire deployment belongs to a single customer. Second, on-prem authenticates users through LDAP / Active Directory as the only supported SSO. Cloud additionally supports Google sign-in for multi-tenant workspaces.

When to choose on-prem versus Cloud

Choose on-prem when at least one of the following applies:

  • Data residency — engineering events, identities, and metrics must remain inside your network perimeter
  • Regulated industry — finance, healthcare, defense, or government workloads with internal compliance requirements
  • Corporate LDAP / AD is the source of truth — you want PanDev Metrics to authenticate against the same directory as the rest of your stack
  • You operate your own Kubernetes or Docker hosts and prefer to keep operations consistent

Choose Cloud (pandev-metrics.com) when you want zero-ops, automatic updates, and multi-organization workspaces. Cloud and on-prem share the same feature set otherwise.

High-level architecture

PanDev Metrics on-prem is a three-component stack: backend, frontend, and PostgreSQL. The backend exposes a REST API on port 8080 and an actuator on port 9090. The frontend is a static React bundle served behind your reverse proxy. PostgreSQL stores all persistent state on a separate machine. Sessions and rate-limit counters live in the backend's in-process cache; Redis is optional and only needed if you later want to share sessions across horizontally scaled backends.

Backend and frontend usually share one application host. PostgreSQL runs on a dedicated machine because the database is the only stateful component that benefits from independent CPU, memory, and storage sizing.

Components in plain language

Backend (Spring + Java 17) is the brain. It ingests events from IDE plugins, syncs Git and task-tracker data, computes DORA and IDE metrics, and serves the REST API used by the frontend and plugins.

Frontend (React + Vite) is the dashboard surface. It is a single-page app served as static files. It talks to the backend over HTTPS through your reverse proxy.

PostgreSQL 17 stores everything that needs to persist: events, employees, dashboards, integrations, computed metrics, and audit records. Row-level security (RLS) is applied to multi-tenant tables for defense in depth, even though on-prem runs a single organization.

Redis 7 — optional. In single-node on-prem the backend caches sessions and rate-limit counters in-memory. Add Redis only if you want to externalise sessions from the instance; it isn't required for a single organization.

What on-prem does not include today

A few features are not part of on-prem in May 2026 and should not be planned around:

  • Multi-tenant / multi-organization is Cloud-only. On-prem runs one organization per installation.
  • SAML and OIDC are not supported. LDAP / Active Directory is the only SSO option for on-prem.
  • Air-gapped deployment is not supported — PanDev Metrics needs minimal outbound network access for Git, task tracker, and IDE plugin integrations.

These limits are deliberate and reflect the current production reality. Cloud customers get multi-organization workspaces today. On-prem customers get full control over data and infrastructure.

Next steps

Citations