Git Sync deployment scenarios on Grafana Labs

Single instance Git Sync

Tue, 18 Aug 2026 10:15:08 +0000

Single instance Git Sync

Use a single Grafana instance synchronized with a Git repository. This is the foundation for Git Sync and helps you understand bidirectional synchronization.

Use it for

Getting started: You want to learn how Git Sync works before implementing complex scenarios.
Personal projects: Individual developers manage their own dashboards.
Small teams: You have a simple setup without multiple environments or complex workflows.
Development environments: You need quick prototyping and testing.

Architecture

┌─────────────────────────────────────────────────────┐
│           GitHub Repository                         │
│   Repository: your-org/grafana-manifests          │
│   Branch: main                                      │
│                                                     │
│   grafana-manifests/                              │
│   └── grafana/                                     │
│       ├── dashboard-1.json                         │
│       ├── dashboard-2.json                         │
│       └── dashboard-3.json                         │
└─────────────────────────────────────────────────────┘
                        ↕
              Git Sync (bidirectional)
                        ↕
        ┌─────────────────────────────┐
        │    Grafana Instance         │
        │                             │
        │  Repository Resource:       │
        │  - url: grafana-manifests  │
        │  - branch: main             │
        │  - path: grafana/           │
        │                             │
        │  Creates folder:            │
        │  "grafana-manifests"       │
        └─────────────────────────────┘

Repository structure

In Git:

your-org/grafana-manifests
└── grafana/
    ├── dashboard-1.json
    ├── dashboard-2.json
    └── dashboard-3.json

In Grafana Dashboards view:

Dashboards
└── 📁 grafana-manifests/
    ├── Dashboard 1
    ├── Dashboard 2
    └── Dashboard 3

A folder named “grafana-manifests” (from repository name) contains all synced dashboards.
Each JSON file becomes a dashboard with its title displayed in the folder.
Users browse dashboards organized under this folder structure.

Configuration parameters

Configure your Grafana instance to synchronize with:

Repository: your-org/grafana-manifests
Branch: main
Path: grafana/

How it works

From Grafana to Git: When users create or modify dashboards in Grafana, Git Sync commits changes to the grafana/ directory on the main branch.
From Git to Grafana: When dashboard JSON files are added or modified in the grafana/ directory, Git Sync pulls these changes into Grafana.

Git Sync for development and production environments

Tue, 18 Aug 2026 10:15:08 +0000

Git Sync for development and production environments

Use separate Grafana instances for development and production. Each syncs with different Git locations to test dashboards before production.

Use it for

Staged deployments: You need to test dashboard changes before production deployment.
Change control: You require approvals before dashboards reach production.
Quality assurance: You verify dashboard functionality in a non-production environment.
Risk mitigation: You minimize the risk of breaking production dashboards.

Architecture

┌────────────────────────────────────────────────────────────┐
│              GitHub Repository                             │
│   Repository: your-org/grafana-manifests                 │
│   Branch: main                                             │
│                                                            │
│   grafana-manifests/                                     │
│   ├── dev/                                                │
│   │   ├── dashboard-new.json    ← Development dashboards │
│   │   └── dashboard-test.json                            │
│   │                                                       │
│   └── prod/                                               │
│       ├── dashboard-stable.json  ← Production dashboards │
│       └── dashboard-approved.json                        │
└────────────────────────────────────────────────────────────┘
           ↕                                 ↕
    Git Sync (dev/)              Git Sync (prod/)
           ↕                                 ↕
┌─────────────────────┐          ┌─────────────────────┐
│  Dev Grafana        │          │  Prod Grafana       │
│                     │          │                     │
│  Repository:        │          │  Repository:        │
│  - path: dev/       │          │  - path: prod/      │
│                     │          │                     │
│  Creates folder:    │          │  Creates folder:    │
│  "grafana-manifests"│         │  "grafana-manifests"│
└─────────────────────┘          └─────────────────────┘

Repository structure

In Git:

your-org/grafana-manifests
├── dev/
│   ├── dashboard-new.json
│   └── dashboard-test.json
└── prod/
    ├── dashboard-stable.json
    └── dashboard-approved.json

In Grafana Dashboards view:

Dev instance:

Dashboards
└── 📁 grafana-manifests/
    ├── New Dashboard
    └── Test Dashboard

Prod instance:

Dashboards
└── 📁 grafana-manifests/
    ├── Stable Dashboard
    └── Approved Dashboard

