Metabase embedding options: which method your project can use on the free edition
A team building customer-facing analytics on Metabase should first decide whether its end users will sign in to Metabase or only view charts inside an application it already runs. Guest embedding runs on the open-source edition, while SSO-based modular and full app embedding need the Pro or Enterprise plan. Guest embedding is enough when external viewers see fixed dashboards or charts, every viewer may see the same data after your application applies its filters, and nobody needs an individual Metabase account. It can also work on a tight budget if your team accepts that Metabase branding stays visible, because Metabase's pricing page lists embedding without Metabase branding as a paid Pro or Enterprise feature. Your application server handles authentication and tenant logic, so the security design of the embed sits with your team.
Modular and full app embedding change that picture because Metabase learns who each viewer is through your identity provider. Modular embedding places individual charts or dashboards inside your product, while full app embedding gives users a complete Metabase interface. Choose either when viewers must see different rows or columns, when internal staff and customers share one governed environment, or when users need to explore data on their own. Metabase's pricing page places row and column level permissions and multi-tenant data segregation on Pro and Enterprise, and its people and groups documentation lists JWT, OIDC and SAML sign-in as Pro or Enterprise features. Before you commit, confirm with Metabase which embedding features each plan includes for the version you plan to deploy.
Public links and static embedding are the two options that look simpler, and they need the most caution. A public link lets anyone who holds the URL view the content, so use it only for data that may be published openly. Static embedding is deprecated, so do not start a new project on it, and confirm its current status in Metabase's embedding introduction before you plan a migration. Before choosing a method, check four things: which data each viewer may see, whether branding must be removed, how many internal editors need accounts (Pro on Metabase's pricing page includes 10 users, with extra users priced separately), and whether your identity provider already supports the sign-in method Metabase requires.
How guest, modular and full app embedding differ in practice
Guest embeds suit customer-facing analytics where viewers should never log in to your BI tool. Your application signs a JWT that names the dashboard or question and any parameters, and Metabase renders it inside your page for an anonymous viewer. The end user is your customer or partner, and that person has no Metabase identity.
- End user: external customers or partners who see only the content you signed for.
- Authentication: your server signs a token with the embedding secret, so Metabase trusts the request without a user account.
- What they can do: view the embedded dashboard or question and use the filters you expose, with no open-ended exploration.
- Edition: available on the open-source edition, but removing Metabase branding requires Pro or Enterprise.
- Limit: tenant isolation depends entirely on the parameters your server signs, so test it yourself with separate customer accounts.
Check which filters you expose, where the signing key is stored, and whether your branding requirement pushes you to Pro.
Modular embedding places individual Metabase components, such as charts, dashboards or question views, inside pages your product already has. Users sign in through your identity provider, and Metabase applies the permissions tied to their groups, so each person sees data that matches their role. The end user is an authenticated member of your product or workforce, not an anonymous visitor.
- End user: logged-in users of your application, each mapped to a Metabase identity through SSO.
- Authentication: SSO through JWT, with group and attribute mapping, which Metabase lists as a Pro or Enterprise feature.
- What they can do: work inside the components you place, bounded by the row and column permissions set in Metabase.
- Edition: requires Pro or Enterprise, because the open-source edition does not include SSO.
- Cost driver: confirm with Metabase how embedded end users count toward plan seats, since per-user pricing shapes the total.
Confirm your identity provider flow and how group changes in the identity provider reach Metabase permissions.
Full app embedding brings the complete Metabase interface into your application, including browsing collections and building new questions. It fits products where users need to explore data themselves and go beyond fixed views. The end user is an authenticated person with a Metabase identity, often business or operations staff who work with data every day.
- End user: authenticated users who need self-service exploration inside your product.
- Authentication: SSO as in modular embedding, so each session maps to a Metabase user with its own permissions.
- What they can do: browse collections, build questions and use the query builder, limited by the data permissions you set.
- Edition: requires Pro or Enterprise, with the same SSO and permission features that modular embedding uses.
- Exposure: a larger surface than fixed embeds, so review data permissions, row and column rules and audit logging before go-live.
Ask what self-service exploration your users actually need, and test the permission model with a non-admin account before rollout.
A public link produces a URL that anyone holding it can open to see a saved question or dashboard, with no login. It is quick for sharing non-sensitive content, but the link itself is the only control. The end user is anyone who receives the URL, including people you never intended to see the data.
- End user: any person with the link, including forwarded copies and URLs captured in logs or browser history.
- Authentication: none, because possession of the link is the only credential.
- What they can do: view the shared content as saved, with no interactive exploration beyond that view.
- Edition: confirm availability and any plan requirement on the Metabase pricing page before relying on it.
- Risk: revoking access means changing the sharing setting in Metabase, and copies already sent to others remain usable until then.
Keep customer and regulated data out of public links, and confirm the sharing settings in your environment before any rollout.
Static embedding is the older method that embeds a signed iframe for a fixed question or dashboard, with parameters locked by the signature. Metabase has deprecated it, so new projects should start with guest embedding, and existing implementations should plan a migration. The end user is the same anonymous viewer as in guest embeds, but the control model is older and less flexible.
- Status: deprecated, so confirm the current status and any removal timing in the embedding documentation before starting a new build.
- Authentication: a signed URL built with a secret key, which works on similar principles to guest embeds.
- What they can do: view a fixed embed with locked parameters, with less room for filter changes than guest embeds allow.
- Edition: confirm the edition requirement in the docs, and do not assume support carries over from guest embeds.
- Migration: existing static embeds need rebuilding as guest embeds, including signing code and iframe changes, so scope that effort early.
Inventory your existing static embeds and ask Metabase for the current deprecation timeline before you plan the migration.
Which embedding features each Metabase edition includes
This table places the four Metabase editions against the embedding capabilities a customer-facing project usually needs. Read the Open Source and Starter column as the ceiling for building without a paid plan, and treat cells marked as points to confirm as questions for Metabase before you commit. The main takeaway is that JWT, OIDC and SAML sign-in, row and column permissions, multi-tenant segregation and unbranded embedding all sit on Pro or Enterprise.
| Capability | Open Source and Starter | Pro | Enterprise |
|---|---|---|---|
| Published starting price | Open Source is free; Starter is $100 per month, or $90 per month billed yearly, with 5 users included | $575 per month, or $517.50 per month billed yearly, with 10 users included (Metabase pricing page) | Quoted, starting at $20,000 per year (Metabase pricing page) |
| Guest embedding | Works on the open-source edition; confirm current terms with Metabase | Included; confirm any Pro-specific limits with Metabase | Included; confirm any Enterprise-specific terms with Metabase |
| Modular and full app embedding | Advanced embedding features are listed for Pro and Enterprise only; confirm availability with Metabase | Advanced embedding features are included per the pricing page; confirm which methods they cover | Advanced embedding features are included per the pricing page; confirm which methods they cover |
| SSO for embedded sign-in (JWT, OIDC, SAML) | Google sign-in and LDAP only; JWT, OIDC and SAML are not available | JWT, OIDC and SAML are available, with documented SAML setups for Auth0, Entra ID, Google, Keycloak and Okta | SSO is included per the pricing page; confirm any methods beyond Pro with Metabase |
| Row and column level permissions | Not included | Included | Included |
| Multi-tenant data segregation | Not included | Included; confirm how tenant boundaries apply to embedded users | Included; confirm how tenant boundaries apply to embedded users |
| Embedding without Metabase branding | Not included | Included | Included |
| SCIM provisioning and advanced LDAP group sync | Not included | Included | Included; confirm with Metabase |
| Usage analytics and auditing | Not included | Included | Included |
What licensing, support and upgrade terms mean for a customer-facing product
Metabase uses two license families and two support tracks, and each one changes how an embedded product must be built, tested and upgraded. Read these terms together before you choose an embedding method, because the license decides what you may ship and the support window decides how often you must upgrade.
AGPL open-source edition
The open-source edition of Metabase is licensed under the AGPL, and its source outside the top-level enterprise directory follows that license. The AGPL requires source sharing for modified versions, including modified versions that users reach over a network, so an embedded product built on a changed fork can trigger those obligations. Ask counsel how the license applies to your code and whether an unmodified build changes your position.
Metabase Commercial Software License scope
The commercial editions ship under the Metabase Commercial Software License in the LICENSE-MCL.txt file, while the open-source edition ships under the AGPL. Advanced embedding features sit on the paid Pro and Enterprise plans, so a product that depends on them needs a commercial agreement in addition to the open-source download. Ask Metabase which terms cover your embedding use, which version you deploy, and whether you may redistribute the JAR inside your own product.
LTS support window
Metabase LTS versions are supported for 14 months, and every release receives bug fixes and security updates until its end-of-life date. Metabase 64 is an LTS release published on September 16, 2026, with end of life on December 1, 2027. For a customer-facing environment, choose the LTS line so the support window outlasts your planned release cycle, and put the end-of-life date on your roadmap.
Non-LTS release window
Non-LTS versions usually reach end of life after about 2 months, which leaves a short window to test and roll out a release before support ends. Metabase 65 was released on October 12, 2026, so check its support type on the version support page before you deploy it to customers. A product that follows each non-LTS release needs a standing upgrade routine, and the team must confirm it can sustain that pace before committing.
Upgrade steps before each release
Metabase runs application database migrations automatically during an upgrade, so back up the application database first. The upgrade docs recommend reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading release by release when starting from a version older than 40. Schedule a maintenance window that covers the embedding host and any apps that call it, and rehearse the upgrade on a copy of the application database.
What each embedding path costs at published Metabase prices
This table separates the Metabase subscription from the one-time and recurring work each embedding path needs. Read the subscription row for published plan prices, then the work rows to see what a quote must cover. DeployOpen does not publish prices, so integration, identity setup and testing are quoted from a written scope.
| Cost component | Open Source with guest embedding | Pro | Enterprise |
|---|---|---|---|
| Metabase subscription | Free under the AGPL open-source edition (Metabase pricing page) | $575 per month, or $517.50 per month billed yearly (Metabase pricing page) | From $20,000 per year, priced by quote (Metabase pricing page) |
| Users included and extra users | No per-user fee listed for this edition on the pricing page | 10 users included; $12 per additional user per month (Metabase pricing page) | Seat terms set in the Enterprise quote |
| Identity setup for SSO embedding | Not required for guest embedding; SSO embedding needs a paid plan | SSO is included in the plan; setup labor is one-time and quoted separately | SSO is included in the plan; setup labor is one-time and quoted separately |
| Hosting and operations | Recurring compute, database and backup costs in your own environment; Metabase does not price these | Same recurring infrastructure costs, plus the subscription | Same recurring infrastructure costs, plus the subscription and any support terms in the quote |
| Integration and front-end work | One-time work to build guest embed URLs and the host application, quoted from written scope | One-time work to build SSO, modular or full app embedding, quoted from written scope | One-time work for the same scope, plus any procurement or air-gapped deployment items in the quote |
| Testing and acceptance | One-time test plan for tenant isolation and embed security, scoped in writing | One-time testing of permissions, SSO flows and embed behavior, scoped in writing | Same testing scope, sized to the enterprise architecture and controls |
| Upgrades and maintenance | Recurring time to test and apply each Metabase release, including database backups first | Recurring upgrade cycle, plus any paid retainer for ongoing support | Recurring upgrade cycle, with support windows defined in the contract |
| What to ask for in a quote | Itemized one-time build and test effort, plus recurring run and upgrade tasks | Subscription terms, user count, one-time SSO and embed work, and recurring run tasks | Written enterprise price, support scope, one-time integration and any deployment requirements |
Moving from guest embedding to SSO-based embedding
This sequence takes a team that started on the open-source edition with guest embeds and moves it to SSO-based modular or full app embedding on a paid plan, with a verified identity model, a safe upgrade path and a clean application database.
Confirm the identity provider and user model
Before buying anything, the identity team documents which identity provider will sign in embedded users, which attributes it passes (such as tenant, region or department), and how groups map to Metabase permissions. Metabase's people and groups documentation lists JWT, OIDC, SAML and SCIM as paid options, so confirm that your provider's chosen method is supported on Pro or Enterprise. The step is done when the team has a written mapping from identity claims to Metabase groups and collections, reviewed by the identity owner.
Map guest embeds to the future data model
Inventory every guest embed in use, noting which dashboards, filters and signed parameters they rely on and which customer or tenant boundary each one enforces today. Guest embeds work on the open-source edition, but row and column level permissions and multi-tenant data segregation are paid features, so the team should mark which boundaries will move from signed parameters to Metabase permissions. The output is a table of embeds with their target embedding method, which the product owner and a security reviewer sign off.
Plan the Pro or Enterprise subscription
Ask Metabase for a quote that matches the number of internal users, the embedding model and whether support, procurement or air-gapped deployment is needed. Metabase's pricing page places advanced embedding features on Pro and Enterprise, with Pro listed at $575 per month and 10 users included, and Enterprise by quote from $20,000 per year. Budget for the recurring license, and confirm with Metabase whether embedded end users are counted in the user model. The step closes when a signed order form matches the mapped identity model.
Move the application database off H2
If the instance still uses the embedded H2 application database, migrate it before production embedding goes live. Metabase recommends PostgreSQL for production and documents a one-time load-from-h2 command that must run with the same Metabase version that last updated the H2 file. Verify the migrated instance by comparing questions, dashboards and permission groups against the source. The step is complete when the production instance reads from the new database and the H2 file is archived.
Back up the application database and test the upgrade
Take a verified backup of the application database before changing the Metabase version, since upgrades run application database migrations automatically. Rehearse the upgrade on a copy of production, and where a major upgrade is planned, reduce the cluster to a single node because of the migration lock that the upgrade guidance describes. Confirm the restore procedure works on the copy. The step is done when the rehearsal completes and the restore has been tested.
Upgrade release by release to the paid line
Move the instance forward one release at a time, as the upgrade documentation recommends for versions older than 40, and check the version support page for the target line. Metabase 64 is an LTS release with end of life on 1 December 2027, and Metabase 65 followed on 12 October 2026, so choose the release line that fits your support window. After each step, confirm that dashboards, guest embeds and scheduled jobs still behave as expected. The step is done when the target version runs in staging with all embeds passing checks.
Enable SSO and switch embeds to modular or full app
Activate the chosen SSO method (JWT, OIDC, SAML or SCIM) on the paid plan, then rebuild each embed as modular or full app embedding using the identity mapping from the first step. Test sign-in with a test identity for each tenant, and confirm that row and column permissions block cross-tenant access. Retire the guest embed only after the new path passes these tests. The output is a signed test record for each tenant and a retirement log for the old guest embeds.
Retire guest embeds and document the final state
Remove the old guest embed keys and signed parameter code once every customer-facing view has moved, then document the final architecture, plan, identity configuration and upgrade routine. Keep the backup and migration records with the runbook so the next upgrade starts from a known state. The step is complete when a reviewer confirms that no guest embed remains in production and the runbook matches the running system.
Questions teams ask before choosing an embedding method
Is guest embedding enough for customer-facing analytics in Metabase?
It can be, when every viewer sees the same dashboards with fixed filters and no per-customer data rules. The page scope places guest embeds on the open-source edition, so the license cost is zero and the work is mainly hosting, setup and testing. The limits matter, though. Guest embeds do not give you identity federation through SSO, and row and column level permissions, multi-tenant data segregation and removal of Metabase branding sit in the paid Pro and Enterprise plans on Metabase's pricing page. If each customer must see only its own rows, or if customers log in with their own identities, plan for a paid tier. Confirm the current guest embed terms on the pricing page before you commit to this path.
What does Pro or Enterprise add for embedding in Metabase?
Metabase's pricing page says advanced embedding features are available on the Pro and Enterprise plans, including the SSO-based modular and full app embedding paths. Pro is listed at $575 per month, or $517.50 per month billed yearly, with 10 users included and additional users at $12 per month. Enterprise is priced by quote starting at $20,000 per year. The same paid tiers also list embedding without Metabase branding, row and column permissions, multi-tenant data segregation and usage analytics with auditing. Which tier fits depends on whether you need per-customer security boundaries and identity federation. Ask Metabase how embedded end users count toward the plan's user terms, since that can change the monthly total.
How much effort do SSO and modular embedding take?
Most of the effort sits in identity design, not in switching a Metabase setting. Modular embedding places individual charts or dashboards inside your application, while full app embedding gives customers a larger Metabase experience inside your product. Both depend on your application passing a trusted identity to Metabase, so your team must map customer accounts, groups and attributes to Metabase permissions. Metabase's people and groups documentation covers JWT, OIDC and SAML setups, with documented examples for Auth0, Entra ID, Google, Keycloak and Okta, and those methods require Pro or Enterprise. Effort rises with the number of tenants, the complexity of group rules and the number of attribute syncs. Before you estimate, ask for an inventory of your identity providers and a list of test cases for each customer type.
Can our team set up Metabase embedding without outside help?
Yes, if you have engineers who can handle web authentication, token signing, database administration and upgrades. Metabase's embedding and admin documentation covers the setup, and the open-source edition lets you prototype a guest embed before you buy a paid plan. Teams without this mix usually stall on identity design, tenant isolation testing and the upgrade routine. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, under fixed-scope written agreements, and offers retainers for ongoing support and upgrades. Outside help is worth weighing when the security review or compliance evidence must be ready by a set date, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications.
How long does Metabase embedding setup take for each scope?
No supplied figure gives a setup duration for any embedding path, so treat any number you hear as unverified until the scope is written down. Duration follows the path you choose. A guest embed of a few fixed dashboards is the smallest job. Modular embedding adds identity mapping and permission testing, and full app embedding adds navigation, branding and tenant design on top of that. Other drivers include the number of data sources, the count of distinct customer permission models, and whether the Metabase application database already runs on PostgreSQL. Ask any implementation partner for a milestone plan with an acceptance test for each embedding path, and compare plans on the same list of tenants and identity providers.
What does the customer team need to provide for embedding?
Expect to supply the data source connections and read-only accounts, the identity provider or token issuer, a sample of customer account and group structures, and the hosting target where Metabase will run. You also need named owners for the application database, backups and upgrades. Metabase recommends PostgreSQL as the application database for production, while the embedded H2 database is meant for demos. Its upgrade guidance asks you to back up the application database first, reduce a cluster to a single node for major upgrades because of a migration lock, and upgrade release by release from versions older than 40. Decide early who holds Metabase user administration on a Pro or Enterprise plan, because that person approves every identity change.
Should we still use static embedding in Metabase?
Not for new work. The topic scope treats static embedding as deprecated, so build new customer-facing analytics on guest, modular or full app embedding, and plan a migration for any existing static embeds. Confirm the deprecation status, and any removal date, in Metabase's embedding documentation before you set a migration schedule, because no supplied date fixes it. Inventory every existing static embed with its owner, then replace each one under the same security review as new work. Also check your Metabase version. Metabase 64 is an LTS release with end of life on December 1, 2027, and Metabase 65 was released on October 12, 2026, so plan the migration around the upgrade window you will actually use. Metabase embedding introduction lists the current paths.
When the paid Metabase edition is worth the cost
The open-source edition is worth keeping when the embed is internal or low risk. A dashboard shown to your own finance or operations staff, where every viewer may see the same data, is a good fit for a guest embed on the free edition. Stay on Open Source when the audience is small, the data does not need separating by customer, and your team accepts the Metabase branding on the embedded content. Before you commit, check the current embedding lines on the Metabase pricing page, because branding and permissions are where the plans differ.
Pro becomes worth paying for when your application, not a shared guest credential, must decide what each viewer sees. Row and column level permissions, SSO, multi-tenant data segregation, and embedding without Metabase branding are all listed as Pro or Enterprise features, and JWT and SAML sign-in also require Pro or Enterprise. The list price is $575 per month, or $517.50 per month billed yearly, with 10 users included and $12 per additional user per month. For a customer-facing product, the seat count and the identity setup often matter as much as the embed itself, so price both before you choose.
Enterprise, priced by quote from $20,000 per year, makes sense when procurement, support terms or deployment constraints drive the decision more than embedding features do. Ask Metabase whether embedded end users count toward licensed seats or are priced separately, which identity setup it supports for your provider, whether your tenancy model needs Enterprise, and what support response terms apply. Plan the recurring work on any plan. Metabase LTS releases are supported for 14 months, and Metabase's version support page is the place to track end-of-life dates for the version you run.
How DeployOpen scopes an embedding project
The sequence turns a Metabase embedding idea into a written scope that names the edition, embedding method, identity integration and hosting before any build work starts. Each step ends with a document or check the client can review and keep.
Confirm the customer-facing use case
DeployOpen starts with a discovery session where your product, data and product owners describe who sees the analytics, what they can do inside the page and whether any viewer should ever edit a question. DeployOpen maps those answers to a candidate method: guest embedding for read-only views, modular embedding for parts of the Metabase interface, or full app embedding for a complete analytics area. The step closes with a one-page summary of the viewer types and interaction needs, which your product owner signs off before scoping continues.
Confirm the Metabase edition and plan
Next, DeployOpen checks which embedding method needs which plan. Confirm the plan against Metabase's current pricing page, since advanced embedding features sit on Pro and Enterprise, and guest embedding can run on the open-source edition. The written scope records the edition, the user count you expect, and any Enterprise needs such as procurement or air-gapped deployment. Your procurement team should ask Metabase for a quote for any plan above Open Source, because Enterprise pricing is set by quote.
Define the identity integration
DeployOpen documents how your application authenticates viewers and how Metabase will recognize them. For SSO-based modular and full app embedding, this means choosing the signing approach, the attributes passed for row and column permissions, and how groups map to Metabase groups. Identity owners at your organization review the mapping table and confirm which identity provider remains the source of truth. The output is a signed-off identity design, plus a list of any settings you must confirm directly with Metabase for your version.
Write the scope and hosting plan
DeployOpen writes the fixed scope in a document covering the edition, embedding method, identity integration, hosting inside your cloud account, data center or air-gapped network, the application database choice, backup and upgrade routines, testing and documentation deliverables. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that scope. Ask for line items that separate one-time build work from recurring support, so you can compare the quote with the plan price.
Build, harden and test the embed
Engineers deploy Metabase in your environment, configure the application database, implement the embedding and identity flow, and apply the agreed permissions. Testing covers each viewer type, attempts to view data outside a viewer's permissions, and the behavior of the embed after an upgrade in a staging copy. The step closes with a test report listing each scenario, its result and any open issue, which your team reviews before anything reaches production.
Document and hand over the system
DeployOpen delivers the runbook, architecture notes, identity mapping, backup and restore procedure, and the upgrade routine that matches the Metabase version support policy. Your engineers run a supervised handover session and operate a production change themselves while DeployOpen observes. The handover is complete when your team can rebuild the environment from the documentation and has signed off the acceptance checklist. DeployOpen prepares this evidence for compliance reviews, but it does not issue audit reports or certifications; independent auditors and certification bodies do that.
Decide on optional retainer support
After handover, you choose whether to keep ongoing support through a retainer for upgrades, monitoring, security patching and continuous testing, or to run the platform in-house. The retainer scope is written separately and recurs on its own terms. Ask for the response expectations, the upgrade cadence and what counts as in-scope work before you sign, so the recurring cost is clear alongside Metabase's own plan fees.
How DeployOpen supports Metabase embedding in your infrastructure
DeployOpen plans, implements, integrates, documents and supports self-hosted Metabase inside your own cloud accounts, data centers or air-gapped networks. We start by matching the embedding method and plan to your customer-facing requirements, then build and hand over the result with the evidence your team needs to run it.
How we scope
- Confirm which embedding method your customer-facing use case needs before any plan decision is made
- Map the identity provider, user groups and tenant data separation your embedded views depend on
- Agree the written scope, deliverables and timeline in writing before work starts, as most engagements are fixed-scope
How we build
- Install and configure self-hosted Metabase in your environment, with the application database chosen and documented
- Integrate SSO and embedding settings for the selected method, including signed embed or identity configuration where required
- Test permissions, tenant isolation and embedded views against the scope before they reach customers
How we hand over
- Document the architecture, configuration, embedding setup and access model so your team can maintain it
- Provide an upgrade and backup runbook covering application database backups and migration steps for each release
- Walk your engineers through the handover and confirm the deliverables against the written scope
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope, response expectations and upgrade cadence are set in writing, so confirm them during scoping
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list
