CI/CD automation on Grafana Labs

CI/CD automation

Wed, 15 Jul 2026 16:12:13 +0200

CI/CD automation

What you’ll do in this module:

Pipeline architecture. How plan and apply stages map to pull requests and merges.
GitHub Actions workflow. A complete workflow that plans on PRs and deploys on merge.
Secrets and variables. Securely storing and referencing Grafana credentials in CI/CD.
Reliable deployments. How Terraform state prevents drift, duplicates, and conflicts.
Key takeaways. The most important principles to remember.
Resources. Documentation and references for continued learning.

Estimated time: 15 minutes

CI/CD pipeline architecture

Wed, 15 Jul 2026 16:12:13 +0200

CI/CD pipeline flow

This diagram shows the end-to-end pipeline from code commit to deployed resources.

What each stage does

The pipeline has two stages, each triggered at a different point in the workflow.

Stage	Trigger	Action
Plan	Every push	Show what Terraform will change
Apply	Merge to main only	Deploy changes to Grafana

When each path runs

The same stages run along two paths, depending on where the code is in the workflow:

On a pull request: the pipeline runs plan, then posts the plan as a PR comment for review. Nothing is deployed yet.
On merge to main: the pipeline runs plan and apply. Terraform applies the changes, so the resources in Grafana always reflect the latest code on main.

The review gate

The Terraform plan output is posted as a PR comment so you can see:

Which resources will be created, updated, or destroyed
Exactly what configuration will change

This gives you the full benefits of resources as code: every change is reviewed, every deployment is automated, and you can trace any resource back to the commit that produced it.

GitHub Actions workflow

Wed, 15 Jul 2026 16:12:13 +0200

Complete workflow

You can deploy resources with a single terraform apply. But if someone still has to remember to run that command after every change, you haven’t removed the human bottleneck. Now you’ll automate the full resource lifecycle with GitHub Actions.

This workflow plans and deploys your Grafana resources. It runs in two cases: when you open or update a pull request, and when commits are pushed to main. On a pull request, it runs plan to preview the changes. On a push to main, it also runs apply to deploy them.

name: Deploy Grafana Resources

on:
  push:
    branches: [main]
  pull_request:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan -input=false -no-color

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve
        env:
          GRAFANA_AUTH: ${{ secrets.GRAFANA_TOKEN }}

Step breakdown

Each step in the workflow handles one stage of the plan-apply pipeline.

Step	Purpose
Checkout	Access your repository code
Setup Terraform	Install the Terraform CLI
Terraform Init	Download the Grafana provider
Plan/Apply	Preview or deploy resource changes

The if: github.ref == 'refs/heads/main' condition on the apply step gates deployment: plan runs on every push, but apply runs only when changes land on main. Pull requests get a plan preview without deploying anything.

Alternative CI systems

You can adapt this to other CI systems (GitLab CI, CircleCI, Jenkins) by translating the same four steps. Your Terraform configuration stays the same regardless of which CI tool runs it.

Secrets and variables

Wed, 15 Jul 2026 16:12:13 +0200

What you need

Your pipeline must authenticate to Grafana without exposing credentials in code. GitHub Actions provides two mechanisms: secrets for sensitive values and variables for non-sensitive configuration. You need three values: one secret and two variables.

Value	What it is	Type	Where to store
GRAFANA_TOKEN	Service account token that authenticates the pipeline to Grafana	Secret	Repository secrets
GRAFANA_SERVER	Your Grafana instance URL, for example `https://your-stack.grafana.net`	Variable	Repository variables
GRAFANA_STACK_ID	Your Grafana stack identifier	Variable	Repository variables

Add and reference your credentials

Store the three values in your repository, then reference them from your workflow.

In your repository, go to Settings > Secrets and variables > Actions.
On Repository secrets, add GRAFANA_TOKEN with your service account token. Never commit this token to your repository.
On Repository variables, add GRAFANA_SERVER and GRAFANA_STACK_ID.
Reference the secret with the secrets context and the variables with the vars context.

env:
  GRAFANA_SERVER: ${{ vars.GRAFANA_SERVER }}
  GRAFANA_STACK_ID: ${{ vars.GRAFANA_STACK_ID }}
  GRAFANA_TOKEN: ${{ secrets.GRAFANA_TOKEN }}