Both instances create a folder named “grafana-manifests” (from repository name)
Each instance only shows dashboards from its configured path (dev/ or prod/)
Dashboards appear with their titles from the JSON files

Configuration parameters

Development:

Repository: your-org/grafana-manifests
Branch: main
Path: dev/

Production:

Repository: your-org/grafana-manifests
Branch: main
Path: prod/

How it works

Developers create and modify dashboards in development.
Git Sync commits changes to dev/.
You review changes in Git.
You promote approved dashboards from dev/ to prod/.
Production syncs from prod/.
Production dashboards update.

Alternative: Use branches

Instead of using different paths, you can configure instances to use different branches:

Development instance:

Repository: your-org/grafana-manifests
Branch: develop
Path: grafana/

Production instance:

Repository: your-org/grafana-manifests
Branch: main
Path: grafana/

With this approach:

Development changes go to the develop branch
Use Git merge or pull request workflows to promote changes from develop to main
Production automatically syncs from the main branch

Alternative: Use separate repositories for stricter isolation

For stricter isolation, use completely separate repositories:

Development instance:

Repository: your-org/grafana-manifests-dev
Branch: main
Path: grafana/

Production instance:

Repository: your-org/grafana-manifests-prod
Branch: main
Path: grafana/

Git Sync with regional replication

Tue, 18 Aug 2026 10:15:08 +0000

Git Sync with regional replication

Deploy multiple Grafana instances across regions. Synchronize them with the same Git location to ensure consistent dashboards everywhere.

Use it for

Geographic distribution: You deploy Grafana close to users in different regions.
Latency reduction: Users need fast dashboard access from their location.
Data sovereignty: You keep dashboard data in specific regions.
High availability: You need dashboard availability across regions.
Consistent experience: All users see the same dashboards regardless of region.

Architecture

┌─────────────────────────────────────────────────────┐
│           GitHub Repository                         │
│   Repository: your-org/grafana-manifests          │
│   Branch: main                                      │
│                                                     │
│   grafana-manifests/                              │
│   └── shared/                                      │
│       ├── dashboard-global.json                    │
│       ├── dashboard-metrics.json                   │
│       └── dashboard-logs.json                      │
└─────────────────────────────────────────────────────┘
              ↕                           ↕
       Git Sync (shared/)         Git Sync (shared/)
              ↕                           ↕
┌────────────────────┐          ┌────────────────────┐
│  US Region         │          │  EU Region         │
│  Grafana           │          │  Grafana           │
│                    │          │                    │
│  Repository:       │          │  Repository:       │
│  - path: shared/   │          │  - path: shared/   │
└────────────────────┘          └────────────────────┘

Repository structure

In Git:

your-org/grafana-manifests
└── shared/
    ├── dashboard-global.json
    ├── dashboard-metrics.json
    └── dashboard-logs.json

In Grafana Dashboards view (all regions):

Dashboards
└── 📁 grafana-manifests/
    ├── Global Dashboard
    ├── Metrics Dashboard
    └── Logs Dashboard

All regional instances (US, EU, etc.) show identical folder structure
Same folder name “grafana-manifests” in every region
Same dashboards synced from the shared/ path appear everywhere
Users in any region see the exact same dashboards with the same titles

Configuration parameters

All regions:

Repository: your-org/grafana-manifests
Branch: main
Path: shared/

How it works

All regional instances pull dashboards from shared/.
Any region’s change commits to Git.
Other regions pull updates during the next sync (or via webhooks).
Changes propagate across regions per sync interval.

Considerations

Write conflicts: If users in different regions modify the same dashboard simultaneously, Git uses last-write-wins.
Primary region: Consider designating one region as the primary location for making dashboard changes.
Propagation time: Changes propagate to all regions within the configured sync interval, or instantly if webhooks are configured.
Network reliability: Ensure all regions have reliable connectivity to the Git repository.

Testing sandboxes Git Sync

Tue, 18 Aug 2026 10:15:08 +0000

Testing sandboxes with Git Sync

Use a sandbox branch that users can push to directly, without opening a pull request for every change. A sandbox branch is a low-friction space for short-lived projects and experimentation, while keeping every dashboard version-controlled in Git. When work is ready, you promote it to the main branch.

A sandbox is a branch in the same repository, synced to Grafana with the write workflow enabled. With the write workflow, saving a dashboard commits directly to the sandbox branch, so the editing experience feels close to using Grafana without Git Sync. The difference is that every change is still committed to Git, so nothing is lost and history is preserved.

