Metabase remote sync with Git

Metabase remote sync with Git: when a dev-to-production analytics workflow is worth running

Analysts who edit dashboards directly in production make changes that nobody reviews, and a wrong filter can reach executives before anyone notices. Metabase Remote Sync addresses this by splitting the work across two instances: analysts build and change content in a read-write Metabase, the changes travel through a Git repository where they can be reviewed, and a read-only production Metabase pulls them in automatically. The feature is available on Pro and Enterprise plans, so the first decision is a licensing one. The question to answer first is whether your production content changes often enough, and matters enough, to justify a second instance and a formal review step.

Remote Sync covers three content types: top-level collections, Library content and transforms. Everything it moves is stored as YAML files that describe analytics content in Git, and no table data travels with them. That makes the repository a readable record of what changed, so a pull request can show a dashboard's cards or a transform's definition being altered. Before you commit, list where your production content lives. Content in personal collections, or content outside top-level collections, will not follow the sync, so it either has to move into a synced collection or be accepted as unmanaged. Confirm the current list of supported content in Metabase's remote sync documentation, because that boundary decides how much of your analytics estate the workflow governs.

The workflow pays off most for teams with several analysts publishing to shared collections that others depend on, such as finance reporting, customer-facing metrics or regulated reports where each change needs a named approver and a record. It is less useful for a small team with one analyst who owns everything, or for an organization whose production dashboards rarely change. Illustrative example: a team edits a revenue dashboard twice a week, and a second analyst approves each edit in a merge request. That team gains an approval trail that direct editing never produced. Teams on the Open Source or Starter plans cannot use the feature, so they should weigh an upgrade against tighter manual change control in the existing setup.

Remote Sync moves much of the risk into the Git repository. Metabase advises treating write access to the repository like admin access, because anyone who can push changes can change what production shows. Decide who can push, who can approve merges and whether protected branches are required before the first sync. Cost has several parts. The Metabase plan is listed on the pricing page at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. The licensing for a second instance and the cost of Git hosting are separate lines that you should confirm with Metabase and your Git provider. Ask any implementation partner for a quote that itemizes Metabase licenses, infrastructure for both instances and the design of the review process.

Configuration choices for Metabase remote sync and when each fits

This table compares the decisions a team makes before enabling Metabase Remote Sync: what content is synced, where the Git repository lives, how changes are reviewed, who can write to the repository, and how the production instance pulls. Read each row as a question to answer for your environment, then check option names and screens against the current Metabase remote sync documentation. The main takeaway is that the repository's write access and review rules carry as much weight as the sync settings themselves.

Decision	When the option fits	Trade-off to weigh
Sync scope: top-level collections	Dashboards, questions and models are organized in a few collections that teams build and promote together.	Only top-level collections are synced, so content must be placed inside them to be carried to production.
Sync scope: Library content	Shared metrics, segments or reusable content are maintained centrally and should move with analytics content.	Library changes affect every collection that uses them, so reviewers need to see those changes explicitly.
Sync scope: transforms	Transforms are built in the development instance and should be promoted with the questions that depend on them.	Transform changes can alter data production, so confirm how they are scheduled and validated before promotion.
Git repository and host	Your organization already runs a self-hosted Git platform with review, audit logging and access controls in place.	The repository becomes a control point for analytics content, so hosting, backups and availability must be planned with the platform team.
Branch and review rules	Changes should pass a peer review and an approval step before the production instance can pull them.	Strict rules slow promotion; confirm which branch production tracks and how merges are approved.
Write access to the repository	A small, named group of engineers or analysts owns promotion, with access reviewed like admin access.	Metabase advises treating write access like admin access, so broad write permissions widen the risk of unreviewed changes.
Production pull configuration	The production instance is read-only and should only reflect reviewed content from the repository.	Confirm how pull frequency and sync status are checked, and who responds when a pull fails.
Development instance access	Analysts build content in a read-write instance that is separate from production users and data.	Keep development and production users separate, since edits made outside Git are not reviewed.

How the Metabase remote sync with Git loop runs from edit to pull

