---
title: Manage dashboards as code
description: Version-control Kibana dashboards and deploy them across spaces, clusters, and stages using the dashboards API and Git-based review workflows.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7029/explore-analyze/dashboards/manage-dashboards-as-code
products:
  - Kibana
applies_to:
  - Elastic Cloud Serverless: Preview
  - Elastic Stack: Preview since 9.4
---

# Manage dashboards as code
Treat dashboards as version-controlled artifacts that live in Git alongside the rest of your infrastructure code. The [dashboards API](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7029/explore-analyze/dashboards/create-dashboards-programmatically) produces a clean, diffable JSON definition, so you can review dashboard changes in pull requests and promote them across environments through automated pipelines, the same way you manage data views, alerting rules, or any other resource.
This workflow suits teams that want repeatable, auditable dashboard changes instead of manual edits in the UI. If you only need to move a dashboard between environments once, [exporting it as NDJSON](/elastic/docs-content/pull/7029/explore-analyze/dashboards/sharing#export-ndjson) and [importing it](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7029/explore-analyze/dashboards/import-dashboards) is simpler.

## Workflow

1. **Export** the dashboard definition. From a dashboard, [export it as dashboards API-compatible JSON](/elastic/docs-content/pull/7029/explore-analyze/dashboards/sharing#export-dashboard-json). The result is a clean JSON document that contains the panels, controls, and display options, without the internal state that makes raw saved objects hard to read.
2. **Store** the definition in Git. Commit the JSON file to a repository so every change is tracked, diffable, and reversible. To roll back, revert the commit and redeploy.
3. **Review** changes in pull requests. Because the definition is structured and minimal, a reviewer can see exactly which panel, query, or filter changed, rather than parsing a single stringified blob.
4. **Deploy** to your target environments. Send the definition to the dashboards API in each environment as part of your pipeline. Use the same definition to keep development, staging, and production in sync.

For the request schema and authentication details, refer to the [dashboards API reference](https://elastic.github.io/dashboards-api-spec/dashboards#tag/Dashboards).

## Manage IDs across environments

A dashboard's ID determines whether a deployment updates an existing dashboard or creates a new one. To promote the same dashboard repeatedly across environments, deploy it with a stable, chosen ID rather than letting the API generate one. When you create a dashboard with a fixed ID, later deployments with that ID update the existing dashboard in place instead of creating duplicates.
To deploy a dashboard to a different space within the same cluster, target that space in the API request. When you export a dashboard and select **Open in Console**, you can add the destination space to the request before sending it.

## Manage references to data views and saved objects

Panels can reference other saved objects, such as data views or Discover sessions. A reference only resolves if the object it points to exists in the target environment with a matching ID. When you plan how to handle references, choose one of these approaches:
- **Provision the referenced objects first**, with stable IDs, in every environment. The dashboard then resolves its references consistently wherever you deploy it.
- **Avoid external references** by backing panels with [ES|QL](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/7029/explore-analyze/query-filter/languages/esql-kibana) queries or ad-hoc index patterns defined directly in the panel. These definitions are self-contained and don't depend on a saved data view in the target environment.


## Choose inline or library panels

The dashboards API supports two ways to define a visualization panel, and the choice affects how portable your definition is:
- **Inline panels** define the visualization entirely within the dashboard definition. The dashboard is self-contained and carries no external references to resolve, which makes it the most portable option for deploying across environments.
- **Library panels** are stored as standalone [visualizations](/elastic/docs-content/pull/7029/explore-analyze/dashboards/create-dashboards-programmatically#lens-visualizations-api) and embedded by reference. Use them when you want to reuse a chart across multiple dashboards and have a single update propagate everywhere. The referenced visualization must exist in the target environment.

Prefer inline panels when portability matters most, and library panels when reuse across dashboards matters most.

## Automate with Terraform

For a fully managed GitOps workflow, the [Elastic Stack Terraform provider](https://registry.terraform.io/providers/elastic/elasticstack/latest/docs) includes an `elasticstack_kibana_dashboard` resource that maps the dashboards API to Terraform configuration. With it, you get `terraform plan` diffs, drift detection when someone edits a dashboard manually in the UI, per-environment deployments, and rollback by reverting to a previous commit.