This scenario uses a single shared sandbox branch that everyone works in. A shared sandbox uses only one Repository connection regardless of how many users work in it, which keeps you well within the per-stack limit of 10 repository connections. If you need stricter isolation, you can instead give each user their own sandbox branch. Refer to Individual or shared sandboxes.

Use it for

Short-lived projects: You need a temporary space for work that may or may not reach production.
Shared experimentation: A team experiments freely in one space without affecting shared production dashboards.
Fast iteration: You want the low-friction editing of a non-provisioned instance, but with the safety of Git history.
Staged promotion: You develop in a sandbox, then promote finished work to the main branch.

Architecture

┌────────────────────────────────────────────────────────────┐
│              GitHub Repository                             │
│   Repository: your-org/grafana-manifests                 │
│                                                            │
│   Branch: main       ← Promoted, reviewed work            │
│   └── grafana/                                             │
│       ├── dashboard-stable.json                            │
│       └── dashboard-approved.json                          │
│                                                            │
│   Branch: sandbox    ← Direct pushes, shared experiments  │
│   └── grafana/                                             │
│       ├── alice/dashboard-wip.json                         │
│       └── bob/dashboard-test.json                          │
└────────────────────────────────────────────────────────────┘
                        ↕
              Git Sync (write workflow)
                        ↕
              ┌─────────────────────────┐
              │    Grafana Instance     │
              │                         │
              │  Repository Resource:   │
              │  - branch: sandbox      │
              │  - path: grafana/       │
              │  - workflows: [write]   │
              │                         │
              │  Save = direct commit   │
              │  to sandbox             │
              └─────────────────────────┘

Repository structure

In Git:

your-org/grafana-manifests
├── (branch: main)
│   └── grafana/
│       ├── dashboard-stable.json
│       └── dashboard-approved.json
└── (branch: sandbox)
    └── grafana/
        ├── alice/
        │   └── dashboard-wip.json
        └── bob/
            └── dashboard-test.json

In Grafana Dashboards view (synced to sandbox):

Dashboards
└── 📁 grafana-manifests/
    ├── 📁 alice/
    │   └── Work in Progress Dashboard
    └── 📁 bob/
        └── Test Dashboard

A folder named “grafana-manifests” (from the repository name) contains the dashboards synced from the sandbox branch.
Users can create subfolders inside it, such as alice/ and bob/, to keep their work separate within the shared branch. Subfolders map to subdirectories under the synced path, so no extra Repository connection is needed.
Only dashboards on the configured branch and path appear in the instance.
Saving a dashboard commits directly to the sandbox branch.

Configuration parameters

Configure the Repository resource to sync with the sandbox branch and enable the write workflow:

Repository: your-org/grafana-manifests
Branch: sandbox
Path: grafana/
Workflows: write

In the Repository resource, this looks like:

spec:
  github:
    url: 'https://github.com/your-org/grafana-manifests'
    branch: 'sandbox'
    path: grafana/
  workflows:
    - write

Note
If you enable only the write workflow, saving a dashboard always commits directly to the sandbox branch. To also allow users to open pull requests from Grafana, add the branch workflow: workflows: [write, branch]. Refer to Configuration parameters for details.

How it works

Create a sandbox branch in your repository, for example sandbox.
Configure a Repository resource that syncs that branch with the write workflow enabled.
Users create and edit dashboards in Grafana, optionally in their own subfolder. Each save commits directly to the sandbox branch.
The experience feels similar to using Grafana without Git Sync, but every change is committed to Git.
When work is ready, you promote it to the main branch. Refer to Promote a sandbox to main.

Individual or shared sandboxes

A sandbox can be shared by everyone or scoped to a single user. Each sandbox is a branch synced through its own Repository connection, so the choice is shaped by the per-stack limit of 10 repository connections. Refer to Usage and performance limitations for details.

Shared sandbox (recommended): Use a single branch, such as sandbox, synced through one Repository connection that all users share. This uses only one connection regardless of how many users work in it, so it scales to any number of users. Separate users’ work with subfolders (for example, alice/, bob/) if you want some organization within the shared branch. The trade-off is less isolation, since everyone commits to the same branch. This is the setup described above.
Individual sandboxes: Give each user their own branch, such as sandbox/alice and sandbox/bob, each synced through a separate Repository connection. This provides the most isolation, but every sandbox consumes one of your 10 connections, so per-user sandboxes don’t scale to many users. Reserve them for a small number of active users or short-lived projects, and delete the branch and its connection when the work is done to free the connection.

