Grafana outbound connections and usage reporting

Why a self-hosted Grafana still reaches outside your network

A self-hosted Grafana server can still make outbound requests, so a security or platform lead cannot assume that running it inside their own network means no data leaves it. Several separate features can contact external services, including anonymous usage reporting, external snapshot publishing, and plugin catalog and update checks. Each one has its own setting, its own data flow and its own approval question, so each needs a deliberate decision rather than a single blanket rule. The reader's first task is to list every feature that is enabled on their instance and to record who approved it.

This page covers the outbound behavior that the team controls through its own configuration: the settings in the Grafana configuration file, environment variables, plugin management and the network path from the server. It also covers what changes when the Grafana host sits in a restricted or air-gapped network, where updates, plugins and images must be brought in through an approved route. Some features and their configuration keys vary by Grafana version, so the exact settings must be confirmed against the release the team runs. The Grafana docs describe the release cadence and support windows, which is a useful starting point for planning that check.

Before changing anything, the team should document the current outbound behavior. That means reviewing the active configuration, testing which hosts the server can reach through its firewall or proxy, and confirming with the Grafana version in use which features send requests and what data they carry. The output should be a short register that names each outbound path, the business reason for keeping or disabling it, and the owner who signs off. Compliance and security reviewers can then check the register against the controls they must evidence, while the platform team can use it to set firewall rules and test that blocked features fail safely.

Outbound paths and the control each one needs

This table lists each outbound path a self-hosted Grafana can use, what leaves the network or what is fetched, where the control lives, and the trade-off of switching it off. Confirm the exact setting names and defaults in the configuration reference for the version you run before changing anything, because the location of these controls has moved between releases.

Outbound path	What leaves or is fetched	Where the control lives	When to turn it off and trade-off
Anonymous usage reporting	Anonymous usage statistics sent to Grafana Labs about the instance	Server configuration file, analytics section (confirm key names in the configuration reference for your version)	Turn off on any network that restricts egress or where reporting is not approved. Trade-off: Grafana Labs loses anonymous usage signal it uses for product decisions
External snapshot publishing	Dashboard snapshot data uploaded to an external snapshot service when a user chooses external sharing	Server configuration file, snapshot section, plus the admin UI snapshot options (confirm in the docs for your version)	Disable external snapshots where dashboard data must not leave the network. Trade-off: users lose one-click external links, so they need local snapshots or other sharing methods
Plugin catalog access	Requests to the public plugin catalog to list and install plugins	Plugin settings in the configuration file and the plugin administration page (confirm for your version)	Restrict when plugins must be vetted and installed from approved artifacts. Trade-off: users cannot browse or install from the public catalog, so plugins must be staged and delivered internally
Plugin and update checks	Version and update lookups to Grafana Labs endpoints, including plugin update checks	Configuration file update and plugin check settings, and the plugin admin view (confirm key names and location for your version)	Disable where change control requires manual approval of every version. Trade-off: administrators must track releases and plugin advisories themselves, using the release channel in their own process
News and notification feeds	Fetching of product news or notification content into the Grafana home or admin pages	Admin UI news panel setting and the configuration file (confirm for your version)	Turn off on restricted networks or in shared operator consoles. Trade-off: users may miss in-product notices, so publish equivalent announcements through internal channels

Choosing controls for connected, proxied and air-gapped Grafana

A connected instance keeps general internet access for the Grafana server, and the team's goal is to switch off the behaviors that send data out or fetch content the organization has not approved. Most teams keep their normal data source connections, package repositories and scheduled patching, then turn off specific outbound features in the configuration file. This model suits environments where the risk is data leaving through optional features rather than through the server's core connections.

Usage reporting: Turn off anonymous usage reporting in the [analytics] section, and confirm the key name against the configuration reference for your Grafana version.
Update checks: Disable the core and plugin update checks so the server does not query for new versions. Patching still happens, but on a schedule your change process controls.
External snapshots: Disable publishing to external snapshot servers under [snapshots] so dashboards cannot be shared outside your network.
Plugin catalog: Decide which plugins are allowed, install them from approved packages, and restrict catalog browsing where your version supports it.

The security owner approves the outbound list, the platform team owns the configuration, and the change board approves the final settings. Check the result by capturing outbound traffic from the Grafana host over a representative period and comparing it with the approved list.

Setting outbound controls on a Grafana server

This sequence takes a running self-hosted Grafana from unmonitored outbound traffic to a documented baseline in which only approved destinations are reachable. Each step ends with a check you can repeat after future upgrades.

