Self-Host Umami on Kubernetes

Umami counts web traffic without cookies and without storing personal data, so it needs no consent banner. It is the lightest of the open source analytics tools to operate: one container, one database, no persistent volume. This page covers what it needs, what to budget, and how it compares to Plausible. Edka deploys it on a cluster in your own cloud account.

What Umami Needs to Run

PostgreSQL, and nothing else. Umami stores events, sites, and accounts in a single Postgres database. The application pod itself holds no state, so there is no volume to size, back up, or migrate between nodes. Rescheduling a pod costs nothing.

Edka connects Umami to an existing PostgreSQL installation, database, and login user on your cluster, resolving the host, port, schema, SSL settings, and password automatically. Optional SSL/TLS with certificate verification is supported.

The dashboard and event collection API both serve on port 3000 inside the cluster.

Resource Requirements

Edka’s defaults for the Umami pod:

Setting	CPU	Memory
Request	200m	512Mi
Limit	1000m	1Gi

No persistent volume is provisioned. On a cluster already running PostgreSQL, Umami adds a single stateless pod, which fits comfortably on a CPX21 node (3 vCPU, 4GB) alongside other workloads. See the Hetzner instance types table for the full range.

Umami vs Plausible

Both drop cookies and both avoid personal data. The operational difference is the database layer:

	Umami	Plausible Community Edition
Databases	PostgreSQL	PostgreSQL and ClickHouse
Persistent volume	None	10Gi default
Pod memory request	512Mi	512Mi
Scales to high event volume	Postgres bound	Column store, built for it

Pick Umami when you want the smallest footprint and one database to back up. It is the better fit for a handful of sites and moderate traffic.

Pick Plausible when event volume is high enough that dashboard queries matter. ClickHouse is a column store, so aggregate queries stay fast as rows pile up. The cost is a second database to operate.

Neither locks you in. Both run on your cluster with kubectl access to every component.

What Edka Provisions

Edka deploys Umami and wires up what it needs:

• Umami app. Dashboard and event collection API on port 3000.
• Generated app secret. A 64 character secret is generated automatically to sign authentication tokens.
• PostgreSQL connection. An existing PostgreSQL installation, with the database URL and credentials resolved from Kubernetes Secrets.
• Gateway exposure. Optionally publish the dashboard and tracker through an Envoy Gateway traffic class at your own hostname.

Configuration Options

• Privacy defaults. Anonymous telemetry and built in update checks are disabled by default.
• Tracker customization. Set a custom tracker script name, collect API endpoint, or client IP header for use behind a proxy.
• Resources. CPU and memory requests and limits.
• Placement. Pin pods to a node pool, with automatic tolerations for node pool taints.
• Access. Expose the dashboard at a hostname such as umami.example.com through a Gateway traffic class.
• Auto-updates. Automatic chart and image updates with a patch, minor, major, or custom version policy.

Deploy Umami

1. Click “Deploy Umami” below.
2. Choose a target namespace and confirm the chart and image versions.
3. Select your existing PostgreSQL installation, database, and user.
4. Set resources, placement, and your public hostname.
5. Deploy, then open the dashboard to add your first website and copy the tracking script.

Deploy Umami