The loop starts when an analyst edits content in the read-write Metabase instance, which is the only place where that content is authored. Consider this illustrative example: an analyst adds a filter to a revenue dashboard inside a top-level collection named Finance Reporting. Remote Sync writes the change as YAML files describing that dashboard and its questions to the configured Git repository. A reviewer then opens a pull request in your Git host, approves it, and the change is merged into the protected branch. The read-only production instance pulls the merged YAML automatically and applies it. Production therefore only receives content that has passed through the repository review step.

Reviewers see the change as a text diff of YAML files. The diff shows the definition of each object, its structure, the questions it contains and how they are arranged, so a reviewer can confirm that the filter matches the approved intent and that the change touches only the collection expected. The diff does not carry query result data, so a reviewer cannot confirm the figures a dashboard will show from the pull request alone. Ask the team to run the changed content in the read-write instance or a staging copy and record the values it produces. Pay close attention to any embedded query text in the YAML, since that is the part most likely to change behavior in ways the layout alone hides.

Data does not travel through Git. Remote Sync stores only YAML files that describe analytics content, so the repository is not a place where warehouse rows are kept. The production instance keeps its own connections to the databases it queries, and those connections and their permissions must be configured there separately. Plan for two consequences. First, the production instance needs database access that matches what its users are allowed to see. Second, anyone with write access to the repository can change what production displays after a merge, which is why Metabase advises treating that write access like admin access. Limit write access to the repository and set branch protection and required reviewers accordingly.

Content outside the sync scope does not follow the loop. Remote Sync covers top-level collections, Library content and transforms. Anything outside those categories stays in the instance where it was created, and a change to it will not reach production through a pull request. Confirm the exact boundary in the Remote Sync documentation for your Metabase version before agreeing on a content layout. Place shared analytics content inside synced locations from the start, so reviewers know which changes they are responsible for reviewing and which changes will never appear in the diff.

Before a pilot, confirm three things. Check that your plan includes Remote Sync, which the supplied documentation places on Pro and Enterprise. Check that your Git host can enforce required reviews on the protected branch. Check how often the production instance pulls and whether it can reach the repository from its network. Name an owner for the merge step and define a rollback path, such as reverting the merge and letting production pull the revert. Test that rollback in a non-production setup, and confirm with your Metabase contact that it restores the previous content in your environment before you rely on it.

Setting up Metabase remote sync with Git step by step

This sequence connects a read-write Metabase, a Git repository and a read-only production Metabase so that analytics content moves through reviewed pull requests. Each step ends with a check you can run before moving on, so problems surface in the lower environment first.

Confirm the plan supports Remote Sync
Before any setup, confirm that both the read-write and the read-only production instances run a Pro or Enterprise plan, since Metabase lists Remote Sync as available only on those plans. Check the current plan on each instance and confirm in the Remote Sync documentation where the feature appears in the admin settings, because menu names can change between releases. Your team (or DeployOpen, if scoped) completes this check. The step is done when both instances show a plan that includes Remote Sync and the settings page exposes the feature.
Prepare the Git repository and branch protection
Create a dedicated repository for Metabase YAML files, separate from application code, and choose the branch that production will pull from. Protect that branch so changes can only arrive through pull requests with at least one approving review, and block force pushes and direct commits to it. Confirm the exact protection options in your Git hosting platform's current documentation. The step is done when a test account attempting a direct push to the protected branch is rejected and a pull request requires approval before merge.
Restrict write access to the repository
Metabase advises treating write access to the Remote Sync repository like admin access, so limit it to the service identity used by the read-write instance and a short list of named reviewers or maintainers. Remove inherited write permissions from broader groups and review deploy keys or tokens, noting who holds each one and how it is rotated. Your security or platform team owns this decision. The step is done when the repository's collaborator and token list matches the approved access list exactly, and nobody outside that list can push to any branch.
Connect the read-write instance to the repository
In the read-write Metabase, open the Remote Sync settings and enter the repository location, the branch, and the authentication method. Confirm the exact connection field names and accepted credential types in the current Remote Sync documentation before entering values, and store any token in your secrets manager rather than in a shared note. Run the connection test the settings page provides. The step is done when the test reports a successful connection and the instance shows the linked repository and branch without errors.
Define the sync scope for content
Decide which content leaves the read-write instance. Remote Sync can sync top-level collections, Library content and transforms, so list the collections that belong in production and leave out personal drafts, sandboxes and experiments. Document the scope in your change record so reviewers know what a pull request is allowed to contain. The step is done when a test collection placed outside the chosen scope does not appear in the exported files, and a collection inside scope does.
Run an initial export and review the pull request
Trigger the first export from the read-write instance using the export control in Remote Sync (confirm the label in the current docs). Remote Sync stores only YAML files describing analytics content, not data, so the commit should contain collection, question, dashboard and transform definitions and no query results or row data. Open the pull request the export creates, read the diff, and have a second reviewer approve it. The step is done when the pull request shows only expected YAML changes, the content matches what you intended to export, and the merge is recorded on the protected branch.
Connect the read-only production instance to pull
In the production Metabase, configure Remote Sync to read from the same repository and branch, and set the instance to read-only mode as the product documentation describes for pull targets (confirm the exact setting name). Trigger or wait for the pull, then confirm the content from the merged pull request appears in production. Also test whether production accepts direct edits to synced content and confirm the behavior in the docs. The step is done when the merged collections and dashboards show up in production and the instance's sync status matches the commit that was merged.
Test a change from build to production
Make a small, clearly labeled change to a dashboard in the read-write instance, export it, and open a pull request with a description of the change. After review and merge, confirm that production pulls the update and displays it, and that the commit history in Git matches what was deployed. Keep the test change in a sandbox collection if your scope allows. The step is done when the change is visible in production, the commit history links the change to a reviewer approval, and you have recorded the result as your baseline for future releases.

