Metabase embedding: when your product needs analytics inside it
If a product or portal team wants Metabase dashboards or saved questions shown to its own customers or staff, without sending those users to the Metabase login, the work is embedding. Metabase embedding works through modular embedding, full app embedding, public links and guest embedding, and the authentication method you choose decides which Metabase plan you need. Settle that choice before you design anything, because it shapes every other part of the build. Guest authentication works on every plan, including the open source edition. All SSO-based embedding requires Pro or Enterprise, so a team that expects end users to sign in with their own identities, or that needs each viewer to see different data, should check the plan requirement first. The static embedding option is deprecated. If you have an existing static embed, plan a move to a supported option and confirm the current status in Metabase's embedding documentation before you build on it.
The difficulty is that four decisions interact: the embed type, the authentication method, the plan and the permissions model. Consider an illustrative case. A team builds guest embeds on the open source edition with fixed filters for each customer. Later, the product requires that each customer sees only their own rows and that staff see different columns. Per-user identity and row and column permissions point to SSO-based embedding on Pro or Enterprise, because row and column level permissions are included only on those plans. The embed type, the authentication flow and the collection permissions then all change, and dashboards built on the guest assumptions need rework. The practical discipline is to write down the requirements before the first embed is built. Record who will view the content, whether they hold Metabase accounts, whether any viewer must be limited to specific rows or columns, and whether they may only view or also filter and drill. Each answer narrows the embed type and the authentication method, and each narrowing either confirms the plan you already have or moves you to a higher one.
Which Metabase embedding options exist and what each one is for
Metabase offers four ways to show its content outside the Metabase interface, and each one serves a different audience and carries different authentication and plan requirements. The cards below explain each option, the two components every embed depends on, and the signing secret that guest and SSO embeds need before anything goes live.
Modular embedding
Modular embedding places individual charts, dashboards or saved questions into your own web pages, with your application's layout and navigation around them. It suits product teams who want analytics inside an existing screen without giving users the full Metabase interface. Check which authentication method you need, because guest and SSO setups differ in plan requirements and in how user access is controlled.
Full app embedding
Full app embedding puts the complete Metabase interface inside your application, so users can browse collections, build questions and work with dashboards in place. It suits portals and customer-facing products where analytics is a core feature. Confirm with your Metabase plan and identity setup how users sign in and which permissions and collections they can see, since this option exposes far more of the tool than modular embedding.
Public links
Public links create unauthenticated URLs that anyone with the link can open to view a dashboard or question. They suit publishing a chart to a wide audience, such as a status page or a public report, where no sign-in is wanted. Because anyone holding the URL can see the content, review which data appears in public items and treat each link as shareable with no access control of its own.
Static embedding (deprecated)
Static embedding was an earlier method that rendered fixed, pre-selected content into an application. Metabase has deprecated it, so new projects should not start on it and existing deployments should plan a move to modular or full app embedding. Ask your implementation partner to inventory any static embeds, confirm the current replacement in the Metabase embedding documentation, and schedule the change alongside your upgrade plan.
Metabase application database
The application database stores the dashboards, questions, collections, users and embed settings that every embedding option reads from. Metabase ships with an embedded H2 database for demos, and PostgreSQL is the recommended choice for production. Before you embed anything for real users, confirm the application database is on a supported production engine with backups in place, because an embed is only as available as the instance and database behind it.
Signing secret for guest and SSO embeds
Guest and SSO embeds use a signing secret or key to create signed tokens that prove a request comes from your application. The secret must be stored securely, rotated under a defined process and never exposed in front-end code. Guest authentication works on every plan, including the open source edition, while SSO-based embedding requires Pro or Enterprise. Confirm the exact key setup and token configuration steps in the current Metabase embedding documentation before you build.
Which embed type and authentication method fit your product
This table compares the five Metabase embedding options by the audience each one fits and the operational work it adds: request signing, identity provider setup, plan cost and session handling. Read each row against who will view the content. Guest authentication is the only option available on the open source edition, while every SSO-based option requires Pro or Enterprise. Public links expose content to anyone holding the link, so limit them to non-sensitive material.
| Option | When it fits | Signing and identity setup | Plan cost and sessions |
|---|---|---|---|
| Modular embedding with guest authentication | Customers see selected charts or dashboards inside your product, with no Metabase login | Your backend signs each embed token with the secret key and manages key rotation | Open Source and all paid plans. Viewers have no Metabase session; your app controls access. |
| Modular embedding with SSO | Your users need Metabase accounts with group-based permissions while staying on your product pages | Embed signing plus identity provider setup (SAML, OIDC or JWT); confirm the exact flow for your version | Pro or Enterprise required. Users beyond the plan's included seats are billed per user. Sessions are governed by the identity provider. |
| Full app embedding with SSO | Your users need the full Metabase interface, including collections and question building, inside your portal | Identity provider setup with SAML, OIDC or JWT, so users sign in through your SSO | Pro or Enterprise required. User counts drive cost; confirm seat terms on the pricing page before committing. |
| Public links | Anonymous viewing of non-sensitive charts shared on a website or in a document | No signing or identity setup; anyone with the link can open the content | No login or session. Revoking a link is the main control; confirm revocation steps for your version. |
| Static embedding (deprecated) | Existing static embeds that already run; not suitable as the basis for new work | Signed embed URLs configured in the admin panel; confirm current behavior with Metabase | Deprecated. Plan a move to modular embedding and confirm current support with Metabase before relying on it. |
Guest or SSO authentication: how the choice affects your plan and your users
The authentication method you choose for a Metabase embed decides two things before any dashboard is built: which Metabase plan you need and how each viewer is identified. Guest authentication lets your application vouch for viewers who never hold a Metabase account, and it works on every plan, including the open source edition. SSO-based embedding ties each viewer to an identity in your identity provider and to Metabase permissions, and all SSO-based embedding requires Pro or Enterprise. Confirm the current plan boundaries on Metabase's pricing page before you commit, because the answer determines the license line in your budget. The audience changes the decision. When the viewers are external customers in your product, guest embedding is usually the natural fit, since those customers should not need Metabase logins or a seat in your workforce identity system. When the viewers are internal staff reached through a portal or intranet, they often already have identities in your identity provider, so SSO embedding lets them use the same sign-in they use everywhere else. Ask how many viewers you expect, whether they already exist in your identity provider, and whether any of them also need to log in to Metabase directly.
Permissions follow the identity, so the identity model drives what each viewer can see. With SSO, group membership from the identity provider can be mapped to Metabase groups, and those groups carry collection and data permissions. Row and column level permissions, multi-tenant data segregation and auditing are included only in Pro and Enterprise, according to Metabase's pricing page. Do not assume that a guest embed can carry row-level restrictions for each customer. Before you design tenant isolation around guest sessions, ask Metabase to confirm, in writing for your version, how embed parameters and permissions apply to guest tokens and whether any row-level restriction can be enforced for them. If your design depends on restricting each customer to their own rows, test that restriction with two accounts that should see different data. Check what happens when a filter parameter is omitted or altered in the embed request, since the application signs that request. The result of this test determines whether you need an SSO-based design on Pro or Enterprise, a different data model, or a separate Metabase deployment per tenant.
Settle the identity model before the embed is built. The embed code, the signing logic, the collection structure and the group mappings all depend on who the viewers are and how they are grouped. Decide which identities exist, which groups correspond to which collections and data sets, how a customer's users are represented, and who creates and removes them. Changing these decisions after the build usually means reworking the embed URLs, the signing code and the permission setup together, which is more expensive than settling them first. The mechanics of connecting an identity provider, including the protocol options and how group attributes are passed, belong in the Metabase SSO and identity integration work, so this section does not repeat those steps. What this decision needs is a written model: a list of viewer types, the identity source for each, the Metabase group or permission each type receives, and the plan that supports it. Review that model with your security and compliance leads so that access decisions are documented before go-live.
How to build a Metabase embed from first content to signed-in viewers
This sequence takes a Metabase embed from plan confirmation to a non-admin viewer seeing only their own data in production. Each step closes with a check, so the team knows the embed is safe to move forward before the next step begins.
Confirm the plan and embed type
Compare your plan and embed type against Metabase's pricing and embedding documentation before any build work starts. Guest authentication works on every plan, including Open Source, while all SSO-based embedding requires Pro or Enterprise. The static embedding option is deprecated, so plan around modular, full app or public embeds. The product owner records the decision with the plan, embed type and expected user count. Check: that written note exists and the vendor has confirmed current plan prices, since pricing pages change.
Confirm the production application database
Metabase ships with an embedded H2 application database intended for demos, and the documentation recommends PostgreSQL for production. MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 are also supported. The platform team provisions the production database, points Metabase at it and takes a backup before any content is published, so later changes do not force a rebuild. If you are moving from an existing H2 install, use the documented load-from-h2 command with the same Metabase version that last wrote the H2 file. Check: the instance restarts cleanly against the new database and test content still exists after the restart.
Place embeddable content in a dedicated collection
Choose which dashboards and saved questions external viewers may see, and move only those into a dedicated collection. Review each item for any data, filter defaults or text that should not reach a customer. Sharing and embedding are controlled per item, so a dedicated collection keeps the embeddable set small and easy to audit. The analytics lead signs off the list before the next step. Check: the collection contents match the approved list exactly, and no internal or exploratory questions sit alongside them.
Enable embedding and record the signing key
In the admin settings, turn on embedding and generate or record the signing key that the host application will use to sign guest tokens. Store the key in your secrets manager, limit who can read it and keep a record of which environments hold it. Never place the key in source control or front-end code. Check: embedding shows as enabled in the staging environment, and the key is present in the host's secret store only.
Build the signing or SSO flow
For guest viewers, the host server builds a signed token that names the approved dashboard or question and the parameter values for that viewer, using the key from the previous step. The server must derive those values from the authenticated session, never from the browser request. For SSO-based embedding on Pro or Enterprise, configure SSO following the people and groups documentation and map groups to the permissions you defined. Check: a token altered by even one character is rejected, and a token issued for one customer returns only that customer's rows.
Set allowed parameters and locked filters
Decide which parameters a viewer may change, such as a date range, and lock every filter that enforces ownership or tenancy. Locked values should be fixed inside the signed token, so the browser cannot supply them. Keep the list of allowed parameters in version control with the host code so changes are reviewed. Check: using browser developer tools, change the filter value in the embed request and confirm the viewer still sees only their own data.
Place the embed in a staging page
Place the modular or full app embed on a staging page in the host application, using the embed type confirmed in the first step. Keep the page behind the same navigation and authentication the product already uses, so the viewer signs in once. Hide any Metabase admin navigation that the embed type exposes. Check: the page loads for a signed-in test viewer without a Metabase login prompt and shows only the expected charts and tables.
Test with a non-admin viewer, then release
Sign in as a non-admin test user with a representative group and attribute profile. Confirm the viewer sees only their filtered data, cannot open the Metabase admin area and cannot reach unpublished content. Record the results, fix any leaks, then promote the host change and signing key configuration through your normal release process. Check: the same viewer test passes in production with a dedicated test account, and the application database backup from the second step is still available for the first release.
What drives the effort and cost of a Metabase embedding project
This table compares the factors that change how much work a Metabase embedding project takes and what it costs, with a note on how to keep each one under control. Read each row as a question to answer before scoping, since the same driver can add a few days of work or a full identity integration. The main takeaway is that the Metabase plan and the number of teams touching the signing flow often matter more than the number of dashboards.
| Driver | How it changes the work | How to keep it down |
|---|---|---|
| Number of embed types and pages | Each modular component, full app embed or public link needs its own placement, layout and testing. Static embedding is deprecated, so it should not be chosen for new work. | Limit the first release to the embed types the product needs. Write the list of pages and charts before design starts. |
| Authentication model | Guest embedding works on every plan, including Open Source. SSO-based embedding needs an identity provider connection, group mapping and a signing service, which adds design and security review work. | Confirm early whether guest access is enough for each audience. If SSO is needed, name the identity provider (for example Okta, Entra ID or Keycloak) in the scope. |
| Plan tier and required features | Per the Metabase pricing page, SSO, row and column level permissions and multi-tenant data segregation are included only in Pro and Enterprise. Choosing these features moves the Metabase license cost up. | Map each required feature to a plan before quoting. Ask the customer to confirm the plan they hold or intend to buy, since license cost is separate from implementation effort. |
| Number of end-user audiences and data restrictions | Each audience with different visible data needs its own permission design, test accounts and verification. Multi-tenant data separation adds the most testing. | Group audiences by data access rules. Document the restriction for each group in one table before build starts. |
| Host application stack and teams in the signing flow | Each team that touches the signed embed URL, token issuance or session handling adds review and coordination. Stacks with more services need more integration testing. | Keep token signing in one service owned by one team. Ask the customer to name every team that changes that code path. |
| Number of environments | Development, staging and production each need a Metabase instance, application database, data connections and identity configuration. Keeping them consistent takes repeated setup and checks. | Agree on which environments are required and how configuration moves between them. Confirm whether the customer wants infrastructure as code for the setup. |
| Branding and layout customization | Theme, fonts, colors and page layout for embedded content require design decisions and review in each host page. Custom changes often need retesting after Metabase upgrades. | Limit the first release to the supplied brand guidelines. Defer custom changes to a later phase with a named owner. |
| Security review from the customer's compliance program | Internal security reviews may require threat models, evidence of token expiry and access controls, and sign-off from security reviewers. Each review round adds elapsed time. | Share the intended design and access model with the customer's security reviewers at the start. Ask which controls they need evidence for. DeployOpen prepares evidence but does not issue audit reports or certifications. |
| Quote inputs and handover | Cost comes from engineers, security reviewers and product owners, plus the Metabase plan. A quote without a written inventory of embed types, audiences and environments cannot be compared fairly. | Ask for a written list of embed types, audiences, identity provider, environments and handover items (documentation, runbooks, access transfer) before agreeing the scope. |
How to keep embedded Metabase content from leaking to the wrong viewer
Embedding adds controls on top of the standard Metabase permissions model. Each of the six controls below closes a different path by which content could reach a viewer who should not see it. Work through them before launch and again after any change to signing, sharing options or the data sources an embed can reach.
Signing key kept out of front-end code
Signed embeds use a secret held by your server to create a token for each viewer. If that secret ships in browser JavaScript, anyone who opens developer tools can mint tokens for any embedded dashboard. Keep the secret in a secrets manager, load it only into the backend service that signs requests, and confirm in Metabase's current embedding documentation how the key is generated and rotated. Ask who can read the secrets manager and whether rotation appears in your runbook.
Locked parameters on every signed embed
Signed embeds can carry parameter values, such as a customer ID or region filter. A viewer who edits the URL or the front-end call may try to change those values. Decide which parameters are locked into the signed token and which, if any, the viewer may adjust. Test by changing a parameter in the browser and confirming the result stays scoped to the intended customer. Record which dashboards expose which parameters so a later edit to a dashboard does not quietly open a new filter.
Public links and who creates them
Public links make a dashboard or question viewable by anyone who holds the URL, with no sign-in. They suit published reports that contain no sensitive data, but they are easy to forward and hard to recall once shared. Decide whether public links are allowed in your instance at all, and limit creation to a named group of administrators. Check the sharing settings during acceptance testing, and confirm the current procedure for disabling public links in the Metabase documentation.
Data permissions the embedded viewer inherits
An embedded viewer acts through an identity that carries data permissions, so whatever that identity can query, the embed can display. A broad group or an administrator account behind an embed exposes every table it touches. Build a dedicated group for embedded use, grant only the databases and collections it needs, and apply row and column level permissions where a customer should see only a slice of a table. Those controls require a Pro or Enterprise plan, so confirm the plan before relying on them.
TLS and allowed embedding origins
An embed loads inside another site's page, so traffic between the viewer, the host page and Metabase must be encrypted, and the host site must be permitted to frame Metabase content. Serve Metabase only over TLS with a valid certificate, and set the response headers that limit which origins may embed it. Confirm the origin control and its setting name in the current embedding documentation before writing configuration, since the exact mechanism can change between releases.
Audit trail for embed setting changes
Changes to embedding settings, signing configuration and sharing options alter who can see what. Confirm which of these events your Metabase edition records and where they are visible, because usage analytics and auditing are listed for Pro and Enterprise plans. Assign an owner to review changes, and forward logs to your central monitoring if your edition supports export. Test by making a sharing change and confirming it appears with the user who made it.
How to test that a Metabase embed shows the right data and fails safely
A Metabase embed is only ready for handover when each audience sees the dashboards and rows it should, and nothing else. Start with positive tests. Build a matrix that lists each audience (for example, an internal analyst group, a customer tenant, and a partner team), the embedded dashboard or question each one should see, and the data that should appear in it. Log in as a non-admin account for every audience, because Metabase administrators see collections and settings that viewers never will. Where the embed relies on SSO-based authentication, use accounts that receive their group memberships from the identity provider, not accounts created by hand in Metabase, so the test also proves the group mapping works. Record the expected row counts or totals from the source database so the comparison does not depend on what the tester happens to see.
Negative tests carry most of the risk. First, confirm that a viewer cannot read another customer's rows by editing a parameter in the embed URL, the browser developer tools or the request body. The request should be refused or return only that viewer's data. Second, test token handling. For signed embeds, use an expired token, a token with a changed payload, and a token signed with a different key. Each should be refused. Third, test public links. Open a public link and attempt to reach private dashboards, questions or collections by changing identifiers in the address. The link should expose only the single item it was created for. Fourth, sign in as a user who has no permission on the embedded content and confirm the embed shows nothing useful, not an error page that reveals names or structure. Confirm the exact refusal behavior for your version and configuration, because error messages differ between embedding types.
Check that no Metabase admin interface appears inside the embed. Navigate the embedded view as a non-admin user and look for settings menus, the admin area, database configuration pages, user management and the full application navigation. In full app embedding, the surrounding Metabase navigation is expected to be present, so the test should focus on whether admin routes are reachable from it. In modular embedding, confirm that only the chosen components render and that no toolbar or action exposes administrative features. Try the admin paths directly in the address bar as well. The same check should be repeated after any change to the embed code, because a small front-end change can expose navigation that was previously hidden.
Record every test so the results can be handed over and repeated. For each case, capture a test identifier, the audience and account used, the steps, the expected result, the actual result, the tester, the date, and evidence such as a screenshot or a saved request and response. Also record the Metabase version, the plan, the authentication method and the identity provider configuration in effect at the time. Store test account credentials in your password vault, not in the test log. Retest the full plan after any change to the plan (some embedding and SSO features depend on Pro or Enterprise), to the Metabase version, to the identity provider or its group claims, to signing keys, or to the permission model. Ask your implementation partner to confirm which of these tests your version supports natively and which need an external tool or a manual procedure.
Keeping embeds working after upgrades and version changes
An embed is only as stable as the Metabase version it runs on and the configuration around it. The cards below cover the decisions and checks that keep embedded dashboards and questions working across upgrades, from version support windows to rollback and documentation.
Version support windows
Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after about 2 months. Metabase 64 is an LTS release with end of life on 1 December 2027, and Metabase 65 was released on 12 October 2026. Check the version support page before choosing a target, and retest any embed built on one version before it moves to another.
Retesting embeds after upgrades
An embed depends on the signing code in your application, the embed settings in Metabase, and the rendering behavior of the Metabase version serving it. A release can change any of these, so a dashboard that worked before may fail silently for some users. Keep a test pass for each embed type you run, including guest, SSO and any public links, and run it against a staging copy before production.
Backing up the application database
Metabase runs application database migrations automatically when a new version starts, so the upgrade changes stored configuration, including embedding settings and permissions. Take a backup of the application database immediately before each upgrade and confirm it can be restored. If the database is still the embedded H2 default, plan the PostgreSQL move before a major upgrade.
Rollback by restoring the backup
The recommended rollback is to restore the pre-upgrade application database backup and start the previous JAR. Running the migrate down command with the newer JAR is an alternative, but it depends on the migration path, so test it on a copy first. Record the exact version numbers and backup timestamp before each upgrade so that rollback is a timed, practiced step rather than a search through logs.
Embed inventory and ownership
Keep a written list of every embedded dashboard and question, the application page or portal that hosts it, the authentication method used, and the Metabase object IDs involved. Name one owner for the signing configuration and secret rotation, and one owner for the test script. Without this record, the next upgrade starts with discovery work rather than verification.
Test script and sign-off
A short, repeatable test script shortens each upgrade review. It should load each embed as each user type, confirm filters and row-level restrictions behave as expected, and check that signed tokens are accepted. Store the script in the same repository as the embed configuration, and record who signed off each run so audit questions can be answered from documents.
Questions buyers ask about Metabase embedding before hiring help
Which Metabase plan is needed to embed dashboards in my product?
Guest embedding works on every plan, including the free Open Source edition. SSO-based embedding requires Pro or Enterprise. Metabase's pricing page lists Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Enterprise is priced by quote, starting at $20,000 per year. Confirm current figures on the pricing page before budgeting, because plan terms can change. The deciding question is how your end users sign in. If guest access is enough, Open Source can cover embedding. If embedded viewers must authenticate through your existing identity provider, plan for Pro or Enterprise from the start.
Can our own engineers build Metabase guest embedding in-house?
Yes, many teams build guest embedding with their own engineers, but the work spans your application code as well as Metabase settings. Your server must generate signed embedding tokens, map each customer or tenant to the right dashboard parameters, and keep those mappings correct as accounts change. The platform team also needs to operate the self-hosted instance, its application database and its upgrades. Confirm the exact token and signing steps against the embedding documentation for your Metabase version. Teams often ask an outside reviewer to test the boundary between their app and Metabase, since that is where access mistakes are most likely to appear.
How long does a Metabase embedding project take, and what drives the timeline?
No duration applies to every project, so treat any timeline as unconfirmed until the scope is written. The main drivers are the number of embedded surfaces (modular components, full app embedding or public links), the authentication choice (guest or SSO through your identity provider), how many tenants or data segments must stay separated, and whether your host application already issues signed tokens. Testing across environments and the security review also add time. Ask for a phased plan with a dated first milestone, and check it against your release calendar and freeze windows before committing.
What does a Metabase embedding project need from our team?
The work depends on access and decisions from your side. Plan for the following:
- Identity provider access: admin rights or metadata for any SSO setup on Pro or Enterprise.
- Host application engineers: people who can add server-side token generation and front-end embedding to your product.
- A named product owner: one person who decides which dashboards, filters and tenant rules are in scope.
- A security reviewer: someone who checks token handling, permissions and public link exposure.
- Metabase administrators and test data: access to a non-production instance and realistic sample data.
Agree these owners in writing at the start, because delays usually come from unassigned decisions rather than from the technical build itself.
Should we still use static embedding in Metabase?
Do not start new work on static embedding. Metabase lists it as deprecated, so plan for the documented replacement in its embedding documentation. Inventory every existing static embed, map each one to its replacement option, test the result with real users and schedule cutover before any Metabase upgrade removes the old path. Confirm the replacement details and any removal date against the current documentation for your version, because no removal date is set in this guide. Keep a rollback plan for each embed during cutover, since a broken portal page is visible to your customers.
What should a Metabase embedding quote include?
A useful quote follows from a written scope, since most engagements are fixed-scope. Ask for these items:
- The list of embedded surfaces, the authentication method and the tenant model.
- Identity provider work and any group or attribute mapping.
- Environments, testing types (functional, permission and security) and acceptance criteria.
- Documentation, handover and training for your team.
- Which costs are one-time and which recur, such as support retainers.
- A separate line for Metabase licensing, since it is set by Metabase's own plans.
- Change request handling and the buyer responsibilities listed in the scope.
DeployOpen does not publish a price list, so a quote follows from the written scope.
Can our team maintain Metabase embeds after go-live?
Yes, if the maintenance plan is set before launch. Embeds need attention when Metabase upgrades, because each release brings database migrations and changed behavior. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months, so your version choice sets how often you must upgrade. Back up the application database before each upgrade, and retest every embed afterward. Your team can handle this internally, or a support retainer can cover upgrades, regression testing and monitoring. Ask for a written runbook and confirm who owns each step.
How DeployOpen scopes, builds and hands over Metabase embeds
DeployOpen scopes Metabase embedding as a written, fixed-scope engagement inside your own infrastructure, starting with the embedding type and authentication method your plan supports. We build and test the embed in your environment, then hand over documentation, configuration and walkthroughs for your engineers. Ongoing support, upgrades and testing are available as a retainer.
How we scope
- Written scope that names the embed type: modular, full app, or public link, for each embedded surface.
- Authentication decision: guest access works on all plans, while SSO-based embedding requires Pro or Enterprise.
- Confirmation of the Metabase edition and application database the embed will run on.
How we build
- Embed settings applied in your Metabase instance, with secrets stored in your own secret management.
- Front-end integration in your product or portal, built against the dashboards and questions you approve.
- Test of each embedded view for the permissions and collections each user type should see.
How we hand over
- Documentation covering the embed type, authentication path, settings and the owners of each configuration item.
- Walkthrough with your engineers covering how to add a new embedded dashboard without breaking access rules.
- Deprecation note if the design relies on static embedding, with a migration path to a supported option.
How we support
- Ongoing support, upgrades and continuous testing available as a retainer, scoped in writing.
- Review of embed behavior when Metabase moves to a new release, using the version support windows to plan.
- Confirmation with your team of who owns Metabase access, plan changes and ongoing edition decisions.
