Git Sync deployment scenarios on Grafana Labs

Single instance Git Sync

Fri, 03 Apr 2026 12:35:46 -0500

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

Fri, 03 Apr 2026 12:35:46 -0500

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

Fri, 03 Apr 2026 12:35:46 -0500

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.

Git Sync for high availability environments

Fri, 03 Apr 2026 12:35:46 -0500

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

Fri, 03 Apr 2026 12:35:46 -0500

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.