Securing the Remote Sync repository and the production instance

Metabase Remote Sync turns the Git repository into the path by which analytics content reaches production, so anyone who can write to it can change what production shows. The controls below cover who can change the repository, how changes are reviewed, how credentials are handled, and how the production instance stays read-only.

Treat repository write access as admin access

Metabase advises treating write access to the Remote Sync repository like admin access. Limit write permission to a short, named list of people who maintain analytics content, and keep it separate from general developer access to the repository. Review that list on a fixed schedule, and confirm which roles on your Git host can push branches, edit settings and change protection rules, since those roles can also alter what reaches production.

Configure branch protection and reviewer rules

The branch that the production instance tracks should be protected so that no one can push to it directly. Require a pull request, require at least one reviewer who did not author the change, and block force pushes and branch deletion on that branch. Confirm the exact setting names and the approval options in your Git host's documentation, because the available controls differ between hosts and plans.

Scope and store repository credentials

The read-write instance and any automation need credentials to read and write the repository. Use a dedicated service account or machine identity rather than a personal token, grant it access only to the Remote Sync repository, and store the token in a secrets manager instead of in configuration files. Confirm how the current Remote Sync documentation expects the connection to be authenticated, and set a rotation schedule for the token.

Stop unreviewed changes reaching production

Because the production instance pulls changes automatically, an approved merge is the only route for new content into production. Check that the production instance follows the protected branch and not a development branch, and that no one can switch its tracked branch without review. Test the flow with a harmless change, such as a dashboard description, to confirm that an unmerged branch never appears in production.

Keep the production instance read-only

The production instance should be set up so that users cannot edit content in the Metabase interface, which would create changes that Git never recorded. Confirm which accounts have admin rights on the production instance and limit those rights to the sync and operations staff. Review the instance's permissions after each Metabase upgrade, because new settings or defaults can change who may edit content.

Audit commits and revoke access promptly

Record who merged each change, when it merged and which pull request approved it, and keep those records with your other access logs. Review the commit history against the list of people with write access on a regular schedule. When someone leaves the team or changes role, remove their repository access, revoke any tokens they created, and check their recent merges. Confirm with your Git host which audit log events it retains and for how long.

What Metabase remote sync and the Git host cost to run

The first cost decision is the Metabase plan, because Remote Sync is available only on Pro and Enterprise. The Open Source and Starter plans cannot run this development-to-production workflow, so budgeting starts at Pro. Ask Metabase in writing whether the read-only production instance also needs a Pro or Enterprise license, and whether the read-write development instance and the production instance each count as a separate deployment. Those answers change the license count before any user is added, so settle them before you sign.