Authenticate Terraform

Pass authentication to the Terraform provider through environment variables or directly in the provider block. Set TF_VAR_grafana_url and TF_VAR_grafana_token as environment variables, and Terraform picks them up automatically. The environment variable approach keeps your Terraform code portable: the same configuration works locally and in CI.

provider "grafana" {
  url  = var.grafana_url
  auth = var.grafana_token
}

Reliable, repeatable deployments

Wed, 15 Jul 2026 16:12:13 +0200

How Terraform handles existing resources

A reliable pipeline produces the same result no matter how many times you run it, with no duplicate resources and no errors. Terraform ensures this with a state file: a record of the resources it has created. On each run, Terraform decides what to change by comparing three things:

Your configuration
The state file
What actually exists in Grafana

When a live resource no longer matches your code (for example, someone edited an alert threshold in the UI), that difference is called drift. Because of this, you can safely retry failed runs and merge to main repeatedly without creating duplicates.

Scenario	What Terraform does
Resource doesn’t exist	Creates it and records in state
Resource exists and matches	No changes needed
Resource was edited manually	Detects drift, restores code-defined version

Singleton resources

Some Grafana resources, like the notification policy tree, exist as a single instance. Terraform handles these correctly: it updates the existing policy tree in place rather than trying to create a second one. This means your pipeline can safely manage the full alerting pipeline, including the notification policy, without conflicts.

Safe retries

The practical benefit of state management: you can rerun your pipeline as many times as you want. Failed runs can be retried safely. Multiple merges to main won’t create duplicate alert rules or contact points. And manual edits in the UI get corrected on the next pipeline run.

Key takeaways

Wed, 15 Jul 2026 16:12:13 +0200

Principles to remember

Grafana resources deserve Infrastructure as Code rigor. Version control, review, and automation produce a solid observability experience.
Terraform’s state management prevents drift. The state file ensures manual UI edits are corrected on the next pipeline run.
The alerting pipeline has three parts. Rule groups, contact points, and notification policies work together as a unit.
The pipeline is the source of truth. Code on main equals what’s deployed.

Resources

Wed, 15 Jul 2026 16:12:13 +0200

Documentation

Grafana Terraform provider: all available resources and data sources
Provision alerting resources with Terraform: the canonical guide for managing alerting resources with the Grafana Terraform provider
Infrastructure as Code with Terraform: guides for managing Grafana Cloud resources
Observability as Code overview: all as-code tools and approaches
Grafana Alerting: alert rules, contact points, notification policies
Export alerting resources: export existing alert rules, contact points, and policies to Terraform HCL

Tools and references

Create and manage a Grafana Cloud stack using Terraform: end-to-end stack setup with Terraform
provisioning-alerting-examples repository: working Terraform examples for alerting resources

Learning paths

Deploy an alert rule with Terraform: hands-on learning path for deploying a complete alerting pipeline with Terraform
Configure Grafana with Terraform: broader learning path covering dashboards, alerts, RBAC, and more

Dashboards as Code with the Foundation SDK: define dashboards programmatically and deploy them with Terraform

Thank you

Wed, 15 Jul 2026 16:12:13 +0200

Congratulations!

You’ve completed Deploy Grafana Resources as Code with Terraform.

Next steps

Multi-environment deployment. Use Terraform workspaces to manage staging and production resources from the same code.
Expand scope. Add dashboards, data sources, and folders to your Terraform configuration.
Dashboards as code. Use the Foundation SDK to define dashboards programmatically and deploy them with the same pipeline.
Team adoption. Share your pipeline with your team and establish resources-as-code as a standard practice.

CI/CD automation on Grafana Labs

CI/CD automation

CI/CD automation

CI/CD pipeline architecture

CI/CD pipeline flow

What each stage does

When each path runs

The review gate

GitHub Actions workflow

Complete workflow

Step breakdown

Alternative CI systems

Secrets and variables

What you need

Add and reference your credentials

Authenticate Terraform

Reliable, repeatable deployments

How Terraform handles existing resources

Singleton resources

Safe retries

Key takeaways

Principles to remember

Resources

Documentation

Tools and references

Learning paths

Related journeys

Thank you

Congratulations!

Next steps

Happy coding!