System requirements for PanDev Metrics on-prem
PanDev Metrics on-prem ships as a self-contained stack — backend, workspace, and PostgreSQL 16 — that you run from the distribution archive with Docker Compose or the bundled Helm chart. By default everything runs on a single host; for larger installs you can move the database to a dedicated host or a managed service. This page lists the hardware, supported operating systems, the CPU-instruction baseline, and required software versions.
At a glance
| Property | Value |
|---|---|
| Topology | Single host by default (database bundled); external/managed database optional |
| Deployment options | Docker Compose or Kubernetes 1.28+ |
| OS family | Linux — x86_64 or arm64 |
| Database | PostgreSQL 16 (bundled); 17 also supported |
| Backend API port | 8080 |
| Workspace UI port | 8090 (Docker Compose host port; on Helm the workspace Service is 80 behind Ingress) |
| Actuator port (internal) | 9090 |
Hardware
Size the deployment by organization size — the number of tracked engineers drives event volume, materialized-view size, and query load.
What scales, and what doesn't:
- Backend and workspace stay light at every size. The backend is a GraalVM native image that holds database connections and orchestrates work; the heavy computation happens in the database, not in the application.
- PostgreSQL is the component that scales. It carries the analytical workload — the nightly materialized-view refresh and the dashboard queries.
- For day-to-day use, CPU is rarely the bottleneck — dashboards read pre-computed materialized views. The one real consumer is the nightly materialized-view refresh: a mostly single-stream batch that runs in roughly 10–15 minutes for a ~70-engineer install on typical cloud hardware and grows with data volume. It is bound by per-core CPU speed and disk speed — not core count (extra vCPUs do not speed it up), so favor a few fast cores on SSD/NVMe over many slow cores. It fits the nightly window comfortably; for large installs, fast storage keeps it short.
- The real sizing levers are RAM — keep the working set (recent events, all materialized views, and their indexes) in memory — and disk, because raw events are retained indefinitely.
Sizing profiles
| Profile | Application (server + workspace) | PostgreSQL (CPU / RAM) | PostgreSQL disk |
|---|---|---|---|
| XS — up to ~10 engineers (pilot / small team) | 2 cores / 4 GB | 2 cores / 8 GB | 50 GB SSD |
| Small — up to ~50 engineers | 2 cores / 4 GB | 6 cores / 16 GB | 100 GB SSD |
| Medium — ~50–200 engineers | 4 cores / 8 GB | 8 cores / 32 GB | 100–250 GB SSD |
| Large — 200+ engineers | 4 cores / 8 GB | 16 cores / 64 GB | 500 GB+ NVMe |
The bundled Helm chart and Compose stack ship tuned to the Small profile, which fits most installations. For very large deployments (500+ engineers or several years of history) keep PostgreSQL at 16 cores / 64 GB on a dedicated host or a managed instance.
These are sized for comfortable, responsive performance — not bare minimums. The levers that keep it fast are RAM and SSD/NVMe, not core count; give PostgreSQL fast storage and enough memory to keep the working set cached.
Single host vs. split
On a single host — the default Docker Compose layout — sum the two component columns. A Small install on one host therefore wants roughly 8 cores / 20 GB; an XS pilot fits comfortably in ~4 cores / 12 GB. From Medium up, move PostgreSQL onto its own host or a managed instance, where it can be sized and tuned independently of the application.
Disk sizing
PostgreSQL storage grows with the number of engineers, integrations, and how much history you keep — raw events are retained, there is no retention cut-off today. The materialized views refresh with REFRESH MATERIALIZED VIEW CONCURRENTLY, which transiently needs roughly 2× the size of the largest view on top of the steady-state footprint, so leave headroom. Use fast SSD/NVMe storage: the nightly refresh and large dashboard aggregations are I/O-sensitive.
CPU and architecture
The backend is published as a GraalVM native image, compiled ahead of time for a specific CPU architecture. This is why the distribution ships two image variants — pick the one that matches your host:
| Architecture | Image tag | Notes |
|---|---|---|
| x86_64 / amd64 | default (e.g. :<version>) | Requires the instruction baseline below |
| arm64 | -arm suffix (e.g. :<version>-arm) | Native arm64 build, including Apple Silicon |
On x86_64, the native backend requires a modern instruction baseline. The host CPU (and any virtualization layer in front of it) must expose:
CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3,
SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA
Verify on a candidate x86_64 host:
lscpu | grep -E "avx|avx2|fma|sse4"
If these instructions are missing — typically because a hypervisor masks them — the native backend aborts at startup with Illegal instruction. On arm64 hosts, use the -arm image tags; the x86_64 instruction list above does not apply.
Virtualization settings
If the x86_64 backend fails to start on a virtual machine, the hypervisor is most likely masking required CPU instructions from the GraalVM native image. Pass the host CPU through to the guest using the setting for your platform.
| Platform | Setting |
|---|---|
| Proxmox VE | cpu: host in VM config |
| VMware ESXi | VM compatibility 7.0+, CPU passthrough |
| VirtualBox | Enable VT-x, Nested VT-x, PAE/NX. Run VBoxManage modifyvm "VM" --cpu-profile host |
| Hyper-V | VM generation 2, disable CPU compatibility mode |
| XCP-ng / XenServer | CPU mode host-passthrough |
| QEMU / KVM | -cpu host or explicit flags +avx2,+fma,+bmi2 |
Operating system
PanDev Metrics on-prem runs on any current Linux distribution that ships a supported Docker Engine.
| Distribution | Tested versions |
|---|---|
| Ubuntu Server | 22.04 LTS, 24.04 LTS |
| Debian | 11 (bullseye), 12 (bookworm) |
| RHEL / Rocky / AlmaLinux | 8, 9 |
| SUSE Linux Enterprise Server | 15 SP4+ |
Other Linux distributions that meet the kernel and Docker requirements also work, on both x86_64 and arm64. Windows Server is not supported.
Software
| Component | Required |
|---|---|
| PostgreSQL | 16 (bundled); 17 also supported |
| Docker Engine | ≥ 20.10 |
| Docker Compose | ≥ v2.0 (v2.20+ recommended) |
| Kubernetes | ≥ 1.28 (Helm path) |
| Helm | 3.x (Helm path) |
PostgreSQL 16 ships inside the distribution, so you do not install it yourself unless you choose an external database. The backend is compatible with both PostgreSQL 16 and 17 — use 17 if your external or managed database runs that version. An external cache (such as Redis) is not part of the distribution and not required — the backend caches sessions and rate-limit counters in-memory.
Network
Inbound and outbound network requirements are documented separately in Network and ports. Summary:
- Public inbound on 8080 (backend API) and 8090 (workspace UI) — or behind a reverse proxy on 443
- Internal inbound on 9090 for the actuator (health and metrics)
- PostgreSQL on 5432 — published to the host by the bundled Compose file; bind it to localhost or firewall it off for non-local installs
- Outbound HTTPS to the PanDev license server, plus your configured Git provider and task tracker (egress is minimal and cannot be disabled)
Browser support
The PanDev Metrics frontend is a modern single-page React application. Recent versions of Chrome, Edge, Firefox, and Safari are supported. The team targets the latest two major releases of each browser.
Constraints and edge cases
- Single organization per installation. On-prem does not support multi-tenant separation. One install equals one organization.
- No air-gapped deployment. Minimal outbound network access is required for integrations.
- Horizontal scaling of the backend is not part of the on-prem distribution. Run a single backend instance per installation; vertical scaling via larger hosts is the supported path.
Related
- How-to: Install PanDev Metrics on-prem
- Reference: Network and ports
- Concept: On-prem architecture