Record the Grafana version and edition
The platform engineer running the instance records the exact Grafana version, the edition (open source or Enterprise), the install method (package, container or Helm chart) and the database backend. Outbound behavior and setting names change between releases, so every later step depends on this record. Confirm the setting names for that exact version in the Grafana configuration documentation before editing anything. The step is done when the version, edition and database are written into the change ticket and match what the server reports on its administration page.
Capture current outbound destinations
Before changing anything, the network team turns on firewall or proxy logging for the Grafana host and runs a short test window that covers normal use: logins, dashboard loads, plugin page visits, alert evaluations and a scheduled backup if one exists. The team lists every destination hostname and IP address the server contacts, grouped by purpose. Expect entries for data sources you intend to keep, but also for update checks, plugin catalog requests and usage reporting. The step is done when the list has been reviewed and each destination is labeled as required, optional or unknown.
Turn off optional outbound features
The administrator disables each optional outbound feature in the Grafana configuration file or the administration settings, one at a time, then restarts the service. Typical candidates are anonymous usage reporting, external snapshot publishing, the plugin catalog and update checks, each of which has its own setting name in the security and analytics sections of the configuration reference. Record the file path, the key and the old and new values for each change. The step is done when the restarted service starts cleanly and the configuration file holds the recorded values.
Install required plugins from a verified internal source
Plugins that the team needs are obtained from an internal artifact store or a verified download made on a connected workstation, then copied into the Grafana plugins directory or set through the plugin path setting. The team checks each package's signature and checksum against the publisher's values before import, and keeps the package in version control with its hash. Plugins that are not needed are removed so they cannot trigger catalog requests. The step is done when every installed plugin loads on the plugins page without a fetch attempt in the firewall log.
Enforce egress denial for the Grafana host
The network team applies a default-deny egress rule to the Grafana host, with allowances only for the approved data source endpoints, the database, the directory or identity provider, the internal mail relay and the internal time source. If outbound access must pass through a proxy, Grafana's proxy settings are configured to match. The rule is applied in a change window with a rollback plan. The step is done when the rule is active and the firewall log shows the new default action.
Verify that only approved endpoints are reachable
The team tests from the Grafana host itself, using a short script that attempts connections to a list of external test hostnames and expected internal endpoints. Blocked attempts should appear as denied entries in the firewall or proxy log, and the approved endpoints should succeed. Then the team loads representative dashboards, runs a panel query against each approved data source, and triggers a test alert to an internal contact point. The step is done when the denied attempts are logged, the approved connections succeed, and the dashboards and alerts work with egress denied.
Document the outbound baseline
The team writes a baseline record that lists the Grafana version, edition, configuration changes with file paths and keys, the approved destination list, the plugin inventory with hashes, and the firewall rule identifiers. The record also names an owner and the steps to repeat these checks after each upgrade, since minor and patch releases can change defaults. Keep the baseline in version control alongside the provisioning files. The step is done when a second engineer can follow the record and reproduce the same outbound state on a rebuilt server.

Security risks when Grafana talks to external services

Every outbound path from a self-hosted Grafana is a place where data can leave, code can enter, or a dependency can fail without warning. The cards below group those paths by the control that closes each one and the team that should own it, so the outbound settings are reviewed as a security decision rather than a convenience toggle.

Data leaving through snapshots and reporting

Dashboard snapshots can be published to an external snapshot service, and usage reporting sends installation data to Grafana Labs unless it is turned off. Either path can move dashboard content, panel queries or instance details beyond your boundary. Check the snapshot and reporting settings in the server configuration, confirm that external snapshot publishing is disabled or restricted to an approved host, and record the setting in your provisioning or configuration review. Owner: platform engineering, with the CISO signing off on the data-egress decision.

Plugins installed outside the approved supply chain

The plugin catalog and plugin install commands pull code from the public internet at install time. A plugin installed from an unreviewed source runs with the same access as Grafana itself, including its connections to your data sources. Restrict plugin installation to a reviewed list, pin versions, and install approved packages from your own artifact store rather than letting servers fetch them on demand. Owner: security engineering for the approval list, platform engineering for the install pipeline.

Unverified packages carried into isolated networks

In an air-gapped or restricted network, plugins, container images and Helm charts must be carried across the boundary by hand. Each artifact should be checked for integrity and provenance before it crosses, and the transfer should be logged. This is the same control expectation NERC CIP-013-2 places on software integrity for vendor software and patches, so utilities and other regulated operators should map this step to their supply chain procedure. Owner: the team operating the transfer, with supply chain risk management for acceptance.

Plugin trust and signing decisions

Grafana distinguishes signed plugins from unsigned ones, and unsigned plugins must be explicitly allowed in configuration. Allowing unsigned plugins is sometimes needed for internal builds, but each allowance widens what the instance will load. Decide which signature levels your policy accepts, document any internal plugins you sign for private use, and review the allow list whenever a plugin is added or upgraded. Confirm the exact signing behavior for your Grafana version in the plugin documentation before you write the policy. Owner: the Grafana platform owner, with security approval for exceptions.

