Grafana dashboard snapshots and why the default endpoint matters
In a stock Grafana installation, snapshots and external snapshot publishing are both enabled by default, and the default external_snapshot_url points to That means a colleague who clicks Share, then Snapshot, on a shared self-hosted instance can push dashboard data to a server outside your network without anyone deciding that it should leave. Before you open the instance to a shared team, confirm these settings in your own configuration rather than assuming the defaults match your data policy.
A snapshot captures the dashboard state and the query results visible at the moment it is taken, so it carries the values, labels and panel data a viewer would see, not a live link to the data source. Teams use snapshots to share a point-in-time view with someone who cannot query the data source, to attach a view to a ticket or incident, or to keep a record of how a panel looked during an event. The convenience is the risk: the snapshot contains operational detail such as host names, service names, internal addresses and business volumes, and it persists after the dashboard changes. Ask your Grafana administrators which users can create snapshots and whether any of them would reasonably share operational data with an outside party.
The [snapshots] section of the Grafana configuration controls this behavior, and the settings to review are whether external publishing is enabled, which URL is used, and whether the instance itself is meant to act as a snapshot server. Setting public_mode to true turns the instance into an external snapshot server that accepts unauthenticated create and delete requests, which is a different exposure and should never be enabled on an internal instance by accident. The default is false. Plan the change as a documented configuration decision, test it with a non-sensitive dashboard, and record which mode each environment runs in before the first user group is onboarded.
Snapshot configuration options and when each fits
This table compares the four snapshot settings that decide where snapshot data goes and who can write to it. Read each row against your network boundary: the default values send snapshots to an external service, so regulated and air-gapped deployments usually need to change at least one of them. Keep public_mode at false unless you deliberately run an internal snapshot server.
| Setting | When it fits a regulated or air-gapped deployment | Risk it carries |
|---|---|---|
| Snapshots enabled (default on) | Keep on when operators need point-in-time copies of dashboards for internal review, incident records or change evidence | Snapshots can hold query results and data values, so they become a store of operational data that needs access control and retention rules |
| External snapshot publishing enabled (default on) | Turn off in isolated networks so users cannot publish snapshots outside the instance | Without this change, a user can push dashboard content to an endpoint outside your network boundary |
| external_snapshot_url set to the default endpoint | Only suitable where outbound internet access to that endpoint is permitted by policy, which is rarely the case for regulated or air-gapped work | Default value points to an external host, so data leaves your environment unless publishing is blocked |
| external_snapshot_url set to an internal Grafana server | Fits when you want an internal snapshot target and have a Grafana instance inside your network configured as a snapshot server | The target inherits its own access, patching and retention obligations, so treat it as a system in scope |
| public_mode set to false (default) | Recommended for almost all deployments, because create and delete requests require authentication | Lower risk; confirm that no other service depends on unauthenticated snapshot calls |
| public_mode set to true | Only for a dedicated internal instance acting as a snapshot server, with network restrictions in front of it | Allows unauthenticated create and delete requests, so anyone who can reach the endpoint can write or remove snapshots |
Keeping snapshot data internal: setup sequence
This sequence moves a Grafana instance off the default external snapshot endpoint, so snapshot data stays on infrastructure you control and you can prove it with a test publish and a check of outbound traffic.
Inventory dashboards and snapshot publishers
Ask the Grafana administrator to list which dashboards exist and which users have created snapshots, using the snapshot list in the UI and any existing snapshot records in the database. Include users who may publish from shared or service accounts. Record which snapshots are already public and whether they hold sensitive panel data or annotations. The step is done when you have a written list of publishers, the snapshots already sent to external endpoints, and the owners who need to be told about the change. Confirm with your Grafana team how existing snapshot links will be handled before any setting changes.
Set the snapshot publishing policy
Decide with the security and data owners whether snapshots are allowed at all, allowed only as internal snapshots, or restricted to named roles. Write the policy down, including who may delete snapshots and how long internal snapshots should be kept. Snapshots are enabled by default in Grafana, so this decision controls whether the instance should keep that default. The step is done when a signed policy exists and the Grafana administrator has confirmed which configuration keys implement it. Keep the policy short enough that dashboard owners can apply it without asking for an exception.
Disable external snapshot publishing
In the
[snapshots]section of the Grafana configuration file, turn off external snapshot publishing so that snapshots are not sent to the default external endpoint. Grafana enables this by default, and the default external endpoint is outside your network. If you need an external endpoint, do not point it at the default service. Instead, deploy an internal snapshot server inside your network and setexternal_snapshot_urlto that server. The step is done when the configuration file shows the change and the Grafana administrator has recorded the file version in your change system. Check the Grafana configuration reference for the exact key names in your installed version.Keep public mode off unless intended
Confirm that
public_modeis set tofalseunder[snapshots]. The default isfalse. When it istrue, the instance acts as an external snapshot server and accepts create and delete requests without authentication. Set it totrueonly when you have deliberately built a dedicated internal snapshot server, and then restrict network access to that server. The step is done when a review of the effective configuration confirms the value, including any override from environment variables or containers. Record the reviewer and date in the change record.Restart and confirm the new settings
Restart the Grafana service so the configuration changes take effect, using your normal change process. After the restart, check the logs for startup errors and confirm the running instance reads the updated values. The step is done when the service is healthy and the configuration check passes on every node. In a high availability deployment, apply the same configuration to all Grafana servers behind the load balancer before testing, because a node with the old setting will still publish externally.
Test a snapshot publish from a test account
Sign in with a non-administrative test account that has the Editor or Viewer role your policy allows, open a test dashboard, and attempt to create an external snapshot from the share menu. The publish should be refused or should only produce a local snapshot, depending on the settings you chose. Repeat the test with an account that is not allowed to create snapshots and confirm it is blocked. The step is done when both results match the written policy and the test outcomes are recorded with the Grafana version and time. Remove the test snapshot afterward if it was created.
Confirm no traffic reaches the default endpoint
Verify at the network layer that the Grafana server makes no outbound request to the default external snapshot host. Use your firewall, proxy or DNS logs, or a controlled egress test from the Grafana host, and repeat the test-account publish while capturing traffic. Compare the results with the default endpoint name in the Grafana configuration reference. The step is done when the logs show no connection to that host during the test and your team has filed the evidence with the change record. Repeat this check after each Grafana upgrade, since defaults and configuration keys can change between releases.
What regulated and air-gapped deployments change
Snapshot publishing is a data-egress path, and security teams should review it alongside every other outbound route from the Grafana host. On a default installation, [snapshots] external_snapshot_url points at ` and external publishing is enabled, so a user who clicks share and chooses the external option sends dashboard data, panel data and the snapshot's embedded query results to a host outside your network. That path does not appear in a normal firewall review of Grafana's data sources, because it originates from the Grafana process itself and is initiated by a user action. In a regulated environment, the control question is whether that transfer is permitted at all, who can trigger it, and whether it is logged.
An isolated boundary changes the answer from a configuration preference to a boundary condition. Under NERC CIP-005-7, Interactive Remote Access to high and medium impact BES Cyber Systems must pass through an Intermediate System with encryption and multi-factor authentication, and entities must be able to detect and disable active vendor sessions. A snapshot upload to a public endpoint is not remote access in that sense, but it is the same class of concern: uncontrolled movement of operational data across a perimeter. Treat the external endpoint as an outbound dependency to disable, not as a feature to govern. Under NERC CIP-013-2, the related expectation concerns verifying the integrity and authenticity of vendor software and patches brought across the boundary. Snapshot settings do not address that, but the same change process should cover any package, plugin or image you transfer in. Confirm applicable standards with your compliance team, since these references are context for your review, not a statement that Grafana satisfies them.
DeployOpen prepares configuration, evidence and records of these decisions for your assessment, including the settings applied, how outbound traffic was tested and who approved the change. DeployOpen does not issue audit reports, attestations or certifications, and an independent auditor decides whether the evidence meets a given requirement. Ask your auditor early which evidence they expect for outbound data paths, and ask your implementation partner to show the configuration state from the running instance rather than from the file alone.
Security and operational risks of snapshot settings
Snapshot defaults in Grafana send data to an external endpoint and can expose unauthenticated write access when public mode is turned on. The cards below cover the risks that follow from those settings, from who can create snapshots to confirming the configuration still holds after an upgrade.
Unauthenticated create and delete
When [snapshots] public_mode is set to true, the instance acts as an external snapshot server and accepts create and delete requests without authentication. Anyone who can reach the endpoint can write data into your instance or remove existing snapshots. Before enabling it, confirm the endpoint is reachable only from the networks that need it, and test that unauthenticated requests are refused from everywhere else.
Data leaving the network
Snapshots and external snapshot publishing are enabled by default, and external_snapshot_url points to a public endpoint. A user who clicks share with external snapshot sends dashboard data, including query results, outside your network. In a regulated or air-gapped environment, disable external publishing and confirm that no snapshot URL in the configuration leads off-premises.
Snapshots outliving their purpose
A snapshot stays in the instance until someone removes it, so data copied for a single incident review can remain readable long after the review closes. Define who owns snapshot cleanup, how often it runs, and how removal is verified. Ask your team whether any retention limit is set in your deployment and document what you find, since this page does not assume a default.
Sensitive values in snapshot data
A snapshot captures the rendered data behind a panel, not only the layout. Query results can contain hostnames, account identifiers, customer records or secrets that appeared in a label or annotation. Review which data sources feed dashboards before snapshots are allowed, and keep sensitive panels out of any dashboard a user can snapshot.
Who can create snapshots
Snapshot creation follows the access the user already has to a dashboard, so broad Editor or Admin roles widen who can export data. Decide which roles may create snapshots, and align that decision with folder permissions and any data source permissions in place. Check this for viewers too, since viewer access to a dashboard can still expose the data it displays.
Confirming settings after upgrades
Settings that look correct on day one can drift after a configuration rewrite, a container image change or a Helm values update. Monitor outbound traffic from the Grafana host or pod and alert on connections to the snapshot endpoint. Repeat the check after every upgrade, since major releases arrive once a year and patch releases at least monthly.
Questions teams ask before changing snapshot settings
How much effort does it take to lock down snapshots on an existing Grafana instance?
The configuration change itself is small: set the snapshot options in the Grafana configuration file and restart the service. The effort lies in everything around it. You need to find out who has created snapshots, decide what happens to snapshots already published to the external endpoint, confirm that no dashboards or users depend on external sharing, and prove with egress logs that snapshot traffic has stopped. Ask any partner for a written scope that lists each of these steps and the systems they touch before agreeing a fee or timeline.
What drives the effort of locking down Grafana snapshots?
Four factors move the work most:
- Number of users and teams who create snapshots, since each group may have its own habits and shared links
- Number of dashboards and folders that contain snapshot links in runbooks, tickets or chat history
- Number and type of data sources, because snapshot contents depend on what each panel queried
- Air-gap rules, such as whether the network must block all external DNS and HTTPS, which requires a documented test plan
Each factor adds review and testing time, so ask for a quote that names the count of each one in your environment.
Can our own team change snapshot settings using the configuration docs?
Yes, a capable Grafana administrator can change the snapshot settings from the Grafana configuration documentation. The harder part is verification. Your team must confirm that the new settings took effect on every node in a high availability setup, that the external endpoint is unreachable from production, and that users see clear errors instead of silent failures. If your team lacks time or a test environment, a fixed-scope engagement can cover these checks in writing.
What do we need to provide if a partner handles the snapshot change?
Plan to provide access to the Grafana configuration file and the host or container where it runs, read access to the database that stores snapshot records, and a named owner who can approve the change window. You will also need egress logs or firewall records covering at least the period before the change, so the change can be compared with real traffic. Agree on a test plan that lists the dashboards, users and data sources to check. Confirm with your security team which evidence they need to retain for review.
Should we ever enable public_mode for snapshots?
Only in a deliberate case where the instance is meant to act as an external snapshot server. With public_mode set to true, Grafana allows unauthenticated create and delete requests for snapshots, and the default is false. In a shared or regulated environment, that exposure is hard to justify. Treat any request to enable it as a formal risk decision, document the network controls that limit who can reach the endpoint, and confirm the decision with your security and compliance owners before any change.
How does a snapshot change interact with Grafana upgrades?
Snapshot settings live in the configuration file, so they must survive each upgrade. Review the configuration and any provisioning or automation that writes it before every minor or major release, because a replaced file can silently re-enable external publishing. Grafana publishes major releases once a year and minor releases every other month, so plan a regression check of snapshot behavior into each upgrade window. Confirm the current release and support window in the Grafana upgrade guidance before scheduling.
What recurs after the snapshot change is complete?
The one-time work is the configuration change, the test plan and the review of existing snapshots. Recurring work is smaller but continuous: checking configuration after each upgrade, monitoring egress for new calls to the external snapshot endpoint, and reviewing any new request to change snapshot settings. If your organization wants ongoing support, ask for a retainer with defined review points rather than an open-ended hourly arrangement, so the recurring cost stays visible in the quote.
Where to confirm the exact settings
Before you change anything in grafana.ini, confirm the exact key names, default values and the section each setting belongs to in the Grafana configuration documentation. The snapshot settings discussed on this page sit in the [snapshots] section, and the external endpoint is controlled by external_snapshot_url. Those names have been stable enough to rely on, but a configuration key can be renamed, moved or given a new default between releases, and a setting that looks identical in an older guide may behave differently after an upgrade. Treat the reference as the authority and this page as the map to what needs checking.
Always read the reference for the Grafana version you actually run, not the latest version. Check the installed version on the server or in the Grafana interface, open the matching documentation, and confirm each snapshot key there before you write it into your deployment configuration. Environment variable overrides, container images and Helm values can also set these keys, so confirm which mechanism your platform uses and that the value in effect is the one you intended. Record the version and the checked values in your change ticket so a later auditor or engineer can see what was true at the time.
Once you have confirmed the keys, test the result rather than assuming it. Create a snapshot from a dashboard with no outbound internet access, confirm it is stored on your own instance, and verify that no request leaves your network during the attempt. Ask your Grafana platform owner who will repeat this check after each upgrade, because the behavior of a default you rely on can change without any visible warning in the interface.
How DeployOpen scopes snapshot lockdown for your Grafana
Snapshot lockdown touches configuration, network rules and evidence at the same time, so the work starts with a written scope and ends with records your reviewers can check. The cards below follow that order from agreement to ongoing support, and each one names the decision or artifact the reader should expect.
Written scope before any change
The engagement starts with an agreed scope that names the Grafana instances, the snapshot and renderer settings in use, and the networks each instance can reach. It also records who approves changes to snapshot behavior and which users currently publish snapshots. Because the default external snapshot endpoint is enabled out of the box, the scope should state explicitly whether publishing to any external host is allowed, and for which teams.
Review of snapshot and egress settings
We review the [snapshots] section, the external snapshot URL, and the outbound paths from Grafana and any image renderer against your network rules. The goal is a list of every destination the instance can reach and a decision for each one. Ask us to include proxies, DNS resolution and any plugin or update traffic, since a snapshot setting alone does not show the full egress picture.
Public mode and unauthenticated requests
Setting public_mode to true turns a Grafana instance into an external snapshot server that accepts unauthenticated create and delete requests. We check whether any instance in your estate should ever run that way, and where a snapshot endpoint must exist, we confine it to a network segment with access controls and documented owners. Confirm this decision with your security team before the work begins.
Changes made in your infrastructure
Configuration changes are made inside your own servers, containers or Kubernetes clusters, using your change tools and your review process. We deliver the modified configuration files and a rollback path for each one. The internal snapshot setup, storage location and any renderer changes are applied in your environment, so no snapshot data passes through DeployOpen systems.
Verification evidence for reviewers
At the end of the work, we hand over a record showing the effective settings, the test results for blocked external publishing, and the outbound destinations confirmed during testing. Auditors and internal reviewers can use this record as evidence of configuration, but it does not replace their own assessment. We also document the settings that were intentionally left in place and why.
Optional retainer for ongoing review
Grafana releases new minor and patch versions regularly, and configuration defaults or documentation can change between them. A retainer lets us re-check snapshot settings, egress rules and renderer configuration after each upgrade, and review new user requests for snapshot sharing. Retainer scope, frequency and fees are agreed in writing, so ask for the scope document before deciding.
