Self-Host Metabase on Kubernetes

Metabase is open source business intelligence: dashboards, questions, and SQL exploration for people who do not write SQL. Self-hosting it on Kubernetes has one decision that matters more than the rest, which is where Metabase keeps its own metadata. This page covers that, the resource footprint, and the setup. Edka deploys it on a cluster in your own cloud account.

Use PostgreSQL, Not the Embedded H2 Database

Metabase ships with an embedded H2 database for its application metadata: your questions, dashboards, users, and saved database credentials. H2 is fine for evaluating Metabase on a laptop. On Kubernetes it is a liability.

The H2 file lives in the container. A pod restart on a fresh node loses every dashboard you built. Backing it up means backing up a file that Metabase is actively writing to, and migrating off H2 later is a documented but manual export.

Edka points Metabase at a PostgreSQL installation already running on your cluster from the start. You pick the instance, database, and user, and Edka resolves the connection and credentials from the corresponding Kubernetes Secret. Your dashboards then survive pod restarts, node failures, and cluster upgrades, and they are covered by the database backups you already run.

Resource Requirements

Setting	CPU	Memory
Request	500m	1Gi
Limit	2000m	2Gi

Metabase runs on the JVM and is the heaviest of the analytics apps in the Edka catalogue at rest. The 1Gi memory request is a floor, not a suggestion. Query concurrency drives the rest: a dashboard with a dozen cards fires a dozen queries at once.

Deployed as a single replica on port 3000. A CPX31 node (4 vCPU, 8GB) is a comfortable home once PostgreSQL shares the cluster. See the Hetzner instance types table.

What Edka Provisions

Edka installs Metabase and wires it into your cluster:

• Metabase application. A single replica deployment exposing the UI on port 3000.
• PostgreSQL application database. An existing PostgreSQL installation on your cluster holds Metabase’s own metadata. You select the instance, database, and user during setup.
• Encryption at rest. A stable encryption secret key is generated so Metabase can encrypt the credentials of the databases it connects to.
• Gateway access. When enabled, Edka publishes Metabase through an Envoy Gateway traffic class with an HTTPRoute for your hostname.

Configuration Options

• Database. The PostgreSQL installation, database, and login user for Metabase’s application data. SSL/TLS to PostgreSQL is configurable.
• Resources. CPU and memory requests and limits.
• Placement. Pin pods to a node pool, with automatic tolerations for that pool’s taints.
• Access. Expose the dashboard through a Gateway traffic class on a custom hostname, which also sets the Metabase site URL.
• Anonymous tracking. Disabled by default. Opt in to share usage statistics with Metabase.
• Auto-update. Let the Edka agent apply newer chart and image versions using a patch, minor, major, or custom version policy.

Deploy Metabase

1. Click “Deploy Metabase” below.
2. Select the PostgreSQL installation, database, and user Metabase should use for its own metadata.
3. Adjust resources, placement, and access settings.
4. Choose a hostname to expose the dashboard, or keep it internal.
5. Deploy, then open Metabase and complete the initial admin setup.

Deploy Metabase