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, workspace UI, and PostgreSQL — all shipped together in the distribution. The backend exposes a REST API on port 8080 and an actuator on port 9090. The workspace is a static React bundle served by Nginx on port 8090. PostgreSQL is part of the stack and stores all persistent state. Sessions and rate-limit counters live in the backend's in-process cache; no external cache is required.

All three components ship together and run on a single host by default. PostgreSQL is the only stateful component; for larger installs you can move it to a dedicated host or a managed service, since it 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 16 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.

Caching. The backend keeps sessions and rate-limit counters in its own memory. The on-prem distribution does not include or require a separate cache such as Redis.

What on-prem does not include today​

A few features are not part of on-prem as of mid-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​