Version and metrics endpoints exposed to outside callers

The version string and the metrics endpoint can tell an outside caller which build is running and how the instance behaves. Hardening guidance recommends hiding the version from unauthenticated users and requiring authentication for the metrics endpoint. Check both from a host outside your trusted network, and make sure your scraping tool presents credentials that are stored as secrets. Owner: network security for the perimeter test, and the monitoring team for the scrape configuration.

Proxy and DNS dependencies that break when calls are blocked

When outbound calls are blocked, features that depend on them can fail in ways that are hard to diagnose. Plugin catalog lookups, update checks, proxy settings, and DNS resolution for external hosts can all time out or return errors that look like Grafana faults. Inventory every outbound destination your instance uses, route required ones through an approved proxy, and test dashboards and data sources after each egress change. Confirm the dependency list with your Grafana build and deployment method, because the set of calls differs between packages, containers and Helm installs. Owner: the platform team running the network changes.

What changes for regulated and air-gapped networks

Sector rules decide how much of the outbound question is a policy choice and how much is an obligation. In operational technology and critical infrastructure, the stakes are higher because a self-hosted Grafana often sits beside control systems that cannot tolerate unplanned change. NERC CIP-013-2 requires supply chain risk management processes that address verification of software integrity and authenticity for vendor software and patches. For an isolated boundary, that control applies to every package you carry across it, including Grafana binaries, plugins, container images and any update media you use to refresh an offline instance. Ask your compliance lead which of your Grafana assets fall under that process and who signs off on each transfer.

Frameworks for OT security are less prescriptive. *NIST SP 800-82 Rev. 3*, the *Guide to Operational Technology (OT) Security*, describes risks and controls in general terms, so it does not hand you a checklist for Grafana. Your team has to map its own obligations to that guidance and to any sector regulator that applies to you, then record which Grafana settings support each one. Typical items to map include who may change the outbound settings, how those changes are logged, and how plugin installs are approved. Treat the mapping as a working document that your assessor can review, not as a statement that the guide has been satisfied.

DeployOpen prepares systems, configuration and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Your assessor decides what counts as sufficient evidence for your environment, so agree the evidence list with them before the work starts. Ask them which configuration exports, change records and package verification logs they expect to see, and whether they want the outbound settings shown on a running instance or in version-controlled provisioning files. Confirm these expectations early, because they determine how the controls are documented and tested.

Limits to confirm before disabling outbound features

Turning off outbound features changes what your Grafana can fetch, install and share, so the settings are only safe once you know which functions depend on them. The cards below cover the checks to run in your own environment before the change reaches production.

Version and edition support

Confirm which outbound settings exist in the exact Grafana version and edition you run, since option names and defaults can change between releases. Read the configuration reference for that version rather than copying settings from an older guide. Record the edition too, because some controls that affect sign-in and provisioning are limited to Enterprise or Cloud. A setting that is missing in your build will leave traffic flowing without any warning.

Functions that lose access

List every workflow that needs an external endpoint, including plugin installs, plugin updates, catalog browsing, public snapshot sharing and update notices. Test each one on a staging instance with the outbound block in place, and note which failures are cosmetic and which stop a user or a scheduled job. Plan a documented alternative for each function that you need, such as a plugin bundle staged inside the boundary.

Patch intake across the boundary

Patch releases arrive at least monthly and minor releases roughly every other month, so you need a repeatable path to carry each one across the isolation boundary. Decide who downloads the artifacts, how checksums and signatures are verified, and how the package is approved and imported. Without that process, your instance will fall behind and the upgrade becomes a larger project each time.

Plugins with external dependencies

Inventory each installed plugin and check whether it calls a vendor API, loads remote assets, or checks a license server at runtime. A data source plugin may need outbound access to the system it queries, which is expected, but a panel plugin that pulls fonts or scripts from a public CDN can break silently under a block. Ask each plugin publisher to document its network calls, and retest after every plugin update.

Enterprise or Cloud dependencies

Check whether any control you intend to rely on, such as SAML, team sync, SCIM provisioning or a managed sharing feature, is available only in Grafana Enterprise or Grafana Cloud. If it is, the open-source edition will not give you that control, and the decision belongs in the license conversation before the network design is final. Ask for written confirmation of the feature matrix for your exact edition.

Questions teams ask before changing Grafana's outbound settings

How much effort does a Grafana lockdown take, and what drives it up?

The effort depends mostly on how many plugins and data sources the instance uses, how often the team applies patches, how complex the proxy and egress path is, and how much audit evidence the assessor expects. Each plugin that fetches assets or checks for updates adds a path to test. A monthly patch cadence means the process of getting packages across the boundary repeats every month, so the work is recurring rather than a one-time change. Ask any partner to break the quote down by these drivers so you can see which ones your environment triggers.

