System requirements¶
Supported platforms¶
| Layer | Supported | Notes |
|---|---|---|
| OS (binary install) | Linux x86-64 / aarch64; Windows x86-64 | Tested with Ubuntu 22.04+, Debian 12+, RHEL 9+, Rocky 9+, Windows Server 2022 |
| Container runtime | Docker 24+, containerd 1.7+ | Any OCI-compliant runtime works |
| Kubernetes | 1.27+ | The base manifests use API versions stable in 1.27. Tested on EKS, AKS, GKE and vanilla kubeadm. |
| .NET runtime | 10.0 | Bundled into self-contained binary builds and the container image. You only need .NET on the host if you build from source. |
PostgreSQL¶
PostgreSQL 16 or newer is the only production-supported store.
| Capability | Used by | Why |
|---|---|---|
JSONB + jsonb_path_ops GIN indexes | Dynamic groups, lint rules | Containment queries on AgentDescription |
LISTEN / NOTIFY | Cross-instance dispatch backplane | Optional alternative to Redis |
| Row-Level Security | Hard multi-tenant isolation | One-time setup at install |
pgcrypto | Optional, only if you re-encrypt at-rest material in-database | Default deployment uses application-side AES-GCM |
SQLite is supported for development convenience only. Do not run production on SQLite.
Sizing guidance for Postgres¶
| Fleet size | Recommended Postgres |
|---|---|
| ≤ 200 agents | 2 vCPU, 4 GiB RAM, 20 GiB SSD |
| 200 – 2000 agents | 4 vCPU, 16 GiB RAM, 100 GiB SSD |
| 2000 – 10 000 agents | 8 vCPU, 32 GiB RAM, 500 GiB SSD; consider read replicas for the dashboard |
| > 10 000 agents | Talk to us. The bottleneck is JSONB write throughput on agent-status events. |
Ampora server¶
| Fleet size | Replicas | CPU per pod | Memory per pod |
|---|---|---|---|
| ≤ 200 | 1 | 200 m / 1500 m | 384 Mi / 1 Gi |
| 200 – 2000 | 2 | 500 m / 2 | 512 Mi / 2 Gi |
| 2000 – 10 000 | 3 – 5 | 1 / 4 | 1 Gi / 4 Gi |
The requests / limits columns above match the base deployment.yaml. Override per overlay if your fleet sits at the top of the band.
Network¶
Inbound to Ampora¶
| Port | Protocol | Used by | Notes |
|---|---|---|---|
| 443 | HTTPS / WSS | Operators (browser) and agents (OpAMP) | Single TLS port covering both is the default |
| (optional) 9464 | HTTP | Prometheus metrics endpoint | Cluster-internal scraper only — never expose externally |
You can split agent and operator traffic onto two TLS ports if your network policy demands it. See Configuration → Settings.
Outbound from Ampora¶
| Target | Reason | Required? |
|---|---|---|
| PostgreSQL | Persistence | yes |
| OIDC provider (Keycloak, Okta, AzureAD, …) | Operator login | yes (production) |
| Redis | Cross-instance backplane | only if Dispatch:Backplane = Redis |
| HSM / KMS endpoint | Cryptographic operations | only if not using the software provider |
| OTel collector | Self-observability export | recommended |
| Git host (HTTPS or SSH) | GitOps config sync | only if you use GitOps |
| Object storage (S3 / MinIO / GCS / Azure Blob) | Package artefact storage | only if you push binary packages |
| Federation peers | Federated read aggregation | only if you federate |
Air-gapped deployments are supported. Disable the features whose outbound endpoints you cannot reach.
TLS certificates¶
Ampora is mTLS-aware but does not terminate public TLS itself. A production deployment puts a reverse proxy in front (NGINX, Traefik, k8s Ingress, Application Gateway, …) which:
- terminates the server TLS to the operator browser,
- forwards client mTLS material to Ampora via standard headers (
X-SSL-Client-Cert,ssl_client_escaped_cert, …) so Ampora can verify agent identity.
Internal CA: Ampora issues its own agent client certificates out of a persisted CA, optionally backed by HSM/KMS. You do not need to provision those externally. See mTLS & PKI.
Browser support¶
The web UI (Blazor Server + SignalR) supports:
- Chromium-based browsers (Chrome, Edge, Brave) latest two majors
- Firefox latest two majors
- Safari latest two majors
Stable WebSocket / EventSource support is required. IE11 is not supported.
Authentication¶
OIDC is the only supported user-auth mechanism. Locally Ampora ships with a preconfigured Keycloak realm; production typically uses your existing IdP.
The OIDC provider must support:
- the Authorization Code flow with PKCE,
- ID Token JWS signatures,
- OIDC discovery (
/.well-known/openid-configuration).
See OIDC authentication for the full mapping.