Deploy
Metabase self hosted.
With the Postgres application database Metabase recommends for production, running before you sign in.
Metabase is an open source business intelligence tool for building dashboards and asking questions of your existing databases in SQL or through its query builder. Selfhost.dev runs Metabase v0.63.15.3 with its own Postgres 16 application database on a 4 GB server we provision, route and secure for you. It costs $0.02/hr, about $15 a month in our EU locations, if you leave it running.
One click. The template deploys in about seven minutes.
no signup
+$5.00 added at signup · deployment choice preserved · no card
What is Metabase self hosted
The whole of Metabase.
On a server you control.
What it is. Metabase is an open source BI tool that sits in front of databases you already have and turns them into dashboards, saved questions and scheduled reports. Self hosting it means the application, its application database and every credential it holds run on a server you control rather than on Metabase's infrastructure.
Who it is for. Teams who want dashboards over their own data without a per-seat bill, and teams whose data cannot leave infrastructure they control. Metabase's open source edition has no user limit, so the cost of adding the tenth or the fiftieth person is zero.
When to use it. When you have a database worth querying and more than a couple of people who want to ask it questions. If you need row-level permissions, SSO or official embedded analytics, those are licensed features and self hosting the open source edition will not give them to you.
Metabase self hosted requirements
What Metabase needs, and what we already provide.
| What Metabase needs | This deployment |
|---|---|
| Runtime | JVM, in the official Metabase image |
| Application database | Postgres 16, bundled |
| Memory | 4 GB is the working size |
| Architecture | x86 or ARM, both supported |
| First boot | Runs the full application database migration suite |
| Outbound email | Not configured; add SMTP in Metabase's admin settings |
| Data sources | Any database Metabase can reach over the network |
| What Selfhost.dev provides | Detail |
|---|---|
| Locations | Six, across the EU, the US and Singapore |
| TLS | Let's Encrypt, per hostname, automatic |
| Custom domain | One customer domain per service |
| Backups | Optional, daily, whole VM, last 7 kept, +20% of the server price |
| Metrics | Server CPU and memory |
| Root access | Your SSH key, a root shell on your own server |
| MCP | The platform's deploy and management tools are available over MCP |
Specifications current as of September 2026.
What is in the Metabase deployment
Two containers. One click.
Two containers, both pinned, plus the volume that holds everything you build.
| Component | Version | What it does |
|---|---|---|
| Metabase | metabase/metabase:v0.63.15.3 | The application itself, running on the JVM |
| Application database | postgres:16-alpine | Holds every question, dashboard, collection and user account |
| Volume | metabase-postgresql-data | Survives a redeploy of the application container |
| Routing and TLS | Traefik with Let's Encrypt | HTTPS on a generated hostname, or on your domain |
The application database is Postgres, not H2
Metabase keeps its own application database, separate from whatever you are analysing. It is where your questions, dashboards, collections and accounts live, and losing it means losing all of your work. Run the stock container without configuring one and Metabase falls back to an embedded H2 file. Metabase's own documentation is direct about this: leave H2 in place and "the application database could get corrupted, and you could end up losing all of your questions, dashboards, collections, and other Metabase data." It names Postgres as "our preferred choice." This deployment wires Postgres 16 before the first boot. There is no H2 file, and no migration to schedule later.
Your data source credentials are encrypted
Every database you connect to Metabase means storing a hostname, a username and a password. Metabase can encrypt those with AES256 and SHA512, but only if MB_ENCRYPTION_SECRET_KEY is set. The stock image does not set it, so those credentials sit unencrypted in the application database. We set that key and persist it as a secret, so it survives a redeploy. That matters more than it sounds: Metabase's documentation warns that "you cannot decrypt connection details without this key", so a key that regenerates on restart would lock you out of every saved connection.
The version tag cannot move
Only Metabase's four-segment tags are immutable. The shorter v0.63.x form moves as patches land, which means a container restart can silently change the software under a running instance. We pin v0.63.15.3, so yours cannot.
Selfhost.dev pins both images to exact tags. A restart, a redeploy or a new template build never moves a running instance onto a different version.
What we set up for you
The settings that decide whether a container is usable or merely running.
| Metabase setting | Why it matters |
|---|---|
MB_DB_* pointed at the bundled Postgres 16 | The production application database Metabase recommends, in place before first boot |
MB_ENCRYPTION_SECRET_KEY, persisted | Metabase encrypts saved data source credentials instead of storing them in the clear |
MB_SITE_URL bound to the live hostname | Dashboard links, embeds and subscription emails re-derive correctly after you move to your own domain |
A /dev/urandom to /dev/random bind | The JVM does not stall waiting on entropy at boot |
| On every Selfhost.dev deployment | Why it matters |
|---|---|
| Default-deny inbound firewall, only 22, 80 and 443 open | Nothing else is reachable from the internet |
| Let's Encrypt certificate per hostname | HTTPS from the first request, renewed for you |
| A per-service DNS name for the database container | A generic postgres alias resolves across stacks; a unique one cannot |
| No template ever boots on a documented default password | And if credential seeding ever fails, the instance boots locked rather than open |
| Every image pinned to an exact immutable tag | No latest, anywhere |
| One VM per project, one customer per VM | No shared tenancy inside the box |
How to self host Metabase in four steps
From zero to live.
No server to set up.
Four steps. No Docker file, no Postgres to install, no certificate to renew.
1. Choose Metabase
Open Metabase in the Selfhost.dev template catalog. The brief lists the exact images and versions before you commit to anything.
2. Confirm size and location
The console pre-selects the cheapest server in stock that clears Metabase's memory floor in your nearest location, and tells you why it chose it. Change either one in place.
3. Launch
The template deploys in about seven minutes. Metabase starts its JVM and runs its application database migration on first boot, which is why this one takes longer than a small template.
4. Claim it and connect your data
Open the generated HTTPS URL and complete Metabase's first-run screen. The account you create is the administrator. Then add your first data source.
Ready when you are.
Deploy MetabaseWhat we run, and what you run
The honest split.
We manage the infrastructure. You own what happens inside Metabase. This is managed hosting, not managed analytics.
| Selfhost.dev | You |
|---|---|
| Provisions the server and the network | Connect your data sources |
| Deploys and routes the containers | Create accounts and set permissions |
| Issues and renews TLS certificates | Build questions, dashboards and collections |
| Runs a health check every 60 seconds | Configure SMTP if you want subscriptions and alerts |
| Takes daily whole-VM backups when you enable them | Decide when to move to a newer Metabase |
| Shows server CPU and memory metrics | Administer Metabase itself |
What a 4 GB server handles
What fits on the box.
Metabase counts as a heavy workload, which reserves 2 GB. After the 1.5 GB the host keeps for itself, a 4 GB server has 2,560 MB to allocate, so it fits Metabase plus one light application. An 8 GB server fits three heavy applications plus one light, and every project is capped at five workloads whatever its size.
We do not configure a concurrency ceiling on Metabase, so its limit is the server's memory and CPU rather than a number in a plan. What we will not do is publish a users-per-server figure: we have not load tested it, and a number we made up is worth less than this one.
Metabase self hosted cost
One rate, for the server.
The template, the bundled database, HTTPS, your domain and every user account are included.
| Server | Cores | RAM | Disk | Where | Rate | Monthly at 730 hrs |
|---|---|---|---|---|---|---|
cx23 (recommended) | 2 | 4 GB | 40 GB | EU | $0.02/hr | $15.18 |
cax11 (ARM) | 2 | 4 GB | 40 GB | EU | $0.02/hr | $16.35 |
cpx21 | 3 | 4 GB | 80 GB | EU | $0.04/hr | $25.70 |
cpx21 | 3 | 4 GB | 80 GB | Singapore | $0.07/hr | $51.39 |
cpx21 | 3 | 4 GB | 80 GB | US | $0.12/hr | $87.75 |
cx33 (one size up) | 4 | 8 GB | 80 GB | EU | $0.03/hr | $23.36 |
Monthly figures assume 730 hours. The console picks the cheapest server in stock that clears Metabase's memory floor in your nearest location, and tells you why it picked it.
| What else you pay for | Cost |
|---|---|
| The Metabase template | $0 |
| The bundled Postgres application database | $0 |
| HTTPS and a custom domain | $0 |
| Users, seats or accounts | $0 |
| Bandwidth | $0. Traffic is included |
| Backups | Optional, +20% of the server price |
No bandwidth charges
You pay for the server; traffic is included. That is worth checking against any usage-billed platform you are comparing, because a dashboard tool that people load all day is exactly the workload that makes metered egress expensive.
Prefer to see the full ladder? The pricing calculator prices every size in every location, with no signup.
What every Metabase deployment gets
Five things built into the platform.
- Every service is health-checked every 60 seconds.
- A deploy that stalls is retried automatically, not abandoned.
- A deploy is never reported done until the URL actually answers.
- Retrying a create never leaves you paying for two copies.
- Your version never moves on its own.
Typical deploy time for the Metabase template is about seven minutes once the server is up. That is the platform's own budget, not an estimate.
Not sure whether 4 GB is enough?
Tell us how many people will use Metabase and roughly how large the databases are, and we will send back the server size and what it costs in your region.
Metabase Cloud vs self hosted
Two bills with different shapes.
Metabase Cloud is priced per plan with a block of users included and a per-user rate above it. This is priced per server, and the number of people who log in does not appear on the bill.
| Plan | Monthly billing | Annual billing | Users included | Each extra user |
|---|---|---|---|---|
| Open Source | Free, self hosted | Unlimited | $0 | |
| Starter | $100/mo | $1,080/yr, or $90/mo | First 5 | $6/mo, or $65/yr |
| Pro | $575/mo | $6,210/yr, or $517.50/mo | First 10 | $12/mo, or $130/yr |
| Enterprise | Custom | From $20,000/yr | Custom | Custom |
Metabase Cloud list prices as published, checked 8 September 2026. Source: Metabase pricing.
| People using Metabase | Metabase Cloud Starter | Metabase self hosted here (4 GB, EU) |
|---|---|---|
| 5 | $100/mo | about $15/mo |
| 10 | $130/mo | about $15/mo |
| 25 | $220/mo | about $15/mo |
| 50 | $370/mo | about $15/mo |
The crossover is at the first user. Starter is $100 a month whether five people use it or one, and every person after the fifth adds $6. The server here is about $15 a month in our EU locations whether five people use it or fifty, because the open source edition has no user limit.
Versus a VPS you set up yourself
Same hardware. What the difference buys.
This runs on Hetzner, and so would you. Nobody should pretend the hardware is different. What differs is the eight hours between an empty Ubuntu box and a Metabase you would put in front of your team. Doing it yourself means installing Docker, standing up a Postgres application database rather than accepting the H2 default, generating and safely persisting an encryption key, writing a compose file that pins both images, putting a reverse proxy in front, getting a certificate and setting up its renewal, opening the right ports and closing the rest, and knowing that MB_SITE_URL needs to track your domain or your subscription emails will link to the wrong place.
Every one of those is a solved problem. It is solved here in the seven minutes the template takes to deploy, and it stays solved when you redeploy.
When Metabase Cloud is the better choice
One case where you should buy from Metabase instead.
Row and column permissions, SSO and SAML, usage analytics and official embedded analytics are licensed Metabase features. They are not in the open source edition at all, so no amount of hosting will produce them. If your requirements list includes any of those, buy a Metabase plan; that is a licensing decision, not a hosting one.
Metabase self hosted limitations
What this does not do.
- No outbound email until you configure it. Dashboard subscriptions and alerts stay quiet until you add an SMTP provider in Metabase's admin settings.
- The site URL is set for you, so it is read-only in the admin UI. We bind it to your live domain deliberately, so it always tracks where the instance actually answers rather than a value someone typed once.
- The first boot is the slow one. Metabase starts its JVM and runs the full application database migration suite, so a multi-minute starting phase on the very first launch is expected.
- One server, one copy. This is a single node with a single disk, plus whatever backups you enabled. There is no replica and no automatic failover.
Metabase backup and restore
One image covers all of it.
Every question, dashboard, collection and account lives in the Postgres application database on your server, in the metabase-postgresql-data volume. One image covers all of it, and a root shell gets you your own copy whenever you want it.
Backups
Optional, and when you switch them on Hetzner images the whole VM daily and keeps the last seven, for 20% of the server price. One image is every container, every database and every volume together, so a restore brings the whole project back.
Your own copy
Add your SSH key at create time or later, and you have a root shell on your own server. From there docker exec <db-container> pg_dump gives you a portable dump of the application database on your own schedule, to your own storage.
Leaving
That dump is a standard Postgres dump and Metabase reads it anywhere, so moving to another host or back to Metabase Cloud is a restore, not an export negotiation.
One thing to plan for
Backups live with the server, so if a project is deleted the images go with it. If your balance runs out we power the server off first, hold it for 24 hours and email you, and a top-up inside that window restarts the project rather than destroying it. Keep a card on file and keep your own dump, and none of this ever comes up.
Migrating from Metabase Cloud
Metabase documents the path.
Everything comes across: your questions, dashboards, people and settings.
How it works
You ask Metabase's support team for a snapshot of your application database, which arrives as an H2 file with a .mv.db extension. You then restore that snapshot into a Postgres application database using Metabase's own CLI command.
The prerequisite is already done here
That restore requires Postgres to be configured as your application database before you start. On a stock container that is the part you have to build first. On this deployment it is running before you log in.
Two things to check before you start
You cannot generate the snapshot yourself, so allow time for Metabase's team to produce it. And your self hosted major version has to match the Cloud version you are leaving, so confirm your Cloud instance is on the 0.63 line before you deploy.
Frequently asked questions
Is Metabase free to self host?
What database does self hosted Metabase need?
How much RAM does Metabase need?
Can Metabase connect to a database on another server?
Can I use my own domain?
Does Metabase send email from this deployment?
Can I move an existing Metabase Cloud instance here?
Will my Metabase version change on its own?
About Selfhost.dev
Selfhost.dev runs open source applications on dedicated servers you control. Projects deploy from a catalog of one-click templates onto a server in one of six locations, billed by the hour with no per-user fee. Managed Databases run PostgreSQL, MySQL, Redis and ClickHouse on AWS as a separate product.
Best for: Metabase, Grafana, Supabase and managed PostgreSQL, MySQL, Redis and ClickHouse.