Can our team change these settings alone, and what skills does it need?

A capable Grafana administrator can change the documented settings alone, but the work touches several areas at once: the Grafana configuration file, plugin installation, the proxy or firewall that controls egress, and the procedure for bringing updates into the network. Your team needs someone who can read Grafana's configuration, someone who owns the egress rules, and someone who can run and record a verification test. If one of those skills is missing, a partner can fill the gap through a fixed-scope engagement while your staff keep ownership of the running system.

How long does verification take, and what does it involve?

Verification usually takes longer than the configuration change itself because it has to show that the instance no longer reaches external hosts during normal use, scheduled jobs and plugin operations. The team captures outbound traffic from the Grafana host, exercises each data source, dashboard and plugin, and records what was blocked and what failed. Expect several test cycles if the first pass finds unexpected destinations. Confirm with any provider how the verification evidence will be recorded and who signs off on it.

What does the work need from our organization before it starts?

Three inputs shape the plan: current network diagrams showing where Grafana sits relative to firewalls, proxies and any boundary to other networks; egress logs from a representative period that show which external hosts Grafana contacts today; and a named approval path for changes, exceptions and the import of packages or plugin files. Without egress logs, the team has to guess at destinations, which usually lengthens the testing phase. Ask who in your organization must approve a change to the boundary before any work begins.

What does a fixed-scope engagement cover for outbound controls?

A fixed-scope engagement covers the agreed systems, the agreed settings and the agreed deliverables, written down before work starts. For this topic that typically means reviewing the current configuration and egress paths, changing the Grafana settings for usage reporting, snapshots, plugin catalog and update checks, setting up a documented process for offline updates, running verification and handing over the configuration and evidence. Anything outside that list, such as changes to unrelated data sources or a new identity integration, needs its own written scope. Ask for the deliverables list and the acceptance criteria in the proposal.

Does turning off usage reporting affect support or licensing?

Turning off anonymous usage reporting in a self-hosted instance does not change the open-source license terms, which are set by the AGPLv3 license Grafana Labs applied to Grafana in 2021. Support depends on your contract with the vendor or partner, not on telemetry, so confirm with each provider what support they offer for a self-hosted instance that does not report usage. If you hold a commercial agreement, check its terms for any reporting or license verification requirement before changing the setting. Keep a written record of the decision for your compliance file.

How do we keep patches flowing into an air-gapped Grafana instance?

Patches reach an air-gapped instance through a repeatable, reviewed transfer process rather than a live connection. The team downloads the release artifacts and plugin files on a connected system, checks their integrity and authenticity against the publisher's published information, records each file in an inventory, and moves them across the boundary under the approval path. Grafana's upgrade guidance describes patch releases arriving at least monthly, so the process has to run on that rhythm or the instance will fall behind. Confirm the exact checksum and signature steps with the vendor's current documentation before you write the procedure.

What should a quote for this work list?

A quote should list each system in scope, each Grafana setting and plugin path to change, the network and egress changes required, the verification plan with the number of test cycles assumed, the evidence each deliverable produces, and the inputs you must supply. It should separate one-time work, such as configuration and first verification, from recurring work, such as monthly patch transfers and periodic re-verification. Ask for assumptions in writing, including the plugin count and patch cadence they were based on, and for the exclusions that would change the price if they turned out to apply.

How DeployOpen scopes outbound controls for your Grafana

DeployOpen plans, implements and documents the outbound settings of your self-hosted Grafana inside your own infrastructure. We start from a written scope that names each external call your instance can make, then test that the settings hold after installation, upgrades and plugin changes.

How we scope

Inventory every outbound path your Grafana instance can use, including usage reporting, snapshot publishing, plugin catalog and update checks.
Confirm which network zones, proxies and egress rules your Grafana servers and plugin hosts are allowed to reach.
Agree in writing which features stay enabled, which are disabled and who approves any exception to the outbound policy.

How we build

Set the Grafana configuration keys that control usage reporting, external snapshots and update checks, stored as version-controlled files.
Configure plugin installation so approved plugins come from an internal source or a pre-loaded plugin directory, not a live catalog lookup.
Test outbound behavior from the Grafana host with packet capture or egress logs, then record the results against the agreed scope.

How we hand over

Deliver a written configuration record listing each outbound setting, its value, its owner and the reason it was set.
Provide a runbook for installing plugins, upgrading Grafana and checking egress after changes, so your team can repeat the steps.
Document the procedure for air-gapped or restricted networks, including how approved packages and plugins are carried across the boundary.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, Grafana upgrades and recurring egress checks are available as a retainer, with scope agreed separately.
Confirm with your team which outbound settings your Grafana version supports before a quote, since configuration keys change between releases.

Controlling Grafana outbound connections and usage reporting