Both approaches promote to main the same way. Refer to Promote a sandbox to main.

Protect sandbox branches

Even though sandbox branches allow direct pushes, protect them against destructive operations. We recommend blocking force pushes on sandbox branches in your Git provider.

Force pushes rewrite branch history and can silently discard commits that Git Sync relies on. Blocking them keeps history append-only, so Grafana and Git stay consistent and you can always trace how a dashboard reached its current state.

GitHub: Add a branch protection rule (or ruleset) for the sandbox branch (for example, sandbox or the pattern sandbox/* if you use individual sandboxes) and disable Allow force pushes.
GitLab: Set the sandbox branches as protected and disallow force push.
Bitbucket: Add a branch permission for the sandbox branch that prevents rewriting history.

You typically keep pull requests optional on sandbox branches so users can push directly, while still blocking force pushes.

Promote a sandbox to main

When sandbox work is ready, promote it to the main branch. Because everything already lives in Git, promotion is a standard Git operation. Choose the option that fits your review requirements:

Option 1: Open a pull request from the sandbox branch (recommended)

Use your Git provider to open a pull request from the sandbox branch into main.

In your Git provider, open a pull request from sandbox into main.
Review the changes as a normal Git diff and request approvals as needed.
Merge the pull request. The instance syncing main picks up the promoted dashboards on its next sync.

This keeps a full review and audit trail for everything that reaches main, and is the recommended path when main feeds production.

If you also enable the branch workflow on the sandbox Repository resource, users can open these pull requests directly from Grafana when they save, instead of switching to the Git provider.

Option 2: Cherry-pick or merge selected changes

When only some dashboards are ready, promote them selectively instead of merging the whole branch.

Cherry-pick the relevant commits from the sandbox branch onto a branch based on main, or copy the specific dashboard files.
Open a pull request into main and review it.
Merge to complete the promotion.

Use this when a shared sandbox contains a mix of finished and experimental work.

Option 3: Promote through a separate instance or path

When main is synced to a production instance, treat the sandbox as the development stage of a promotion flow.

Develop in the sandbox instance (synced to the sandbox branch with the write workflow).
Promote approved dashboards to main using a pull request (Option 1) or by copying files into the main path.
The production instance syncing main updates automatically.

This mirrors the development and production environments scenario, with the sandbox branch acting as the development stage.

Option 4: Promote from the Grafana UI

If the main branch is synced to a folder in the same instance (through a second Repository connection) or to a separate instance, users can move a dashboard into it directly from Grafana, without touching Git:

Save a copy: Open the sandbox dashboard, select Save as (save a copy), and choose the folder backed by the main branch as the destination. Git Sync commits the copy to main.
Import dashboard: Export the dashboard from the sandbox (Export as JSON), then use Dashboards > New > Import and save it into the folder backed by the main branch. Git Sync commits it to main.

This suits users who prefer working entirely in the UI. Note that these paths commit to main without a pull request, so use them only when main allows direct writes; when main requires review, prefer Option 1.

After promotion, you can delete short-lived sandbox branches, or keep a long-lived shared sandbox and continue iterating.

Learn more

Refer to the following documents to learn more:

Git Sync for high availability environments

Tue, 18 Aug 2026 10:15:08 +0000

Git Sync for high availability environments

Primary–replica scenario

Use a primary Grafana instance and one or more replicas synchronized with the same Git location to enable failover.

Use it for

Automatic failover: You need service continuity when the primary instance fails.
High availability: Your organization requires guaranteed dashboard availability.
Simple HA setup: You want high availability without the complexity of active–active.
Maintenance windows: You perform updates while another instance serves traffic.
Business continuity: Dashboard access can’t tolerate downtime.

Architecture

┌─────────────────────────────────────────────────────┐
│           GitHub Repository                         │
│   Repository: your-org/grafana-manifests          │
│   Branch: main                                      │
│                                                     │
│   grafana-manifests/                              │
│   └── shared/                                      │
│       ├── dashboard-metrics.json                   │
│       ├── dashboard-alerts.json                    │
│       └── dashboard-logs.json                      │
└─────────────────────────────────────────────────────┘
              ↕                           ↕
        Git Sync (shared/)        Git Sync (shared/)
              ↕                           ↕
┌────────────────────┐          ┌────────────────────┐
│  Master Grafana    │          │  Replica Grafana   │
│    (Active)        │          │    (Standby)       │
│                    │          │                    │
│  Repository:       │          │  Repository:       │
│  - path: shared/   │          │  - path: shared/   │
└────────────────────┘          └────────────────────┘
         │                               │
         └───────────┬───────────────────┘
                     ↓
          ┌──────────────────────┐
          │  Reverse Proxy       │
          │  (Failover)          │
          └──────────────────────┘

Repository structure

In Git:

your-org/grafana-manifests
└── shared/
    ├── dashboard-metrics.json
    ├── dashboard-alerts.json
    └── dashboard-logs.json

In Grafana Dashboards view (both instances):

Dashboards
└── 📁 grafana-manifests/
    ├── Metrics Dashboard
    ├── Alerts Dashboard
    └── Logs Dashboard

Master and replica instances show identical folder structure.
Both sync from the same shared/ path.
Reverse proxy routes traffic to master (active) instance.
If master fails, proxy automatically fails over to replica (standby).
Users see the same dashboards regardless of which instance is serving traffic.

Configuration parameters

Both master and replica instances use identical parameters:

Master instance:

Repository: your-org/grafana-manifests
Branch: main
Path: shared/

Replica instance:

Repository: your-org/grafana-manifests
Branch: main
Path: shared/

How it works

Both instances stay synchronized through Git.
Reverse proxy routes traffic to primary.
Users edit on primary. Git Sync commits changes.
Both instances pull latest changes to keep replica in sync.
On primary failure, proxy fails over to replica.

Failover considerations

Health checks and monitoring.
Continuous syncing to minimize data loss.
Plan failback (automatic or manual).

Load balancer scenario

Run multiple active Grafana instances behind a load balancer. All instances sync from the same Git location.

Use it for

High traffic: Your deployment needs to handle significant user load.
Load distribution: You want to distribute user requests across instances.
Maximum availability: You need service continuity during maintenance or failures.
Scalability: You want to add instances as load increases.
Performance: Users need fast response times under heavy load.

Architecture

┌─────────────────────────────────────────────────────┐
│           GitHub Repository                         │
│   Repository: your-org/grafana-manifests          │
│   Branch: main                                      │
│                                                     │
│   grafana-manifests/                              │
│   └── shared/                                      │
│       ├── dashboard-metrics.json                   │
│       ├── dashboard-alerts.json                    │
│       └── dashboard-logs.json                      │
└─────────────────────────────────────────────────────┘
              ↕                           ↕
        Git Sync (shared/)        Git Sync (shared/)
              ↕                           ↕
┌────────────────────┐          ┌────────────────────┐
│  Grafana Instance 1│          │  Grafana Instance 2│
│    (Active)        │          │    (Active)        │
│                    │          │                    │
│  Repository:       │          │  Repository:       │
│  - path: shared/   │          │  - path: shared/   │
└────────────────────┘          └────────────────────┘
         │                               │
         └───────────┬───────────────────┘
                     ↓
          ┌──────────────────────┐
          │  Load Balancer       │
          │  (Round Robin)       │
          └──────────────────────┘

Repository structure

In Git:

your-org/grafana-manifests
└── shared/
    ├── dashboard-metrics.json
    ├── dashboard-alerts.json
    └── dashboard-logs.json

In Grafana Dashboards view (all instances):

Dashboards
└── 📁 grafana-manifests/
    ├── Metrics Dashboard
    ├── Alerts Dashboard
    └── Logs Dashboard

All instances show identical folder structure.
All instances sync from the same shared/ path.
Load balancer distributes requests across all active instances.
Any instance can serve read requests.
Any instance can accept dashboard modifications.
Changes propagate to all instances through Git.

Configuration parameters

All instances use identical parameters:

Instance 1:

Repository: your-org/grafana-manifests
Branch: main
Path: shared/

Instance 2:

Repository: your-org/grafana-manifests
Branch: main
Path: shared/

How it works

All instances stay synchronized through Git.
Load balancer distributes incoming traffic across all active instances.
Users can view dashboards from any instance.
When a user modifies a dashboard on any instance, Git Sync commits the change.
All other instances pull the updated dashboard during their next sync cycle, or instantly if webhooks are configured.
If one instance fails, load balancer stops routing traffic to it and remaining instances continue serving.

Important considerations

Eventually consistent: Due to sync intervals, instances may briefly have different dashboard versions.
Concurrent edits: Multiple users editing the same dashboard on different instances can cause conflicts.
Database sharing: Instances should share the same backend database for user sessions, preferences, and annotations.
Stateless design: Design for stateless operation where possible to maximize load balancing effectiveness.

Multiple team Git Sync

Tue, 18 Aug 2026 10:15:08 +0000

Git Sync in a Grafana instance shared by multiple teams

Use a single Grafana instance with multiple Repository resources, one per team. Each team manages its own dashboards while sharing Grafana.

Use it for

Team autonomy: Different teams manage their own dashboards independently.
Organizational structure: Dashboard organization aligns with team structure.
Resource efficiency: Multiple teams share Grafana infrastructure.
Cost optimization: You reduce infrastructure costs while maintaining team separation.
Collaboration: Teams can view each other’s dashboards while managing their own.

Architecture

┌─────────────────────────┐  ┌─────────────────────────┐
│  Platform Team Repo     │  │  Data Team Repo         │
│  platform-dashboards    │  │  data-dashboards        │
│                         │  │                         │
│  platform-dashboards/   │  │  data-dashboards/       │
│  └── grafana/           │  │  └── grafana/           │
│      ├── k8s.json       │  │      ├── pipeline.json  │
│      └── infra.json     │  │      └── analytics.json │
└─────────────────────────┘  └─────────────────────────┘
           ↕                            ↕
    Git Sync (grafana/)          Git Sync (grafana/)
           ↕                            ↕
        ┌──────────────────────────────────────┐
        │       Grafana Instance               │
        │                                      │
        │  Repository 1:                       │
        │  - repo: platform-dashboards         │
        │  → Creates "platform-dashboards"     │
        │                                      │
        │  Repository 2:                       │
        │  - repo: data-dashboards             │
        │  → Creates "data-dashboards"         │
        └──────────────────────────────────────┘

Repository structure

In Git (separate repositories):

Platform team repository:

your-org/platform-dashboards
└── grafana/
    ├── dashboard-k8s.json
    └── dashboard-infra.json

Data team repository:

your-org/data-dashboards
└── grafana/
    ├── dashboard-pipeline.json
    └── dashboard-analytics.json

In Grafana Dashboards view:

Dashboards
├── 📁 platform-dashboards/
│   ├── Kubernetes Dashboard
│   └── Infrastructure Dashboard
└── 📁 data-dashboards/
    ├── Pipeline Dashboard
    └── Analytics Dashboard

Two separate folders created (one per Repository resource).
Folder names derived from repository names.
Each team has complete control over their own repository.
Teams can independently manage permissions, branches, and workflows in their repos.
All teams can view each other’s dashboards in Grafana but manage only their own.

Configuration parameters

Platform team repository:

Repository: your-org/platform-dashboards
Branch: main
Path: grafana/

Data team repository:

Repository: your-org/data-dashboards
Branch: main
Path: grafana/

How it works

Each team has their own Git repository for complete autonomy.
Each repository resource in Grafana creates a separate folder.
Platform team dashboards sync from your-org/platform-dashboards repository.
Data team dashboards sync from your-org/data-dashboards repository.
Teams can independently manage their repository settings, access controls, and workflows.
All teams can view each other’s dashboards in Grafana but edit only their own.

Scale to more teams

Adding additional teams is straightforward. For a third team, create a new repository and configure:

Repository: your-org/security-dashboards
Branch: main
Path: grafana/

This creates a new “security-dashboards” folder in the same Grafana instance.

Alternative: Shared repository with different paths

For teams that prefer sharing a single repository, use different paths to separate team dashboards:

In Git:

your-org/grafana-manifests
├── team-platform/
│   ├── dashboard-k8s.json
│   └── dashboard-infra.json
└── team-data/
    ├── dashboard-pipeline.json
    └── dashboard-analytics.json

Configuration:

Platform team:

Repository: your-org/grafana-manifests
Branch: main
Path: team-platform/

Data team:

Repository: your-org/grafana-manifests
Branch: main
Path: team-data/

This approach provides simpler repository management but less isolation between teams.

Alternative: Different branches per team

For teams wanting their own branch in a shared repository:

Platform team:

Repository: your-org/grafana-manifests
Branch: team-platform
Path: grafana/

Data team:

Repository: your-org/grafana-manifests
Branch: team-data
Path: grafana/

This allows teams to use Git branch workflows for collaboration while sharing the same repository.