Why Metabase security hardening starts before the first dashboard is shared
Hardening a self-hosted Metabase means making a small set of decisions before anyone shares a question or dashboard: which production application database Metabase will use, which credentials it and each data source connection will hold, how data and collection permissions are set, whether public links and embeds are allowed at all, how traffic is encrypted with TLS, and which activity must be logged and retained. If your team has installed Metabase or is about to, these choices shape everything that follows, because a dashboard shared under the wrong settings is hard to take back once people have seen the data.
The work is harder than it looks for three reasons. First, the embedded H2 application database that Metabase ships with is intended for demos, and Metabase recommends PostgreSQL for production, so the first hardening step is a migration decision rather than a checkbox. Second, several controls depend on your plan. Row and column level permissions, SSO and auditing are included only in the Pro and Enterprise plans according to Metabase's pricing page, so a team on Open Source or Starter must confirm early whether the governance it needs is available at its tier. Third, a public link or embed can expose query results outside the permission model entirely, so those features need an explicit owner and an explicit approval. Scope spans three layers. The hardening work touches the Metabase instance itself, the source databases it queries and the network path between users, Metabase and those databases. A weak database account, an open port or an unencrypted hop can undo settings made inside the application. Ask who on your side owns each layer before configuration starts. Confirm three things with your Metabase contact or in your own environment before you begin: which plan you will run, whether your governance rules require row or column restrictions, and whether anyone expects to share content outside the company. The answers decide which of the controls below are available to you and which must be designed around.
Which Metabase components and settings carry security risk
A hardening review of self-hosted Metabase follows the data path: the application database that holds its state, the credentials it uses to reach source databases, the permissions that decide what users see, and the public and embedded surfaces that expose content outside the normal login. The runtime, the proxy in front of it, and the audit trail complete the picture, because each one either limits or reveals what the layers above it allow.
Application database
The application database stores users, groups, permissions, saved questions, dashboards and settings, so its contents describe the whole deployment. Metabase ships with an embedded H2 database meant for demos, and the vendor recommends PostgreSQL for production. Check that the database is not H2, that it is reachable only from the Metabase hosts, that its backups are encrypted and tested, and that the Metabase service account has no more rights than migrations require.
Source database connections
Each connection stores credentials that Metabase uses to query a source system, and every user query runs under that account unless permissions say otherwise. A connection left with an administrative account exposes far more data than any dashboard needs. Review each connection for a dedicated read-only role, restricted schemas and tables, network paths limited to the Metabase hosts, and a secret store rather than plain configuration files.
Groups, collections and data permissions
Groups decide who can see which data, which collections they can open, and whether they can create or edit questions. The default All Users group is granted broad access in many installs, so new accounts inherit more than intended. Review each group's data access, native query rights and collection permissions, and confirm that sensitive sources are not visible to general groups. Row and column level restrictions require a Pro or Enterprise plan, so confirm which controls your edition provides.
Public links and embedding settings
Public links make a question or dashboard reachable by anyone holding its URL, with no Metabase login. Embedding adds further exposure through guest and signed embeds that present data inside another product. Inventory every public link and embed, confirm that each one shows only data meant for outside readers, and disable public sharing where no current use exists. Confirm which embedding methods your plan supports, since some require Pro or Enterprise.
JAR runtime and reverse proxy
Metabase runs as a Java JAR, so the host's Java runtime, its service user, file permissions on the JAR and configuration, and the process environment all shape the attack surface. A reverse proxy or load balancer in front of it terminates TLS, sets headers and decides which paths are reachable from outside. Verify that Metabase listens only on an internal address, that TLS settings and certificates are current, that unneeded paths are blocked at the proxy, and that the runtime receives timely patches.
Usage analytics and audit data
Usage analytics and audit logs show who queried which data, who changed permissions, and who shared content, which is the evidence a review or incident investigation depends on. These features are included only in the Pro and Enterprise plans, not in Open Source or Starter. Without them, teams need to rely on application logs and database logs at the source. Decide where access events will be kept, how long they are retained, and who can read them.
Which hardening decisions change the security model and the operating load
This table compares the hardening choices that alter what your Metabase deployment protects and what your team must run afterward. Read each row as a decision: the option, when it fits, and the ongoing work it creates. The main takeaway is that the application database, plan tier and embedding model shape both your security posture and your operating load more than any single setting.
| Decision | Option and when it fits | Operational cost |
|---|---|---|
| Application database | Embedded H2 is for demos only. PostgreSQL is the recommended production choice. MySQL 8.4.0 or MariaDB 10.6.0 with utf8mb4 are supported alternatives when PostgreSQL is not an option. | A separate database server adds backups, restore tests, patching, monitoring and access reviews. H2 has no separate server but is not suited to production. Confirm the minimum database version against the current docs before provisioning. |
| Row, column permissions, SSO and auditing | Needed when data access must differ by user or group, when identity must come from your IdP, or when audit trails are required. These features are included only in Pro and Enterprise plans. | Plan cost is recurring and per user, and quotes are needed for Enterprise. Owners must maintain group mappings and permission rules as roles change. Open Source and Starter omit these controls entirely. |
| Public links | Acceptable only for content that is genuinely public. Disabling them is the default posture for most internal deployments. | Low ongoing effort if disabled. If enabled, someone must review which dashboards are shared, track link revocations and check for forgotten links. |
| Embedding mode and authentication | Guest authentication works on all plans, including Open Source. SSO-based embedding requires Pro or Enterprise. Choose the mode according to how your product identifies end users. | Guest embedding requires your application to sign tokens and manage the signing secret, with rotation. SSO-based embedding adds identity provider configuration and plan cost. Confirm which embedding modes your product needs before design. |
| TLS termination point | Terminating at a reverse proxy or load balancer centralizes certificates and is common in managed networks. Terminating at the Metabase instance keeps traffic encrypted end to end inside the network. | Proxy termination means certificate renewal and proxy configuration are maintained by the infrastructure team. Instance termination means certificates are installed and rotated on each node, which grows with cluster size. |
| Upgrade and patch path | Staying current matters because support windows differ between LTS and non-LTS releases. Confirm which release line you will run before choosing a termination or database design. | Each upgrade runs application database migrations and needs a verified backup and a rollback plan. Clusters may need reduction to one node during major upgrades. This work recurs for the life of the deployment. |
How to build a hardened Metabase instance in sequence
This sequence moves a self-hosted Metabase from its demo defaults to a configuration where the application database, database credentials, access rules, sharing settings and audit records each have a defined owner and a verifiable check. The order matters because later controls depend on earlier ones being in place.
Move the application database off embedded H2
Metabase ships with an embedded H2 application database intended for demos, and Metabase recommends PostgreSQL for production. Your platform or database team provisions a managed or self-hosted PostgreSQL instance, configures backups and restore testing, and then points Metabase at it before any production data source is connected or any real question is saved. The migration procedure itself is covered on the H2 to PostgreSQL sibling page. This step is done when the admin settings show the application database as PostgreSQL, a test restore of the backup has succeeded, and the backup schedule is confirmed in your backup tooling.
Create read-only database accounts per connection
For each source database, a database administrator creates a dedicated Metabase account with read-only privileges limited to the schemas and tables the analysts need. Credentials are stored in your secrets manager and never shared between connections, so a compromised Metabase instance exposes only what that account can read. Confirm the grants by attempting a write and a read of an out-of-scope schema with the account, both of which should fail. The step is closed when those negative tests are recorded alongside the grant script.
Configure TLS at the entry point
The platform engineering team places a TLS-terminating reverse proxy or load balancer in front of Metabase, uses certificates issued by your internal or public certificate authority, and redirects plain HTTP to HTTPS. Confirm which settings your Metabase version expects for the site URL so that links, emails and embedding origins resolve to the HTTPS address. The check is an external TLS scan of the Metabase hostname showing a valid chain and no plaintext listener, along with the site URL confirmed in the admin settings.
Set groups, collections and data permissions
Before users are onboarded, the Metabase administrator creates groups that mirror business roles, assigns collection permissions, and sets data permissions per database and table so that default access is no broader than necessary. Sensitive tables are restricted to named groups. Whether a given row or column restriction is available depends on your plan, so confirm that against the current edition comparison before designing it. The step is closed when a test user in a restricted group is shown to be denied a sensitive table, and that result is recorded.
Review public sharing and embedding settings
The administrator reviews the public sharing setting and any embedding settings in the admin panel, then disables features the use case does not need. Public links make content reachable by anyone with the URL, so the default should be off unless a documented requirement exists. Where embedding is needed, confirm which authentication method applies and whether it is available on your plan. The check is a published test question followed by an attempt to open its public link from a logged-out browser, which should fail once sharing is disabled.
Enable audit and usage capture if licensed
Usage analytics and auditing are listed on the pricing page as included only in the Pro and Enterprise plans. If your plan includes them, the administrator enables the capture, sets retention in line with your logging policy, and forwards records to your central log store where that is supported. If your plan does not include them, record that gap as a risk and a compensating control, such as database-side query logging on the read-only accounts. The step is closed when a test action appears in the captured records or the compensating control is documented.
Record the configuration and baseline
The team exports or documents the final configuration: application database settings, grant scripts, group and permission mappings, sharing and embedding settings, TLS configuration and the Metabase version in use. The record is stored under change control so that later upgrades can be compared against it. Confirm with your security owner that the baseline has been reviewed and that the next review date is set. The step is closed when the baseline document is approved and linked from your operations runbook.
Setting data and collection permissions so people see only what they should
Permissions in self-hosted Metabase decide who can query which data and who can see which saved questions and dashboards, so this is where a hardening review should spend most of its time. Access is applied through three connected mechanisms: group membership, data permissions tied to each connected database, and collection permissions that control who can view or edit saved work. A user only sees what the combination of these grants allows, and a gap in any one layer can expose data. Confirm the current permission model in Metabase's people and groups documentation before you design it, because the rules for combining group grants are the part most likely to change between releases.
A dashboard built by a permitted user can still expose data that the viewer should not see. A reviewer should check the underlying source of each question, not only the dashboard. If a card runs on a database connection whose stored credentials belong to an account with broad read access, anyone allowed to run that card may reach far more than the dashboard shows. Sharing settings add a second path: a collection or dashboard shared more widely than intended can carry results to people outside the group that was meant to see them. Treat the saved question, its data source and its sharing setting as one unit when you review access.
Test the layers in order. First, confirm group membership against your identity source, including any admin rights that bypass grants. Second, check database-level and table-level data access for each group, then check collection access, including whether non-admin users can edit or move content in shared collections. Third, review sharing and public link settings. For each group, sign in with a dedicated non-admin test account and attempt the queries and views that group should be blocked from, not only the ones it should have. Record what each account can open, query and share, and repeat the test after every change to groups or permissions.
Row-level and column-level permissions, along with multi-tenant data segregation, are included only in Metabase's Pro and Enterprise plans, according to the Metabase pricing page. Open Source and Starter do not include them. If your design depends on hiding individual rows or columns from some users, or on keeping tenants apart within one instance, the edition decision has to come before the permission design. On the free edition, the practical control is to separate data across groups, connections and collections, and to give each group a database account with only the access it needs. Confirm the current feature list against the pricing page at the time of your review, since plan contents can change.
Hardening controls for access, secrets, sharing and transport
Most Metabase exposure comes from a small set of settings: the database account Metabase uses to reach your data, where credentials are stored, who can publish or share content, and how traffic is encrypted. Each card below names one control, the risk it addresses and the setting or procedure to confirm in your own environment.
Least-privilege source database accounts
Metabase only needs read access to the schemas and tables that analysts query. Create a dedicated read-only account per data source, grant it access only to the required objects, and avoid reusing the account that owns the application database. Rotate these credentials on a schedule your team can run without downtime, and confirm the rotation procedure in the Metabase database connection settings before go-live.
Secrets outside source control
The application database credentials, the encryption key for stored data source secrets and any SSO or SMTP secrets should not appear in version control, container images or plain-text configuration files shared by the team. Inject them at runtime from a secrets manager or the host's protected store. Confirm in the configuration documentation exactly which values Metabase reads from the environment and how it protects stored connection details.
Public links and embedding restrictions
Public links make a question or dashboard readable by anyone who holds the URL, with no login and no permission check. Review which admins can create them, search for existing public links and disable public sharing where it is not required. Public embedding follows the same logic, so confirm that the embedding settings match the audiences you intend to reach.
Embedding authentication matched to the audience
Guest embedding authenticates viewers through a signed token from your application and works on every plan, including Open Source. SSO-based embedding requires a Pro or Enterprise plan. Choose the model that matches who sees the content, document how each embed token is signed and scoped, and test that a token for one customer cannot reveal another customer's data.
TLS between users, proxy and instance
Encrypt traffic from browsers to the reverse proxy and from the proxy to the Metabase instance, and make sure plain HTTP redirects to HTTPS. Check the certificate chain, expiry monitoring and the cipher policy your proxy enforces. Confirm the site URL and any forwarded-protocol settings in the Metabase documentation so that links, cookies and redirects use HTTPS.
Limited admin accounts and patch scope
Keep the number of Metabase administrators small, because admins can change data source connections, permissions and sharing settings. Review admin membership on a regular cadence and remove accounts that no longer need it. Treat the Metabase JAR, the Java runtime and the host operating system as one patch scope, and track the Metabase version support page so that the instance stays on a supported release.
What drives hardening effort and how to keep each driver down
This table lists the factors that change how much work a Metabase hardening engagement involves, what raises each one, and how to keep it manageable. Read each row against your own environment to see which drivers apply most heavily. The main takeaway is that most effort comes from the number of connections, groups and public surfaces, so decide those early and keep them documented.
| Driver | What raises effort | How to keep it down |
|---|---|---|
| Source databases and connections | Each connected database needs its own least-privilege account, a schema-level permission review and a record of what the account can read. Connections added later often bypass the original review. | Connect only the databases needed for approved questions. Use one read-only account per database with narrow grants, and keep a register of connections, owners and review dates. |
| Groups, collections and permission rules | Each business unit adds groups, nested collections and data permission rules. Overlapping rules are hard to reason about and harder to prove to a reviewer. | Map groups to roles agreed with data owners before building. Keep collections shallow, use a clear naming pattern and review permission rules on a fixed cadence. |
| Public and embedded surfaces | Each public link, public sharing setting or embedded dashboard creates a path to data outside normal login. Each one needs its own sharing review and owner. | Disable public sharing by default and allow it only for named content. Keep an inventory of public links and embeds, and retire any that no longer have an owner. |
| Data sensitivity and row or column controls | Personal, financial or health data may require row-level or column-level restrictions. Those controls are available only on Pro and Enterprise plans, so plan choice and testing scope both change. | Classify data sources before rollout. Confirm which controls the chosen plan provides, and limit sensitive tables to groups that truly need them so fewer rules must be tested. |
| Identity integration | SSO and directory sync depend on the plan. Google sign-in and LDAP are available on Open Source and Starter, while SAML, OIDC, JWT and SCIM require Pro or Enterprise. Group mapping must be tested against real directory structures. | Decide the identity method before hardening starts. Use the directory groups that already exist, confirm plan coverage in writing, and test deprovisioning as well as login. |
| Compliance evidence requirements | The assessor needs records they can review, such as access reviews, configuration baselines, change logs and backup restore tests. Each record type adds collection and retention work. | Agree the evidence list with your auditor or compliance lead at the start. Build the records as part of the work, such as exported permission snapshots and dated review sign-offs. DeployOpen prepares evidence but does not issue audit reports. |
| Environments and separation of test and production | When test and production share an application database, users, or data sources, changes are harder to validate and access rules are harder to isolate. Each separate environment repeats part of the configuration and verification. | Run separate application databases and data source connections per environment. Promote configuration in a controlled way and verify hardening settings in each environment rather than assuming they carried over. |
| Version and upgrade cadence | Staying on a supported release requires periodic upgrades, and each upgrade should be checked against the hardening baseline. Release windows for non-LTS versions are short, which raises the frequency of this work. | Choose an LTS release where the support window fits your change calendar. Record the hardening baseline so each upgrade can be checked against it quickly. |
How to verify the hardening works and fails safely
The hardening is only proven when each control is tested for the behavior it should produce, and the most useful way to write those tests is as expected outcomes: what a given user should see, what a blocked request should return, and what the reviewer should find afterward. Write one test case per control, name the Metabase group or role it applies to, and record the result with the date, the Metabase version and the person who ran it. Keep these cases with the configuration record so the same checks can be repeated after every upgrade, since upgrades can change defaults.
Start with permissions. Sign in as a test user in each permission group and confirm that the user cannot read a restricted table through the question builder, cannot reach it with a native SQL question in the SQL editor, and cannot see it indirectly through a shared dashboard or a saved question owned by someone else. The expected result is an access denied message or a view with no rows, never a partial result. Repeat for each group, including groups that have only collection access, and confirm that the test user also cannot change the data source settings. If your plan includes row or column level permissions, add a case per restricted attribute, because a permission can look correct in the group settings while a saved question still exposes the column.
Next, test public and embedded access. With public sharing disabled, request a previously generated public link from an outside browser session and confirm it returns no access. For embedding, send a request to an embedded resource without a valid signed token or guest authentication and confirm the request is rejected rather than rendering the content. Also confirm that the database account Metabase uses cannot write or drop objects. Run those statements only against a non-production copy of the source database, because a failed test that succeeds would change real data. The expected result is a permission error from the database itself, which proves the restriction sits in the database and not only in the application.
Then verify transport and recovery. Check the TLS configuration with a certificate inspection tool and confirm the certificate chain, expiry and host name match the Metabase address. Request the plain HTTP address and confirm it is redirected to HTTPS or refused, not served. For backups, restore the most recent application database backup into a separate instance, start Metabase against that copy, and confirm that users, groups, collections and saved questions are present. A backup that has never been restored is an assumption, not a control.
When a test fails, the expected behavior is that access is denied, no data is returned, and the attempt leaves a trace the reviewer can find. Confirm where your plan records this. Audit and usage analytics are available only on the Pro and Enterprise plans, so on Open Source or Starter the reviewer should rely on the web server, reverse proxy and database logs, and the failed query should be visible in the database's own logs if statement logging is enabled. Confirm with your deployment team which logs are retained, for how long, and who can read them, and write that answer into the test record.
What to monitor, back up, patch and document after go-live
Hardening settings decay without ongoing attention: accounts change, links get created, and versions age out of support. The cards below set out the recurring checks that keep a self-hosted Metabase in the state you approved at go-live, and the evidence that proves it.
Application database backups and restore tests
Metabase stores saved questions, dashboards, permissions, users and configuration in its application database, so that database is the first thing to protect. Schedule regular backups of the PostgreSQL or MySQL instance, and run a restore into a separate environment on a set cadence to confirm the backup is usable. Record who performed each restore test and what they checked.
Version currency and upgrade planning
Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Metabase 64 is an LTS release with end of life on 1 December 2027, so plan the upgrade path to a supported release well before that date. Track the version support page against your running version, and follow the sibling upgrades page for the procedure.
Periodic access reviews
Review user accounts and group memberships on a schedule your organization sets, and confirm that people who left or changed roles have lost their access. Check that group mappings still match your permission model for data and collections, and that admin rights are limited to the people who need them. Keep the review sign-off as evidence for your access control records.
Database credential rotation and sharing status
Each connected data source uses a database account created for Metabase, and those credentials should rotate on the schedule your security policy requires. After each rotation, confirm that Metabase still connects with the least-privilege account and that no unexpected source accounts exist. Also review which saved questions and dashboards have public or embedded links enabled, and remove any that no longer have an owner or purpose.
Security configuration baseline
Document the approved configuration as a baseline: TLS settings, authentication method, permission groups, data and collection permissions, sharing and embedding options, and the application database connection. Compare the running instance against this baseline after each upgrade, configuration change or infrastructure change. Store the baseline under change control so that drift is visible and attributable.
Audit and usage data retention
Decide how long audit and usage data is kept, where it is stored and who can read it, based on your own retention policy and any applicable regulation. Confirm which audit or usage records your edition and plan provide, because some reporting features depend on the paid plan. Test that exported logs or records can be retrieved within the retention window you set.
What buyers ask before hiring help with Metabase security hardening
How much does Metabase security hardening cost to have done?
DeployOpen quotes hardening as a fixed-scope engagement, so the price follows from a written scope. DeployOpen does not publish a price list.
Most of the fee pays for people's time: reviewing the current instance, moving the application database to PostgreSQL where needed, agreeing database credentials with source database owners, setting permissions and collections, configuring TLS, testing, and writing handover documentation. Recurring costs sit outside that fee: hosting, database backups, and the Metabase plan you choose. The Metabase pricing page lists Enterprise by quote starting at $20,000 per year, and Pro at $575 per month or $517.50 per month billed yearly for the first 10 users, with additional users at $12 per month. Ask each quote to separate one-time work from any retainer, and to state which plan the scope assumes.
How long does a Metabase hardening project take to complete?
The timeline depends on scope, so ask for it in the written plan rather than assuming a standard duration.
The main drivers are the number of data sources, whether the instance still uses the embedded H2 application database, how many groups, collections and permission rules already exist, whether SSO is in scope, and how quickly database owners and security reviewers respond. A staging environment that mirrors production shortens testing, and a missing one usually adds time. Changes to a live instance also wait for your change calendar and maintenance windows. Confirm these dependencies early, because most delays come from waiting on people and approvals rather than from configuration work.
What does my team need to provide for the hardening work?
Your team provides access, decisions and approvals, and DeployOpen does the configuration and testing inside your environment.
Expect to provide:
- Source database owners who can create read-only, least-privilege credentials for each connected database.
- Identity and security reviewers who approve group mapping, permission scope, TLS requirements and audit logging.
- A test environment that resembles production, with its own application database.
- Access to the hosts, container platform or cloud account where Metabase runs.
- A named Metabase administrator who makes decisions and accepts the work.
- Change windows for cutover and for any restart of the production instance.
Can our internal team harden Metabase without outside help?
Yes, an internal team can do it if it has Metabase administration experience and database administration skills. Whether it should depends on the gaps in those skills.
The Metabase-specific work covers the permission model, collections, embedding settings and the upgrade procedure. The database work covers creating PostgreSQL roles, granting least-privilege access, enabling TLS on database connections, and testing backup and restore of the application database. Security review covers the threat model and audit requirements. Before deciding, check whether your team has performed a Metabase upgrade and a restore of the application database in the past. If neither has happened, plan for a learning period or a shorter, targeted engagement for the gaps.
Does row-level security in Metabase require a paid plan?
Yes. The Metabase pricing page states that row and column level permissions are included only in the Pro and Enterprise plans, and Open Source and Starter do not include them.
On the free edition, you can still limit exposure through database role grants on each connection, tightly scoped collections and a small set of groups. Those controls work at the database and collection level, so they do not replace Metabase's row-level permission feature. Check the current plan contents on the pricing page before you finalize the design, because plan features change. If row-level security is a requirement, include the plan cost in the comparison with a self-managed workaround.
Does a hardened Metabase instance receive a compliance certification?
No. DeployOpen prepares systems, configuration, controls and evidence for a compliance assessment, but independent auditors issue reports and certification bodies issue certifications.
Evidence typically includes a configuration baseline, access and permission reviews, backup and restore records, change logs, and a mapping of your controls to the systems involved. Ask your auditor which controls they will test and in what form, and agree the evidence format before the work begins. This helps you avoid rebuilding evidence after the fact. DeployOpen can prepare the material for that assessment, but the outcome of the assessment belongs to the auditor.
What happens to hardening settings when we upgrade Metabase later?
Upgrades run application database migrations automatically, so your hardened settings remain in place but need to be re-tested after each upgrade.
Back up the application database before any upgrade. For major upgrades, the Metabase documentation recommends reducing a cluster to a single node because of a migration lock. Upgrades from versions older than 40 should go release by release. Rollback is done by restoring the pre-upgrade application database backup, which the docs recommend, or by running the migrate down command with the newer JAR. Metabase LTS versions are supported for 14 months, so plan upgrade windows around that schedule. Upgrade and support retainers can cover this work after go-live.
How DeployOpen scopes, hardens, hands over and supports Metabase
DeployOpen approaches Metabase security hardening as a fixed-scope engagement inside your own infrastructure, with the scope agreed in writing before work starts. We work through the application database, database credentials, permissions, sharing and embedding controls, TLS and audit options, then document and hand over the configuration so your team can run it.
How we scope
- We review the current Metabase version, deployment type and whether the application database is still the embedded H2 default.
- We agree in writing which data sources, groups, collections, public links and embeds fall inside the hardening scope.
- We confirm which controls your edition supports, since row and column permissions and auditing are limited to paid plans.
How we build
- We move the application database to a production PostgreSQL instance where your scope requires it, using a matched Metabase version.
- We set least-privilege database credentials for each connected source and restrict collection and data permissions to documented groups.
- We configure public sharing and embedding controls, TLS termination and audit options, then test each control against the agreed scope.
How we hand over
- We document the final configuration, including credential ownership, permission groups, sharing settings and TLS certificate handling.
- We provide a verification checklist your team can rerun after upgrades, configuration changes or new data source connections.
- We walk your operators through backup of the application database and the upgrade and rollback steps for your deployment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Retainer work can track Metabase LTS and non-LTS release windows so your instance stays on a supported version.
- Before each upgrade, we can re-check permissions, sharing settings and embedding controls against the hardening baseline.
