Self-Hosting Hoppla

You can run the full Hoppla monitoring platform — uptime, SSL, DNS, cron, performance, status pages, and white-label client portals — on your own Kubernetes cluster, fully autonomously.

Your instance is driven by a signed license file and never phones home. It does not talk to Hoppla's servers to validate the license, fetch features, or report usage. Everything runs inside your network: your data stays in your PostgreSQL database, your checks run from your cluster, and your alerts go out through your own SMTP. The license simply unlocks the entitlements your contract includes.

Cloud vs. self-hosted

If you would rather not operate Kubernetes, the hosted service at app.hoppla.dev gives you the same product with nothing to run. Self-hosting is the right choice when you need data residency, network isolation, or you are reselling monitoring under your own brand on infrastructure you control. The feature set is the same — including the full reseller stack.

Supported platform

Component	Requirement
Kubernetes	≥ 1.28, or a current k3s. A single node is fine for up to roughly 1,000 monitors.
PostgreSQL	16 with the TimescaleDB extension. Shipped in-cluster by the chart, or bring your own — but note that managed RDS-style Postgres usually lacks TimescaleDB (see Scaling).
Redis	7. Shipped in-cluster by the chart, or bring your own.
Ingress + TLS	ingress-nginx + cert-manager recommended. Any ingress class works if you set the custom-domain provisioner to manual.
SMTP	Required — alerts, invitations, and reports all need a real mailer.
Outbound network	80/443 (checks), 587 (SMTP), 43 (WHOIS), 53 (DNS checks).

How it fits together

                    ┌─────────┐
                    │ Ingress │  (TLS via cert-manager)
                    └────┬────┘
          ┌──────────┬───┴────┬───────────┐
       /api,/ping   /app      /
          │          │        │
     ┌────▼───┐  ┌───▼────┐  ┌▼──────────┐
     │  API   │  │ Reverb │  │ Dashboard │
     └───┬────┘  └────────┘  └───────────┘
         │
   ┌─────▼──────────┐   Scheduler ──► dispatches due checks
   │  PostgreSQL    │   Workers   ──► run checks, write results
   │  (TimescaleDB) │   Alerts    ──► send notifications
   └────────────────┘
   ┌────────────────┐
   │     Redis      │◄── queues + cache (workers, scheduler, API, Reverb)
   └────────────────┘

The scheduler polls for due checks and dispatches jobs onto per-type Redis queues. Stateless worker pools (uptime, DNS, SSL, …) pick them up, run the check, and write results into the TimescaleDB hypertable. A failed uptime check is re-verified from a second probe before any alert fires.

Where to go next

• Installation — cluster prerequisites and getting Hoppla running with install.sh or a manual Helm install.
• Configuration — domains, secrets, TLS, running behind Cloudflare/a CDN, network policies, and the full values reference.
• Scaling — choosing a profile, the TimescaleDB constraint, provider notes (EKS/GKE/AKS), DNS records, and multi-probe regions.
• White-label & resellers — branded portals, custom domains, per-reseller SMTP, and the migration importers.
• Upgrading — release types, routine upgrades, security updates, and rollback.
• Operations — day-2 essentials: diagnostics, license lifecycle, backups, and troubleshooting.