Pro is listed on Metabase's pricing page at $575 per month, or $517.50 per month when billed yearly, with the first 10 users included. Each additional Pro user costs $12 per month at list price. As an illustrative example, a team of 15 users would pay for five additional users at list price, which is $60 per month on top of the base fee. Count seats by role: who edits content in the read-write instance, who only views dashboards in production, and whether automated or service accounts consume a seat. Confirm how the annual rate applies to additional users, since the pricing page's yearly discount is stated for the base fee.

Enterprise is priced by quote, and Metabase's pricing page gives a starting point of $20,000 per year. Treat that figure as a floor for planning, not as a quote for your organization. Move to Enterprise only if a documented requirement, such as a feature or scale need that Pro does not meet, justifies it. Ask the vendor to confirm which features are included at each tier so the comparison rests on your requirements rather than on plan names. The Metabase plan is usually the largest recurring cost in this workflow, so compare it against the Git host and your own operating effort together.

The Git host is the second recurring cost. GitLab's pricing page lists GitLab Free at $0, Premium at $29 per user per month billed annually, and a highest tier that is custom priced. All three are available for self-managed installations, so the subscription can run inside your own infrastructure. Count only the people who push YAML changes or approve merge requests as paid seats, and confirm whether read-only reviewers or service accounts also need one. Premium adds advanced CI/CD and priority support, which matter if pipelines will validate content before merge. GitLab's reference architectures start at 1,000 users, so a small analytics team will usually be sized below them, but confirm this with GitLab.

Prices on both pricing pages change, so check current figures before you budget. Ask for a written quote that lists the plan and edition names, the billing term for each line, the user count basis and per-user rate, the cost of each additional user, and whether each read-only instance needs its own license. For GitLab, ask which tier each seat type requires and how self-managed license terms and renewals work. Also ask about included support, renewal conditions and any price-change clause. Keep infrastructure, backup storage and staff time as separate lines in your own estimate, because the subscriptions do not cover them.

Limits to confirm before you rely on Metabase remote sync

Remote Sync can only be relied on once these six points are answered for your own build and environment. Each card names one limit and a check you can run, usually in a staging pair of instances, before production depends on the workflow.

Plan and version availability

Remote Sync is listed for the Pro and Enterprise plans, so an Open Source or Starter instance cannot use it. Confirm the Metabase version that first ships the feature in your build, and check that your license covers that edition before you plan the rollout. Ask your Metabase account contact or read the release notes for the version you intend to run, and record the answer alongside the upgrade plan for your instances.

Git host support and authentication

Confirm that your Git host is supported for Remote Sync and which authentication methods the connection accepts. Metabase advises treating write access to the Remote Sync repository like admin access, so the credential the instance uses should be limited to that repository, with its rotation owned by your identity team. Test a push and a pull from a staging instance and confirm the credential can be rotated without breaking sync.

Content outside sync scope

Remote Sync covers top-level collections, Library content and transforms, and writes YAML files describing that content to Git. Anything beyond those categories will not be carried through the repository, so list the content types your analysts build and map each one to a sync category or a manual process. Confirm the boundary with a test sync from a staging instance before the workflow depends on it.

Deletions and conflict handling

Confirm how Remote Sync treats an item deleted in Git, an item deleted in the read-write instance, and two edits to the same item made in parallel. These cases decide whether a production instance could lose content on pull. Ask Metabase for the documented behavior for each case, then reproduce all three in a staging pair with a disposable collection and record the result before you agree on a review rule for pull requests.

Fully read-only production instance

Confirm the production instance can be made fully read-only, because the workflow assumes production only receives changes from Git. Check the permission model for every group, along with any API keys that carry write rights and any settings that a user could change outside the sync. Record each path that remains open, assign an owner to it, and decide whether those changes need their own review.

Edits made directly in production

Find out how a pull treats content that someone changed directly in production, since a later sync may overwrite that work or refuse to run. Decide whether direct edits are banned, allowed only in a designated collection, or handled as a review item, and write that rule into the runbook. Test one direct edit on staging followed by a pull, and confirm the result matches the rule before go-live.

Keeping Metabase upgrades and Git host releases from breaking the pipeline

Plan upgrades to both Metabase instances and the GitLab host as one change window, because a release on either side can break the path between the read-write instance, the Git repository and the read-only production instance. Start by recording the Metabase version on each instance and the GitLab version on the host, then check each against its support dates. 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 a team that standardizes on it has a fixed date to plan around. Metabase 65 was released on 12 October 2026, and teams on a non-LTS release should expect to upgrade again on a short cycle.

Before any Metabase upgrade, back up the application database, because each upgrade runs database migrations automatically and the backup is your recovery point. For major upgrades, the Metabase docs recommend reducing a cluster to a single node because of a migration lock, so schedule that step inside the window. Upgrade the read-write instance and the read-only production instance in an order you have confirmed against the Remote Sync documentation for version compatibility. If you are upgrading from a version older than 40, move through each release in sequence. For rollback, the recommended path is restoring the pre-upgrade application database backup, which is faster to reason about than running the migrate down command with the newer JAR.

GitLab adds its own constraints. Since GitLab 17.5, upgrades must pass through required upgrade stops at versions x.2, x.5, x.8 and x.11, such as 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11. Check the upgrade paths documentation for your current version before you schedule the move, because skipping a stop can leave the instance unable to finish its migrations. The maintenance policy also changes how long you can wait. Bug fixes are backported only to the current stable release, while security fixes reach the previous two monthly releases as well. An instance that falls behind may keep receiving security patches but stop receiving bug fixes, so set a target release and a date to reach it rather than letting the host drift between stops.

Test every upgrade on a test instance before touching production. Restore a recent copy of the Metabase application database and a copy of the analytics repository into a separate test environment, then upgrade it in the same order you plan for production. Run a Remote Sync pull and a push from a test branch, and confirm that the collections, Library content and transforms you rely on still appear and still export as expected. Repeat the check on the GitLab test host, including any webhooks, access tokens and CI jobs that touch the repository. Because write access to the Remote Sync repository carries admin-level risk, review who can push and merge after each upgrade, and record the results so the next window starts from a tested runbook.

Metabase remote sync with Git: questions buyers ask before hiring help

Which Metabase plan is required for Remote Sync?

Remote Sync requires a Pro or Enterprise plan, so it is not available on Open Source or Starter. On Metabase's pricing page, Pro is listed at $575 per month, or $517.50 per month billed yearly, and includes the first 10 users, with additional users at $12 per month. Enterprise is priced by quote starting at $20,000 per year. Confirm current prices on the pricing page before budgeting, since list prices can change. The plan decision usually comes first because it sets the licence cost and which features your production instance can use. SSO, row and column permissions, and usage analytics and auditing are also limited to Pro and Enterprise, which often matters more to regulated teams than the sync feature alone.

What drives the cost of a Metabase remote sync project?

Cost comes from three groups: the Metabase plan licence, the infrastructure for a staging instance and your Git host, and the people who do the work. Service fees depend on scope: how many top-level collections, Library items and other supported content you sync, how many environments sit between development and production, whether pull requests run automated checks, and how much existing content must be reorganized into collections before the first sync. Licence fees recur, while design, configuration and the first review cycle are one-time costs. Ongoing costs include reviewer time for each change and upgrade work. When requesting a quote, ask for a fixed scope listing deliverables, environments and assumptions, a split between one-time and recurring items, and the party who holds each licence. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does a Metabase remote sync setup take?

Duration depends on how much existing content needs organizing and how many environments you run, so ask for a schedule by phase rather than a single number. A typical sequence covers discovery of collections and permissions, plan and environment decisions, configuring the read-write instance and the repository, defining the review and merge process, rehearsing a pull into a read-only staging instance, cutting over to production, and handover. Each phase should have a clear exit point. For example, the first full cycle from development through review to a production pull should succeed in staging before anyone relies on it. Fixed-scope engagements agree phases, deliverables and timelines in writing before work starts. Ask the provider which phases depend on your reviewers and approvers, because those waits often set the calendar more than the configuration does.

What must our team provide before remote sync work starts?

