Metabase: one repository, two licenses, and a first page that sells the cloud

One tree builds the AGPL edition and the commercial ones

The license section says this repository contains the source for both the open source edition, released under the AGPL, and the commercial editions, released under the Metabase Commercial Software License, with details in LICENSE.txt. Three more license files sit beside it: LICENSE-AGPL.txt, LICENSE-EMBEDDING.txt, and LICENSE-MCL.txt, so the embedding terms are separated from the rest. The build is where the boundary is drawn, because the Dockerfile takes an edition argument defaulting to oss.

ARG MB_EDITION=oss

Consequence: the same source produces a permissibly reviewable product and a commercial one, and which you got is decided by a build flag rather than by the repository you cloned. The metadata will not help you. The repository license field is recorded as NOASSERTION and the frontend manifest declares its license as private at version 0.0.0, so a scan of your dependency tree reports a business intelligence tool with no license, and you have to read the files.

The first thing the page offers is a hosted trial

The get started section points at a free trial of Metabase Cloud and lists what the hosted version includes: expert support, backups, upgrades, an SMTP server, an SSL certificate, and SoC2 Type 2 security auditing. It then says you can switch to self hosting at any time, or vice versa, with links to a cloud versus self hosting comparison and to the installation guide. Consequence: the fastest path to evaluating Metabase puts your data in someone else's instance, and the reassurance that the door opens both ways is a sentence rather than a documented migration. Nothing on this page describes what an export from the hosted product looks like, or what happens to the questions, dashboards, and alerts you built while you were evaluating it, so if the switch is going to happen, ask for that in writing before you start.

No install command, and a build that needs five runtimes

The installation section says Metabase can be run just about anywhere and links the guides, which is as far as the page goes. The Dockerfile is where the real requirements show up. The builder stage starts from node:22-bullseye, installs a JDK from the Adoptium packages, fetches a pinned Clojure installer, pulls uv from astral.sh, installs bun globally, and runs bun install with a frozen lockfile before calling bin/build.sh with a version argument. Consequence: building from source is a multi runtime exercise, and the claim about running anywhere is about deploying the jar rather than reproducing it. If your requirement is reproducible builds, this page is the wrong document and the installation guides are where the actual support matrix lives.

bun with a frozen lockfile and two trusted install scripts

The frontend manifest declares engines for node at 22 or newer and bun at 1.0.0 or newer, marks itself private at version 0.0.0, and lists exactly two trusted dependencies, cypress and esbuild, which are the packages allowed to run code during installation.

RUN bun install --frozen-lockfile

The repository carries bun.lock and bunfig.toml at the top level rather than a package-lock file, which is consistent with the build. Consequence: the frontend build assumes one package manager and a lockfile it refuses to update silently, so a contributor who reaches for npm install gets a dependency tree the project never resolves, and the diff between the two is invisible until something behaves differently in CI. It also means the two trusted postinstall scripts are the surface to look at if you are auditing what a build of this repository executes.

The browser bundle carries analytics and an MCP surface

The dependency list is where the product surface shows through. There is a graph layout library, @dagrejs/dagre, the full CodeMirror editor set with language modes for SQL, Python, JSON, HTML, and JavaScript, a component library built on Mantine, a Google sign in package, a Model Context Protocol extension package at @modelcontextprotocol/ext-apps, a first party tracker at @metabase/track, and Snowplow's browser tracker. Consequence: the front end you ship to a self hosted instance includes two analytics trackers and an integration surface designed for agent tooling, and nothing on this page explains how to turn any of it off. If your environment has a policy about outbound telemetry, resolve that from the source and the configuration reference rather than assuming a self hosted build is inert, because the same code serves both editions.

Local development expects cloud credentials in a copied file

The development environment template is organised as a configuration reference, with a section for global context holding a GitHub token, AWS access keys, and Docker Hub credentials, and it can be populated either manually with cp .env.example .env or from a password manager with an inject command. It suggests auto loading the file through mise or direnv, and it carries a warning that the same variable must not be exported multiple times in different contexts. Consequence: a contributor needs tokens for three external services before the local stack is happy, and the last warning is there because the failure it describes is invisible, since the value that wins depends on which context loaded last. A devcontainer directory sits beside all of this, so the intended path is a reproducible container, not a bare checkout.

Link, spelling, and module boundary checks live in the tree

The quality tooling is unusually visible. There is a link checker configuration with its own ignore file, a markdown link check config, spelling dictionaries and ignores for codespell, a pre-commit config, husky hooks, Clojure formatting and linting configs, and a dependency cruiser file paired with a module boundaries ESLint config, alongside storybook and typedoc setups. Consequence: two things follow for a contributor. Documentation rot in this repository is caught mechanically, and a frontend import that crosses a declared module boundary fails lint even when it compiles. The flip side is that the checks only run if the hooks are installed, so on a fresh clone the first person to find out is CI, which is a slower and less pleasant way to learn the boundary rules.

Embedding is where the license files diverge

The feature list is broad, with a question builder for people who do not know SQL, a SQL editor for those who do, dashboards, documents with comments, alerts and subscriptions to email, Slack, or a webhook, a library for curation, and Git backed remote sync so your work is versioned. The embedding story goes further, offering components for charts, dashboards, a data browser, and AI chat, or an entire Metabase inside your own application, with granular permissions that work whether customer data sits in one database or each customer gets their own. Consequence: embedding is the feature set where the AGPL terms, the commercial terms, and the separate embedding license all bear on the same decision, which is exactly why the repository keeps LICENSE-EMBEDDING.txt apart. If your plan involves putting dashboards in a product you sell, read those three files before you design around it, not after.

Editorial conclusion

Metabase suits a team that wants non technical colleagues asking their own questions and can live with the edition boundary, and it is a reasonable default when SQL must not be a prerequisite. Read the license before you pick an edition, because the repository ships AGPL, commercial, and embedding terms in separate files and the metadata will not tell you which one applies. If you self host, plan the toolchain for building from source as a separate problem from running the jar, keep the edition you were given in writing, and check what the browser dependencies in the frontend send before you point it at production data.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes