Self-Hosting Metabase: Dashboards on Your Own Servers

The open-source edition of Metabase can be run free of charge on your own servers. Dashboards, queries and credentials then stay within your own infrastructure. Self-hosting does require some planning, though, especially for the database, upgrades and backups. This article describes what to watch out for technically.

Which edition can be self-hosted?

Metabase is developed by the US company Metabase, Inc. The open-source edition is licensed under the AGPL and can be self-hosted without licence fees. The paid features of the Pro and Enterprise editions, such as row-level permissions or single sign-on, can also be self-hosted. They use a separate Docker image and a licence token (as of November 2026).

As an alternative to Docker, Metabase is available as a JAR file that runs on a Java runtime. In practice, Docker is usually easier to operate and upgrade.

Architecture at a glance

A self-hosted Metabase consists of three building blocks:

1. Metabase application: runs in a container and listens on port 3000 by default.
2. Application database: stores user accounts, questions, dashboards, collections and settings.
3. Data sources: your actual databases or data warehouses that Metabase queries.

The distinction between points 2 and 3 matters. The application database holds your users' work, not your business data. If it is lost, all dashboards are gone, even though the data sources remain unchanged.

A reverse proxy such as Nginx, Caddy or Traefik should sit in front. It accepts requests over HTTPS, handles the TLS certificate and forwards traffic to the Metabase container.

Choosing the application database

Without further configuration, Metabase uses an embedded H2 database stored as a file. The Metabase documentation explicitly advises against using H2 in production. With Docker there is an additional risk: if the file lives inside the container, it is lost when the container is removed.

For production, Metabase recommends PostgreSQL. MySQL and MariaDB are also supported, but PostgreSQL is the preferred choice. The database must be created beforehand, with UTF-8 encoding for PostgreSQL. Metabase creates the tables itself on first start.

The connection is configured through environment variables:

MB_DB_TYPE=postgres
MB_DB_HOST=db.internal.example
MB_DB_PORT=5432
MB_DB_DBNAME=metabase
MB_DB_USER=metabase
MB_DB_PASS=SECRET_PASSWORD

Alternatively, MB_DB_CONNECTION_URI accepts a full JDBC connection string, for example to set SSL options. Do not store passwords in plain text in Compose files; the documentation recommends Docker Secrets for this.

Start with PostgreSQL from day one. According to the documentation, migrating away from H2 later is only partially supported.

Running with Docker

Docker Compose works well in practice, with one service for Metabase and one for PostgreSQL unless you use a separate database server. Keep a few points in mind:

• Pin the version: use a specific version tag instead of latest. That way you decide when an upgrade happens.
• Health check: Metabase provides an endpoint at /api/health that Docker or your monitoring can query.
• Time zone: JAVA_TIMEZONE sets the application's time zone.
• Do not copy the sample configuration blindly: Metabase states that the Compose examples in its documentation are not intended for production.

Securing access to data sources

Metabase needs credentials for every data source. Create dedicated database users with read-only access to the required schemas or tables. That way, even a faulty query cannot change any data.

Also avoid exposing Metabase to the internet unprotected if that is not necessary. Restricting access to the company network or a VPN reduces the attack surface considerably. Keep the number of administrator accounts small as well.

Upgrading safely

Metabase releases new versions regularly. When a new version starts, Metabase automatically updates the schema of the application database (migration). This leads to a clear process:

1. Read the release notes.
2. Back up the application database.
3. Stop the running container.
4. Pull the new image with a specific version tag.
5. Start a new container pointing to the same application database and let the migration complete.
6. Spot-check important dashboards.

Rolling back to an older version after a major upgrade is not straightforward. The documentation recommends restoring from a backup as the preferred approach. If several Metabase instances run in parallel, scale down to a single instance before upgrading and do not interrupt the process during migration, as this can corrupt the application database.

Planning backups

The most important thing is backing up the application database. For PostgreSQL, Metabase says a dump of the Metabase database is sufficient, for example with pg_dump. Schedule this backup automatically, such as daily, and store the files off the server.

Test restores regularly. A backup that has never been restored only offers apparent safety. Your actual data sources are independent of this and need their own backup strategy.

Checklist for self-hosting

1. Choose the edition: Open Source, or Pro/Enterprise with a licence token.
2. Create a PostgreSQL database with UTF-8 for the application data.
3. Run Metabase with Docker Compose and a pinned version tag.
4. Manage credentials with Docker Secrets or a comparable solution.
5. Set up a reverse proxy with HTTPS and restrict access to the company network or VPN.
6. Create read-only database users for all data sources.
7. Automate daily backups of the application database and test restores.
8. Run upgrades with a prior backup and a short check afterwards.

How Simplify Data can help

Simplify Data sets up Metabase on your own servers for companies in Kiel, Schleswig-Holstein, Hamburg and remotely across Germany and supports you with operations, upgrades and backups. Find out more on our Metabase page.

Sources

• Metabase Docs: Running Metabase on Docker
• Metabase Docs: Configuring the application database
• Metabase Docs: Upgrading Metabase
• Metabase Docs: Backing up Metabase application data