Your team needs to provide repository access, a plan decision, named reviewers and a staging instance before configuration begins. Repository access means a Git project your organization administers, plus a service identity or token scoped for Metabase's use. Metabase advises treating write access to the Remote Sync repository like admin access, so decide who holds it before setup. The plan decision confirms Pro or Enterprise on the instance that authors content. Reviewers should be named people who approve changes and understand how a dashboard or collection will change. A staging instance, ideally with an application database that matches production's engine, lets you rehearse pulls safely. You will also need an owner for the read-only production instance and a list of collections in scope. Ask the provider to confirm each dependency in writing.

Can an internal team set up Metabase remote sync without outside help?

Yes, an internal team can do it if it has Metabase administration experience, a working Git review process and a plan that includes Remote Sync. The hardest part is rarely the setting itself. It is agreeing who may write to the repository, how reviews map to Metabase collections, what happens to content someone creates directly in production, and how the team rehearses a failed pull. Internal teams often underestimate the operating side: application database backups, upgrades and periodic access reviews continue after go-live. An outside partner is useful when a skill is missing, when a deadline depends on a regulated review, or when you want an independent check of permissions and secrets handling. Decide which phases your team owns and which it buys, then request a quote that covers only the purchased phases.

Does Metabase Remote Sync copy our data through Git?

No. Remote Sync stores YAML files that describe analytics content, such as collections, Library items and other supported content, in the Git repository. The underlying data stays in the connected databases. The YAML can still reveal useful information. Collection names, query text, database and table references, descriptions and permission-related structure may appear in files that many reviewers can read. Treat the repository as sensitive, restrict who can write to it, and check which content types your version of Metabase exports before the first sync. Confirm that database credentials are configured on the instance and are not written into content files. Ask the provider to show a sample export from your staging instance during the review stage.

What does ongoing support cover after a Metabase remote sync go-live?

Ongoing support covers the operating tasks that keep the sync pipeline reliable after go-live, and it can be arranged as a retainer following a fixed-scope project. Typical scope includes tuning the approval flow, checking that production pulls complete, reviewing who can write to the repository, and planning Metabase upgrades. Upgrade planning matters because LTS releases are supported for 14 months, while non-LTS releases usually reach end of life after 2 months, so your upgrade cadence should match the release track you choose. Support does not replace your own accountability for reviews and approvals. Ask any proposal to state the systems in scope, who holds on-call responsibility, the response expectations that apply, and what is excluded. DeployOpen does not publish a support price list, so request a quote based on the written scope.

How do we upgrade Metabase without breaking remote sync?

Back up the application database first, then upgrade in a sequence your staging instance has already rehearsed. Metabase runs application database migrations automatically during upgrades, so a verified backup is the most reliable rollback path. Restoring the pre-upgrade backup is the documented recommendation, while running the migrate down command with the newer JAR is the alternative. For major upgrades, the documentation recommends reducing a cluster to a single node because of a migration lock, and upgrading release by release if you are coming from a version older than 40. After upgrading the read-only production instance, run a Remote Sync pull and confirm that content matches what reviewers approved. Schedule the window so your reviewers are available, and check the version support page for current LTS and end-of-life dates before choosing a target release.

How DeployOpen scopes, delivers and supports Metabase remote sync

DeployOpen scopes Metabase remote sync with Git as a fixed-scope engagement covering the read-write authoring instance, the Git repository and the read-only production instance. Remote Sync is available on Pro and Enterprise plans, so confirming the plan comes first. Ongoing support is available as a retainer after handover.

How we scope

Confirm your Metabase plan includes Remote Sync, which is available on Pro and Enterprise plans.
Agree which top-level collections, Library content and transforms will move through Git.
Set who may write to the Remote Sync repository, treating that access with the same care as admin access.

How we build

Configure the read-write authoring instance and the read-only production instance on infrastructure you control.
Connect the Git repository and test that YAML changes pull into production automatically.
Design a review flow in Git pull requests so every change is checked before production pulls it.

How we hand over

Document the promotion workflow, branch and review rules, and the people who approve changes.
Explain what Remote Sync carries: YAML files describing analytics content, with no data stored in Git.
Run a supervised promotion with your team so they can repeat the workflow on their own.

How we support

Ongoing support, upgrades and testing are available as a retainer after handover.
Plan Metabase upgrades and sync checks against the release versions your instances run.
Confirm access reviews and backup coverage for the Git host as part of routine operations.