What Grafana customization involves
Grafana customization is the work of shaping a running Grafana instance around how your teams read data. It covers dashboard design and template variables, folder structure and folder-level permissions, custom panels and app plugins, embedding dashboards in other applications, and theming. It sits on top of a deployment that already exists or is planned. Installing Grafana, connecting data sources, setting up identity, running it in high availability and managing configuration as code are separate topics, and each changes what customization can safely assume.
The usual triggers are three. The first is many teams sharing one instance, where folders, team permissions and a consistent set of variables stop individual dashboards from becoming a maze. The second is multiple data sources, where variables and dashboard templates need to hide which backend a panel queries from the people reading it. The third is an internal portal that embeds dashboards, which brings in anonymous or signed access, theming to match the portal, and questions about what a viewer can see once a dashboard leaves Grafana's own interface.
The boundary with provisioning matters most. Grafana can load data sources, dashboards and plugins from files at startup, and it supports Terraform and Git Sync as further as-code options. Decide early which objects are owned in code and which may be edited in the UI. Customization that is built by hand in the UI and never exported will drift from the repository, and customization that is forced into code without a review workflow will slow every small change.
Most organizations with a small platform team do this in-house once the base deployment is stable. Partners are usually brought in when the design must be settled quickly across many teams, when custom plugins need to be written and maintained, or when the internal portal needs a defined embedding and theming model. Ask any partner to show the folder and permission model, the variable conventions and the provisioning boundary in the written scope before work starts.
What the work includes
Grafana customization is scoped as a set of workstreams, and each one ends in a specific artifact your teams keep. The scope, deliverables and timelines for the workstreams you need are agreed in writing before work starts.
Dashboard standards and variables
We define the conventions your dashboards follow: panel naming, units, time defaults, color use and the shared variables that let one dashboard serve several services, clusters or environments. The deliverable is a dashboard standard with a reference template and a checklist reviewers can apply. Check that variables query the right data source and behave correctly when a selection is empty.
Folder and permission model
We map teams, responsibilities and data sensitivity to a folder structure and a set of roles, then decide which teams may view, edit or administer each folder. The deliverable is a permissions matrix that names every folder, role and grant. Confirm which identity mappings you need, since SAML, team sync and SCIM depend on your Grafana edition.
Custom panel or app plugin development
When built-in panels cannot show your data, we design and build a custom panel or app plugin against the Grafana plugin tooling. The deliverable is the plugin source with build and test steps, a version pinned to the Grafana releases you run, and notes on how it is installed. Confirm the plugin's license terms and how it will be updated across Grafana minor releases.
Embedding and theming
We configure how Grafana appears inside your portal or other applications, including embedded panels, anonymous or signed access rules, and visual theming that matches your brand. The deliverable is an embedding configuration with the settings, allowed origins and a short test plan. Check the embedding and access settings against your security review, because they change who can see data.
Documentation and handover
We document the standards, permissions, plugins and provisioning choices so your team can maintain them without us. The deliverable is a handover pack with runbooks, change steps for dashboards and folders, and a walkthrough with the people who will own the instance. Agree in writing who keeps the documentation current after handover, and how that work is paid for if you use a support retainer.
What drives cost and duration
Each row names one driver that moves customization effort, why it matters for Grafana specifically, and a practical way to keep it manageable, so you can compare scope before asking for a quote.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Teams and folders | Each team needs its own folder structure, permission set and dashboard ownership, and each permission rule has to be designed, tested and documented. | Agree a small set of folder patterns and role templates up front, and map them to existing groups instead of creating one folder per request. |
| Data sources | Prometheus, Loki, SQL databases and others each need connection settings, credentials, query conventions and label or schema knowledge. Variety adds more query-writing and testing work than count alone. | Limit the first release to the sources that feed the most-used dashboards, and standardize naming and label conventions across them. |
| Dashboards to rebuild or standardize | Rebuilding a dashboard means re-deriving its queries, variables, thresholds and layout, then checking values against the old view. Standardizing many near-duplicate dashboards adds review cycles with the owners. | Retire unused dashboards before migration, and build a shared template with variables for dashboards that differ only by service or region. |
| Custom plugin scope | Custom panels and app plugins need their own code, build pipeline, signing decisions and upgrade testing against each new Grafana minor release. Scope grows with every plugin feature requested. | Prefer existing community or core panels and dashboard variables, and write a custom plugin only when a documented need cannot be met otherwise. |
| Embedding requirements | Embedding panels or dashboards in other applications requires anonymous or token-based access decisions, cross-origin settings and security review of the host application. Each embedding pattern is a separate test case. | Agree one embedding pattern and host application first, and confirm your license terms and access model before design begins. |
| Theming depth | Logo and color changes are a small task. Changes to layout, typography or component styling across releases need more testing and may need rework at each upgrade. | Limit theming to brand elements and documented settings, and avoid overriding internal styles that change between releases. |
| Edition (open source or Enterprise) | Some access features, such as SAML, team sync and SCIM provisioning, are available only in Grafana Enterprise and Grafana Cloud according to the Grafana authentication docs. Designs that rely on them need a different build and a separate license decision. | Confirm which access features your design needs before design starts, and use open-source mechanisms such as generic OAuth and role mapping where they meet the requirement. |
| Number of environments | Each environment needs its own provisioning files, data source endpoints, secrets and validation pass. Drift between environments is a common source of rework. | Keep one codebase or provisioning repository with environment-specific values separated, and promote changes through the same path each time. |
Project phases and outputs
The sequence moves from understanding who uses Grafana and what they need to see, through a designed model of folders, permissions and variables, to tested dashboards, plugins or embedding, and a handover your team can operate.
Discover teams, data sources and access needs
We interview the teams who will use Grafana, inventory the data sources they query (such as Prometheus, Loki or SQL databases), and record who needs to view, edit or administer each area. The output is a written requirements inventory listing teams, data sources, dashboards in scope, and access needs. Confirm with your team leads that the inventory matches how work is actually done before design begins.
Design the folder, permission and variable model
We design the folder hierarchy, the role and team permission model, and the dashboard variables that let one dashboard serve several services or environments. Identity mapping is designed here, including which group claims map to which Grafana roles if you use an external identity provider. The output is a design document with a folder tree, permission matrix and variable catalog. Your security and platform owners should approve the permission matrix before any build starts.
Build dashboards, plugins or embedding
We build the dashboards, panels, any custom plugins or app plugins, and any embedding or theming in scope, following the approved design. Work is kept in a version-controlled repository and, where you choose provisioning, is deployed from files rather than edited by hand. The output is a tested build in a non-production instance with a change log. Confirm which items are in scope for the build and which are deferred, since plugin work often carries its own licensing and maintenance questions.
Test against the target version and identity setup
We test dashboards, queries, variables and plugins against the exact Grafana version you will run in production, and verify that sign-in, group mapping and folder permissions behave as designed for each test user role. Security hardening settings are checked as part of this pass. The output is a test record listing each case, its result and any open defects. Confirm the target version with your team in advance, and confirm that the test accounts reflect real roles rather than shared administrator logins.
Hand over with runbooks and operating notes
We deliver the production configuration, the provisioning or as-code repository, and runbooks covering how to add a dashboard, change a permission, roll out a plugin update and recover a broken configuration. Your staff are walked through the material. The output is a signed-off handover pack and a list of known limitations. Confirm that named owners on your side can run each runbook without DeployOpen involvement before the engagement closes.
What your team keeps and what a partner covers
This table shows which Grafana customization work usually stays with your own staff and which parts are often outsourced, with the skills each part requires, so you can decide where a partner adds the most value.
| Part of the work | Usually kept in-house | Often outsourced | Skills it needs |
|---|---|---|---|
| Dashboard ownership | Named owners per team who decide what each dashboard answers and when it is retired | Setting up an ownership model and folder-level responsibility rules for your organization | Operational knowledge of your services, Grafana administration, and a clear review process |
| Business definitions of metrics | Agreed meaning of SLOs, error budgets, revenue-related and capacity measures | Encoding those definitions as recording rules or reusable query templates | PromQL or LogQL for queries, plus domain knowledge from the teams that own the numbers |
| Final approval of access | Sign-off on who may view or edit each folder, data source and team | Mapping approved groups to Grafana roles and folder permissions in configuration | Grafana administration, identity administration, and an audit trail for access changes |
| Dashboard standard design | Final sign-off on naming, layout and the panels each team requires | Building a reusable dashboard standard with panel conventions and documented patterns | Grafana dashboard JSON, PromQL or LogQL, and experience with consistent operational layouts |
| Variable and folder architecture | Confirmation of which environments, clusters and tenants must be selectable | Designing chained variables, folder hierarchy and provisioning structure that scale | Grafana templating, Grafana administration, and provisioning with YAML or Terraform |
| Custom plugin development | Decision on which panels or app plugins are worth maintaining after launch | Building, testing and packaging custom panel or app plugins against the Grafana plugin SDK | Front-end TypeScript and React, Grafana plugin tooling, and upgrade testing across Grafana releases |
| Embedding setup | Decision on which dashboards are shared outside Grafana and with which audiences | Configuring embedded dashboards, theming and anonymous or signed access within your license terms | Web security for embedding, cookie and Content Security Policy settings, and Grafana administration |
What usually goes wrong
Most Grafana customization problems appear months after go-live, when the first upgrade, the first audit or the first embedding request arrives. Each risk below has a prevention step that belongs in the design phase or the handover.
Hand-built dashboards drift from the standard
When teams edit dashboards in the UI without a shared template, panels, variables and naming diverge within months. Agree a dashboard standard in design, including variable conventions, panel naming and folder layout, and keep provisioned dashboards as the source of truth so UI edits are either promoted through review or reverted at the next sync.
Permissions that mirror the org chart
Mapping every reporting line to a folder or team produces hundreds of narrow grants that nobody can review or explain. Design permissions around data domains and roles instead, keep folder hierarchies shallow, and document who may edit, view and administer each folder before the first dashboard is built.
Custom plugins that break on upgrade
Custom panels and app plugins depend on Grafana APIs and build tooling that change across minor and major releases. Record the Grafana versions each plugin supports, pin its build dependencies, and include a compatibility test against the next minor release in the handover so the upgrade plan covers plugins as well as the core server.
Embedding blocked by cookie or CSP settings
Embedded dashboards in another application often fail when browser cookies are restricted or the host page's Content Security Policy does not allow the Grafana origin. Decide the embedding topology during design, review the cookie attributes and CSP directives documented in the security hardening guide, and test the embedded view in every browser the business supports.
Licensing questions raised after build
Teams often ask late whether embedding, redistributing a modified Grafana or shipping a plugin to customers is permitted. Grafana's core is AGPLv3 while plugins and SDKs carry their own licenses, so have counsel review the intended use before design is locked, and record the decision and any Grafana Enterprise requirement in the project documentation.
How the work changes by starting point
A new instance with no dashboards gives the most room to design folders, permissions, variables and provisioning before any content exists. Effort goes into the design itself: how teams are grouped, which folders map to which owners, and which dashboards become shared templates.
- Effort: Mostly design and build. There is no existing content to reconcile, so provisioning files can be the source of truth from the first commit.
- Client supplies: Team and role structure, the list of data sources teams will query, and named owners for shared folders.
- Confirm: Whether your database for configuration will be SQLite for a pilot or MySQL or PostgreSQL from the start, since the installation docs say SQLite does not scale for production.
- Confirm: Which identity features you need, because SAML and team sync are Enterprise-only features.
When dashboards already exist in another tool or another Grafana instance, customization work starts after content has been moved. The move itself is covered in the sibling migration topic, so this tab covers only what changes in the customization scope.
- Effort: Adds a reconciliation step: moved dashboards often need variables, folder placement and permissions reworked to match your team model.
- Client supplies: An inventory of dashboards to keep, retire or merge, plus the owners who will sign off on each one.
- Confirm: Whether dashboards will be converted to JSON provisioning files or maintained in the UI, because that choice sets how drift is handled later.
- Confirm: Which data source identifiers changed during the move, since variables and panels often reference them.
An instance already in production usually holds dashboards created by individuals, with no shared folder model and little record of who owns what. The work is more about governance than building.
- Effort: Audit existing dashboards, then restructure folders and permissions without breaking links or alerts that people already rely on.
- Client supplies: Read access for an export of dashboards and folders, a change window agreed with dashboard owners, and a decision on who may edit shared content.
- Confirm: Whether any dashboards are edited directly in the UI that automation will later overwrite.
- Confirm: Whether users rely on current URLs, since moving dashboards can change them.
Deploying Grafana with the Helm chart changes where customization lives. Provisioning files are usually mounted from ConfigMaps or Secrets, and changes flow through the chart values and the cluster's release process.
- Effort: Adds chart values work, mounting of provisioning files, and a release path for dashboard changes that matches your GitOps or deployment pipeline.
- Client supplies: Cluster access details you are willing to share, namespace and secret handling rules, and the chart version you have approved.
- Confirm: Whether plugins will be installed at startup or baked into a custom image, since the choice affects upgrades.
- Confirm: Whether the database is an external MySQL or PostgreSQL service, because high availability depends on it.
In a restricted network, Grafana cannot fetch plugins or dashboards from the internet at runtime. Every plugin is vendored, reviewed and installed from an internal source, which adds review and transfer steps to each change.
- Effort: Adds a plugin intake process: vendoring, license and security review, and a controlled way to move approved artifacts into the network.
- Client supplies: The approval path for software entering the network, an internal artifact store if one exists, and reviewers for each plugin.
- Confirm: Which plugins are needed and whether each one's license fits your use, since plugin licenses differ from Grafana's.
- Confirm: How dashboard and provisioning changes will be promoted across the boundary and who signs off on them.
What you need to provide
Most of the scope in a Grafana customization project is decided by inputs the client provides before any build starts. Named owners for each team's dashboards come first. Each folder, dashboard and alert rule needs a person who can approve design changes and confirm that a panel still answers the question it was built for. Dashboard owners usually sit in the platform, SRE or observability team, with each product or service team naming a delegate who signs off on its own views. Without named owners, dashboard variables, folder structures and permission models stall in review. Current inventory of data sources and dashboards is the second input. Customization work depends on knowing which data sources exist (Prometheus, Loki, SQL databases or others), who connects to them, and how many dashboards depend on each. A simple export of dashboard JSON and a list of data source connections, maintained by the team that runs Grafana today, lets the scope cover real panels rather than a guess. Ask the platform team to confirm which data sources are read-only and which hold credentials that must be rotated. A non-production Grafana instance on a known version is needed to test provisioning files, plugin changes and theming without touching live dashboards. Confirm the exact version, edition and database backend with the team that operates it, because the upgrade guidance and plugin compatibility differ by release. The same team should confirm the identity provider group structure: which groups map to Grafana roles and folders, and whether SAML, team sync or SCIM is in use, since those features depend on the edition. Finally, decide on the edition and whether embedding is internal or external. Embedding dashboards in an internal portal and embedding them for customers raise different questions about authentication, licensing and theming. The product owner, legal or licensing contact and security lead should agree on these decisions, and any custom plugin code should have a named reviewer in the engineering team who approves it before it reaches production.
Frequently asked questions
Can our team customize Grafana without an implementation partner?
Yes, a team with production Grafana experience can customize it without a partner, and many do. Dashboard variables, folders, permissions and provisioning files are documented and can be learned from the official docs. The harder parts are custom panel or app plugin development, which needs frontend and TypeScript skills, and designing provisioning as code so that UI edits do not drift from the repository. Before deciding, check whether someone on your team has owned a Grafana instance in production and has time for the work.
What drives the cost and effort of a Grafana customization project?
Scope is the main driver: the number of data sources, dashboards, custom plugins and identity integrations. Other drivers include whether provisioning as code is in scope, how many teams need separate folders and permissions, and whether Enterprise-only features such as SAML or team sync are required. Your database choice also matters, since SQLite is not suited to production and MySQL or PostgreSQL is needed for production and high availability. Ask for the one-time build cost separately from any recurring support, and ask what each deliverable includes.
How long does a Grafana customization project take?
The duration depends on the scope agreed in writing before work starts, so no single figure applies to every project. Adding a few dashboards and folder permissions takes far less time than building custom app plugins, moving provisioning to Git and adding SSO with role mapping. Ask for a timeline tied to named deliverables, the review steps on your side, and dependencies such as access to data sources and identity systems. If an upgrade is part of the work, the Grafana release schedule can also affect timing.
What does our side need to provide for a Grafana customization engagement?
Expect to provide access to a test Grafana instance and the data sources it reads from, along with named owners who approve dashboard designs and permission models. You will also need a list of the teams and roles that will use the work. If sign-in is in scope, you will need access to your identity provider, and you should state the source control and change process the work must follow. A decision-maker who can answer design questions quickly usually shortens review cycles. Confirm exact access requirements during scoping.
Can we embed Grafana in our own product under AGPLv3?
Embedding can be allowed under AGPLv3 if you meet its terms, and the obligations that apply when software is accessed over a network need careful reading. Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3 on April 20, 2021, according to the Grafana Labs licensing page. Plugins, SDKs and agent software carry other licenses, so review each component. Grafana Enterprise is offered as a non-AGPL commercial option. Involve your legal team before shipping, because DeployOpen does not provide legal opinions on license compliance.
How do custom Grafana plugins stay compatible across releases?
Custom plugins must be tested against each Grafana release, and the release cadence sets the workload. Grafana's upgrade guidance describes major releases once a year in April or May, minor releases about every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months, so plan upgrade windows at least that often. Pin plugin SDK and build tool versions, run automated tests in staging, and agree who maintains the plugin after handover. An ongoing support retainer can cover this work.
How DeployOpen delivers Grafana customization
DeployOpen scopes Grafana customization in writing before any build starts, then builds dashboards, folders, permissions and plugin work inside your own infrastructure and hands the result over with documentation. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- We agree the teams, dashboards, folders and permission model to be delivered before work starts.
- We list which data sources, such as Prometheus, Loki or SQL databases, the customization must read from.
- We record in writing whether provisioning will use files, Terraform or Git Sync, and who owns each step.
How we build
- We design dashboard variables, templates and panel layouts against the agreed teams and data sources.
- We build folder structures and role assignments that match the permission model signed off in scope.
- We test each dashboard and permission set against sample users and data before handover, and confirm the results in writing.
How we hand over
- We deliver dashboards and configuration as files or code in a repository your team controls.
- We document the folder layout, permission model, provisioning workflow and any custom plugin settings.
- We walk your administrators through changing dashboards and provisioning so UI edits do not drift from the code.
How we support
- We can continue with a retainer covering Grafana upgrades, plugin compatibility checks and security patches.
- Retainer scope, response expectations and review cadence are agreed in writing and confirmed before service starts.
- Changes outside the original scope, such as new teams or data sources, are quoted separately from the written scope.
