Set up Grafana on Grafana Labs

Install Grafana

Fri, 03 Apr 2026 19:43:06 +0000

Install Grafana

This page lists the minimum hardware and software requirements to install Grafana.

To run Grafana, you must have a supported operating system, hardware that meets or exceeds minimum requirements, a supported database, and a supported browser.

The following video guides you through the steps and common commands for installing Grafana on various operating systems as described in this document.

Grafana relies on other open source software to operate. For a list of open source software that Grafana uses, refer to package.json.

Supported operating systems

Grafana supports the following operating systems:

Note
Installation of Grafana on other operating systems is possible, but is not recommended or supported.

Hardware recommendations

Grafana requires the following minimum system resources:

Minimum recommended memory: 512 MB
Minimum recommended CPU: 1 core

Some features might require more memory or CPUs. For more information, refer to the following sizing guidance.

Sizing your deployment

This sizing guidance covers the Grafana server process only, meaning the UI, data source proxy, alert engine, and image renderer. It does not account for the resources required by your data sources. Metric stores such as Prometheus or Grafana Mimir, log stores such as Grafana Loki, and trace backends such as Grafana Tempo each have their own hardware and capacity requirements. For guidance, refer to Planning Grafana Mimir capacity, Size the Loki cluster, and Plan your Tempo deployment.

Four factors most directly drive resource needs for Grafana:

Concurrent users: active, concurrent browser sessions issuing queries or causing panels to refresh. This is the primary driver of CPU and memory load. Users who have Grafana open but are not actively viewing dashboards contribute little load, unless those dashboards have auto-refresh enabled.
Alert rules: background evaluation load on the alert scheduler. High rule counts with short evaluation intervals can saturate CPU independently of user activity. In Grafana OSS, the alert engine runs in the same process as the UI and data source proxy, so alert CPU saturation directly competes with dashboard query performance. This is why isolating alert evaluation to dedicated instances matters at Large scale. Refer to Performance considerations and limitations for details.
Data sources: while the number of proxied data source connections matters, type matters more. Plugins that use the Grafana backend data source proxy — most SQL sources such as MySQL, PostgreSQL, and Microsoft SQL Server — hold an open connection per query on the server. Pull-based metric sources such as Prometheus or Graphite are queried more efficiently and place less load on the Grafana process. Some plugins, such as certain public API or Infinity sources, execute queries directly in the browser and may place no server-side load — depending on plugin configuration and authentication requirements. A deployment with five heavily-queried proxied SQL data sources can exceed the resource needs of one with twenty Prometheus sources.
Dashboards and panels: panel count and refresh interval together determine query throughput. A dashboard with 30 panels refreshing every 10 seconds generates roughly six times the query load of the same dashboard refreshing every minute. Dashboards with many panels and short refresh intervals should be treated as a tier higher than their raw dashboard count suggests. Note that Grafana Enterprise includes query caching, which can significantly reduce this multiplier when many users view the same dashboard simultaneously and may shift a deployment down a tier.

Image rendering and large numbers of short-interval alert rules are the two most common reasons a deployment outgrows its initial sizing. Multi-organization setups and SSO or LDAP directory sync add overhead that can push a deployment into the next tier.

Deployment tiers

Use the table below to identify which tier describes your workload, then refer to the corresponding hardware baseline.

Tier	Concurrent users	Alert rules	Data sources	Dashboards
Small	< 25	< 100	< 5	< 200
Medium	25 – 200	100 – 1,000	5 – 25	200 – 2,000
Large	200+	1,000+	25+	2,000+

The dashboard count threshold assumes roughly 10-20 panels per dashboard with refresh intervals of 30 seconds or longer. Dashboards with more panels or shorter refresh intervals produce proportionally more query load and should be weighted toward the higher tier. Similarly, the data source count assumes a mix of source types. Deployments that rely heavily on proxied SQL sources should plan for the next tier up.

These thresholds are starting points. Validate sizing with a load test that reflects your actual dashboard complexity, panel count, and refresh rates before committing to production hardware. Size for your current workload and include headroom for traffic spikes and growth.

Small

Small deployments suit small teams, internal tooling, and low-traffic environments.

Resource	Minimum
CPU	2 cores
Memory	2 – 4 GB
Disk	10 – 20 GB SSD (database host)
Instances	1

Database: SQLite works for local development and small evaluation instances, but isn’t recommended for production environments. For production use, consider an external MySQL or PostgreSQL instance for higher reliability and growth capacity. For more information, refer to Supported databases.

Image rendering: optional; can run on the same host for light use. Refer to Set up image rendering.

Medium

Medium deployments suit shared team environments and departmental observability platforms.

Resource	Recommendation
CPU	4 – 8 cores
Memory	8 – 16 GB
Disk	20 – 50 GB SSD (database host)
Instances	2 (load-balanced)

Database: SQLite isn’t recommended for production environments and isn’t suitable at this tier. Use an external MySQL or PostgreSQL database. Refer to Supported databases for guidance on choosing an external database.

Image rendering: run the image renderer as a separate process or container. Each renderer worker uses approximately 1 GB of memory; size your renderer host accordingly. Refer to Set up image rendering.

High availability: if you run two or more Grafana instances, configure a Redis session store or enable sticky sessions at the load balancer to prevent users from being signed out between requests. Refer to Set up Grafana for high availability.

Large

Large deployments suit organization-wide platforms and high-traffic production environments.

Resource	Recommendation
CPU	8 – 16+ cores per instance
Memory	16 – 32+ GB per instance
Disk	50+ GB SSD, high I/O operations per second (IOPS) (database host)
Instances	3+ (load-balanced)
Network	10 Gbps or faster

Database: SQLite isn’t recommended for production environments and isn’t suitable at this tier. A highly available MySQL or PostgreSQL cluster is strongly advised. Refer to Supported databases.

Image rendering: run a dedicated renderer fleet with multiple workers, isolated from Grafana instances. Each renderer worker uses approximately 1 GB of memory. Refer to Set up image rendering.

Alert evaluation: with more than 1,000 alert rules or short evaluation intervals of under one minute, alert evaluation can saturate CPU and degrade dashboard query performance on the same instance. Isolate alert evaluation to one or more dedicated Grafana instances in remote evaluation mode to prevent this. Refer to Performance considerations and limitations.

High availability: sticky sessions or a shared Redis session store are required. Refer to Set up Grafana for high availability.

Data source latency: minimize network hops between Grafana instances and data sources. Low-latency links to your database and data sources are important at this scale.

Deployment model: managing three or more Grafana instances alongside a Redis cluster, renderer fleet, and highly available database becomes operationally complex on bare metal. Kubernetes reduces this operational burden significantly at this tier. Refer to Deploy Grafana on Kubernetes and the Grafana Helm chart for guidance.

Supported databases

Grafana requires a database to store its configuration data, such as users, data sources, and dashboards. The exact requirements depend on the size of the Grafana installation and the features you use.

Grafana supports the following databases:

By default Grafana uses an embedded SQLite database, which is stored in the Grafana installation location. If you need to migrate to a different database later, note that database schema and data migrations are customer-managed operations and fall outside the scope of Grafana Support.

Caution
SQLite isn’t recommended for production environments. It works well for local development and small evaluation instances, but it doesn’t scale for production workloads. If you want high availability, you must use either a MySQL or PostgreSQL database. For information about how to define the database configuration parameters inside the grafana.ini file, refer to [database].

Grafana supports the versions of these databases that are officially supported by the project at the time a version of Grafana is released. When a Grafana version becomes unsupported, Grafana Labs might also drop support for that database version. See the links above for the support policies for each project.

Note
PostgreSQL versions 10.9, 11.4, and 12-beta2 are affected by a bug (tracked by the PostgreSQL project as bug #15865) which prevents those versions from being used with Grafana. The bug has been fixed in more recent versions of PostgreSQL.

Note
Grafana binaries and images might not work with unsupported databases, even if they claim to be drop-in or replicate the API to their best. Binaries and images built with BoringCrypto may have different problems than other distributions of Grafana.

Grafana can report errors when relying on read-only MySQL servers, such as in high-availability failover scenarios or serverless AWS Aurora MySQL. This is a known issue; for more information, see issue #13399.

Supported web browsers

Grafana supports the current version of the following browsers. Older versions of these browsers might not be supported, so you should always upgrade to the latest browser version when using Grafana.

Note
Enable JavaScript in your browser. Running Grafana without JavaScript enabled in the browser is not supported.

Chrome/Chromium
Firefox
Safari
Microsoft Edge

Configure Grafana

Fri, 03 Apr 2026 19:43:06 +0000

Configure Grafana

Grafana has default and custom configuration files. You can customize your Grafana instance by modifying the custom configuration file or by using environment variables. To see the list of settings for a Grafana instance, refer to View server settings.

Note
After you add custom options, uncomment the relevant sections of the configuration file.

Restart Grafana for your changes to take effect.

Configuration file location

The default settings for a Grafana instance are stored in the <WORKING DIRECTORY>/conf/defaults.ini file. Don’t change this file.

Depending on your OS, your custom configuration file is either the <WORKING DIRECTORY>/conf/custom.ini file or the /usr/local/etc/grafana/grafana.ini file. You can use a custom configuration path with the --config option.

Linux

If you installed Grafana using the deb or RPM packages, then your configuration file is located at /etc/grafana/grafana.ini and a separate custom.ini is not used. This path is specified in the Grafana init.d script using --config option.

Docker

Refer to Configure a Grafana Docker image for information about environmental variables, persistent storage, and building custom Docker images.

Windows

On Windows, the sample.ini file is located in the same directory as defaults.ini file. It contains all the settings commented out. Copy sample.ini and name it custom.ini.

macOS

By default, the configuration file is located at /opt/homebrew/etc/grafana/grafana.ini or /usr/local/etc/grafana/grafana.ini. For a Grafana instance installed using Homebrew, edit the grafana.ini file directly. Otherwise, add a configuration file named custom.ini to the conf directory to override the settings defined in conf/defaults.ini.

Grafana Cloud

There is no local configuration file for Grafana Cloud stacks, but many of these settings are still configurable. To edit configurable settings, open a support ticket.

Remove comments in the .ini files

Grafana uses semicolons (;) to comment out lines in the INI file. To uncomment a line, remove the semicolon (;) from the beginning of that line.

Grafana ignores all configuration lines that begin with a semicolon.

For example:

;http_port = 3000

Override configuration with environment variables

Don’t use environment variables to add new configuration settings. Instead, use environmental variables to override existing options.

To override an option:

GF_<SECTION NAME>_<KEY>

Where <SECTION NAME> is the text within the square brackets ([ and ]) in the configuration file. All letters must be uppercase, periods (.) and dashes (-) must replaced by underscores (_). For example, if you have these configuration settings:

# default section
instance_name = ${HOSTNAME}

[security]
admin_user = admin

[auth.google]
client_secret = 0ldS3cretKey

[plugin.grafana-image-renderer]
rendering_ignore_https_errors = true

[feature_toggles]
enable = newNavigation

You can override variables on Linux machines with:

export GF_DEFAULT_INSTANCE_NAME=my-instance
export GF_SECURITY_ADMIN_USER=owner
export GF_AUTH_GOOGLE_CLIENT_SECRET=newS3cretKey
export GF_PLUGIN_GRAFANA_IMAGE_RENDERER_RENDERING_IGNORE_HTTPS_ERRORS=true
export GF_FEATURE_TOGGLES_ENABLE=newNavigation

Variable expansion

If any of your options contains the expression $__<PROVIDER>{<ARGUMENT>}or ${<ENVIRONMENT VARIABLE>}, then Grafana evaluates them. The evaluation runs the provider with the provided argument to get the final value of the option.

There are three providers: env, file, and vault.

`env` provider

The env provider expands environment variables. If you set an option to $__env{PORT} the value of the PORT environment variable replaces it. For environment variables you can also use the short-hand syntax ${PORT}.

The following example sets the log directory to the path in the LOGDIR environment variable:

[paths]
logs = $__env{LOGDIR}/grafana

`file` provider

The file provider reads a file from the filesystem. It trims whitespace from the beginning and the end of files.

The following example sets the database password to the contents of the /etc/secrets/gf_sql_password file:

[database]
password = $__file{/etc/secrets/gf_sql_password}

`vault` provider

The vault provider lets manage your secrets with Hashicorp Vault.

Note
The vault provider is only available in Grafana Enterprise.

For more information, refer to Integrate Grafana with Hashicorp Vault.

Configuration options

The following headings describe the sections and configuration options of the Grafana configuration file.

`app_mode`

Options are production and development. Default is production. Don’t change this option unless you are working on Grafana development.

`instance_name`

Set the name of the Grafana server instance. Used in logging, internal metrics, and clustering info. Defaults to: ${HOSTNAME}, which uses the value of the environment variable HOSTNAME, if that is empty or doesn’t exist Grafana tries to use system calls to get the machine name.

`[paths]`

`data`

Path to where Grafana stores the sqlite3 database (if used), file-based sessions (if used), and other data. This path is usually specified via command line in the init.d script or the systemd service file.

macOS: The default SQLite database is located at /usr/local/var/lib/grafana

`temp_data_lifetime`

How long temporary images in data directory should be kept. Defaults to: 24h. Supported modifiers: h (hours), m (minutes), for example: 168h, 30m, 10h30m. Use 0 to never clean up temporary files.

`logs`

Path to where Grafana stores logs. This path is usually specified via command line in the init.d script or the systemd service file. You can override it in the configuration file or in the default environment variable file.

Note
When overriding the default log path in the configuration file or environment variable file, Grafana still logs to the default log path until it has fully started.

Override log path using the command line argument cfg:default.paths.logs:

./grafana-server --config /custom/config.ini --homepath /custom/homepath cfg:default.paths.logs=/custom/path

macOS: By default, the log file should be located at /usr/local/var/log/grafana/grafana.log.

`plugins`

Directory where Grafana automatically scans and looks for plugins. For information about manually or automatically installing plugins, refer to Install Grafana plugins.

macOS: By default, the Mac plugin location is: /usr/local/var/lib/grafana/plugins.

`provisioning`

Directory that contains provisioning configuration files that Grafana applies on startup. Dashboards are reloaded when the JSON files change.

`[server]`

`protocol`

http,https,h2 or socket

`min_tls_version`

The TLS Handshake requires a minimum TLS version. The available options are TLS1.2 and TLS1.3. If you do not specify a version, the system uses TLS1.2.

`http_addr`

The host for the server to listen on. If your machine has more than one network interface, you can use this setting to expose the Grafana service on only one network interface and not have it available on others, such as the loopback interface. An empty value is equivalent to setting the value to 0.0.0.0, which means the Grafana service binds to all interfaces.

In environments where network address translation (NAT) is used, ensure you use the network interface address and not a final public address; otherwise, you might see errors such as bind: cannot assign requested address in the logs.

`http_port`

The port to bind to, defaults to 3000. To use port 80 you need to either give the Grafana binary permission for example:

sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/grafana-server

Or redirect port 80 to the Grafana port using:

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000

Another way is to put a web server like Nginx or Apache in front of Grafana and have them proxy requests to Grafana.

`domain`

This setting is only used in as a part of the root_url setting (see below). Important if you use GitHub or Google OAuth.

`enforce_domain`

Redirect to correct domain if the host header does not match the domain. Prevents DNS rebinding attacks. Default is false.

`root_url`

This is the full URL used to access Grafana from a web browser. This is important if you use Google or GitHub OAuth authentication (for the callback URL to be correct).

Note
This setting is also important if you have a reverse proxy in front of Grafana that exposes it through a sub-path.

In that case add the sub-path to the end of this URL setting.

`serve_from_sub_path`

Serve Grafana from sub-path specified in root_url setting. By default it is set to false for compatibility reasons.

By enabling this setting and using a sub-path in root_url like root_url = http://localhost:3000/grafana, Grafana is accessible on http://localhost:3000/grafana. If accessed without sub-path Grafana redirects the request to the sub-path.

`router_logging`

Set to true for Grafana to log all HTTP requests (not just errors). These are logged as Info level events to the Grafana log.

`static_root_path`

The path to the directory where the frontend files (HTML, JS, and CSS files). Defaults to public which is why the Grafana binary needs to be executed with working directory set to the installation path.

`enable_gzip`

Set this option to true to enable HTTP compression, this can improve transfer speed and bandwidth utilization. It is recommended that most users set it to true. By default it is set to false for compatibility reasons.

`cert_file`

Path to the certificate file (if protocol is set to https or h2).

`cert_key`

Path to the certificate key file (if protocol is set to https or h2).

`cert_pass`

Optional. Password to decrypt encrypted certificates.

`certs_watch_interval`

Controls whether cert_key and cert_file are periodically watched for changes. Disabled, by default. When enabled, cert_key and cert_file are watched for changes. If there is change, the new certificates are loaded automatically.

Warning
After the new certificates are loaded, connections with old certificates don’t work. You must reload the connections with old certificates for them to work.

`socket_gid`

GID where the socket should be set when protocol=socket. Make sure that the target group is in the group of Grafana process and that Grafana process is the file owner before you change this setting. It is recommended to set the GID as HTTP server user GID. Not set when the value is -1.

`socket_mode`

Mode where the socket should be set when protocol=socket. Make sure that Grafana process is the file owner before you change this setting.

`socket`

Path where the socket should be created when protocol=socket. Make sure Grafana has appropriate permissions for that path before you change this setting.

`cdn_url`

Specify a full HTTP URL address to the root of your Grafana CDN assets. Grafana adds edition and version paths.

For example, given a CDN URL like https://cdn.myserver.com, Grafana tries to load a JavaScript file from http://cdn.myserver.com/grafana-oss/7.4.0/public/build/app.<HASH>.js.

`read_timeout`

Sets the maximum time using a duration format (5s/5m/5ms) before timing out read of an incoming request and closing idle connections. 0 means there is no timeout for reading the request.

`[server.custom_response_headers]`

This setting enables you to specify additional headers that the server adds to HTTP(S) responses.

exampleHeader1 = exampleValue1
exampleHeader2 = exampleValue2

`[database]`

Grafana needs a database to store users and dashboards (and other things). By default it is configured to use sqlite3 which is an embedded database (included in the main Grafana binary).

`type`

Either mysql, postgres or sqlite3, it’s your choice.

`host`

Only applicable to MySQL or Postgres. Includes IP or hostname and port or in case of Unix sockets the path to it. For example, for MySQL running on the same host as Grafana: host = 127.0.0.1:3306 or with Unix sockets: host = /var/run/mysqld/mysqld.sock

`name`

The name of the Grafana database. Leave it set to grafana or some other name.

`user`

The database user (not applicable for sqlite3).

`password`

The database user’s password (not applicable for sqlite3). If the password contains # or ; you have to wrap it with triple quotes. For example """#password;"""

`url`

Use either URL or the previous fields to configure the database Example: type://user:password@host:port/name

`max_idle_conn`

The maximum number of connections in the idle connection pool.

`max_open_conn`

The maximum number of open connections to the database. For MYSQL, configure this setting on both Grafana and the database. For more information, refer to sysvar_max_connections.

`conn_max_lifetime`

Sets the maximum amount of time a connection may be reused. The default is 14400 (which means 14400 seconds or 4 hours). For MySQL, this setting should be shorter than the wait_timeout variable.

`migration_locking`

Set to false to disable database locking during the migrations. Default is true.

`locking_attempt_timeout_sec`

For mysql and postgres only. Specify the time, in seconds, to wait before failing to lock the database for the migrations. Default is 0.

`log_queries`

Set to true to log the SQL calls and execution times.

`ssl_mode`

For Postgres, use any valid libpq sslmode, for example, disable, require, verify-full, etc. For MySQL, use either true, false, or skip-verify.

`ssl_sni`

For Postgres, set to 0 to disable Server Name Indication. This is enabled by default on SSL-enabled connections.

`isolation_level`

Only the MySQL driver supports isolation levels in Grafana. In case the value is empty, the driver’s default isolation level is applied. Available options are “READ-UNCOMMITTED”, “READ-COMMITTED”, “REPEATABLE-READ” or “SERIALIZABLE”.

`ca_cert_path`

The path to the CA certificate to use. On many Linux systems, certs can be found in /etc/ssl/certs.

`client_key_path`

The path to the client key. Only if server requires client authentication.

`client_cert_path`

The path to the client cert. Only if server requires client authentication.

`server_cert_name`

The common name field of the certificate used by the mysql or postgres server. Not necessary if ssl_mode is set to skip-verify.

`path`

Only applicable for sqlite3 database. The path to the database file.

`cache_mode`

For “sqlite3” only. Shared cache setting used for connecting to the database. (private, shared) Defaults to private.

`wal`

For “sqlite3” only. Setting to enable/disable Write-Ahead Logging. The default value is false (disabled).

`query_retries`

This setting applies to sqlite only and controls the number of times the system retries a query when the database is locked. The default value is 0 (disabled).

`transaction_retries`

This setting applies to sqlite only and controls the number of times the system retries a transaction when the database is locked. The default value is 5.

`instrument_queries`

Set to true to add metrics and tracing for database queries. The default value is false.

`skip_dashboard_uid_migration_on_startup`

Set to true to skip dashboard UID migrations on startup. Improves startup performance for instances with large numbers of annotations who do not plan to downgrade Grafana. The default value is false.

`[remote_cache]`

Caches authentication tokens and other temporary authentication-related data in the configured database, Redis, or Memcached. This setting doesn’t configure Query Caching in Grafana Enterprise.

Note
This setting doesn’t control user session storage. User sessions are always stored in the main database configured in [database] regardless of your [remote_cache] settings.

`type`

Either redis, memcached, or database. Defaults to database

`connstr`

The remote cache connection string. The format depends on the type of the remote cache. Options are database, redis, and memcache.

`database`

Leave empty when using database and Grafana uses the primary database.

`redis`

Example connection string: addr=127.0.0.1:6379,pool_size=100,db=0,username=grafana,password=grafanaRocks,ssl=false

addr is the host : port of the Redis server.
pool_size (optional) is the number of underlying connections that can be made to Redis.
db (optional) is the number identifier of the Redis database you want to use.
username (optional) is the connection identifier to authenticate the current connection.
password (optional) is the connection secret to authenticate the current connection.
ssl (optional) is if SSL should be used to connect to Redis server. The value may be true, false, or insecure. Setting the value to insecure skips verification of the certificate chain and hostname when making the connection.

`memcache`

Example connection string: 127.0.0.1:11211

`[dataproxy]`

`logging`

This enables data proxy logging, default is false.

`timeout`

How long the data proxy should wait before timing out. Default is 30 seconds.

This setting also applies to core backend HTTP data sources where query requests use an HTTP client with timeout set.

`keep_alive_seconds`

Interval between keep-alive probes. Default is 30 seconds. For more details, refer to the Dialer.KeepAlive documentation.

`tls_handshake_timeout_seconds`

The length of time that Grafana waits for a successful TLS handshake with the data source. Default is 10 seconds. For more information, refer to the Transport.TLSHandshakeTimeout documentation.

`expect_continue_timeout_seconds`

The length of time that Grafana waits for the first response headers from a data source after fully writing the request headers, if the request has an Expect: 100-continue header. A value of 0 results in the body being sent immediately. Default is 1 second. For more information, refer to the Transport.ExpectContinueTimeout documentation.

`max_conns_per_host`

Limits the total number of connections per host, including connections in the dialing, active, and idle states. On limit violation, dials are blocked. A value of 0 means that there are no limits. Default is 0. For more information, refer to the Transport.MaxConnsPerHost documentation.

`max_idle_connections`

The maximum number of idle connections that Grafana maintains. Default is 100. For more information, refer to the Transport.MaxIdleConns documentation.

`idle_conn_timeout_seconds`

The length of time that Grafana maintains idle connections before closing them. Default is 90 seconds. For more information, refer to the Transport.IdleConnTimeout documentation.

`send_user_header`

If enabled and user is not anonymous, data proxy adds the X-Grafana-User header with username into the request. Default is false.

`response_limit`

Limits the amount of bytes that Grafana reads from responses of outgoing HTTP requests. Default is 0 which means disabled.

`row_limit`

Limits the number of rows that Grafana processes from SQL data sources. Default is 1000000.

`user_agent`

Sets a custom value for the User-Agent header for outgoing data proxy requests. If empty, the default value is Grafana/<BuildVersion> (for example Grafana/9.0.0).

`[analytics]`

`enabled`

This option is also known as usage analytics. When false, this option disables the writers that write to the Grafana database and the associated features, such as dashboard and data source insights, presence indicators, and advanced dashboard search. The default value is true.

`reporting_enabled`

When enabled Grafana sends anonymous usage statistics to stats.grafana.org. Grafana doesn’t track IP addresses, only counters of running instances, versions, dashboards, and errors.

The anonymous usage statistics help inform the future development of Grafana. Counters are sent every 24 hours. Default value is true.

`check_for_updates`

Set to false to disable checking for new versions of Grafana in GitHub. When enabled, the check for a new version runs every ten minutes. It notifies, via the UI, when a new version is available. The check itself doesn’t cause automatic updates of the Grafana software, nor does it send any sensitive information.

`check_for_plugin_updates`

Set to false to disable checking for new versions of installed plugins from https://grafana.com. When enabled, the check for a new plugin runs every ten minutes. It notifies, via the UI, when a new plugin update exists. The check itself doesn’t cause any automatic updates of any plugins, nor does it send any sensitive information.

`google_analytics_ua_id`

If you want to track Grafana usage with Google Analytics specify your Universal Analytics ID here. By default this feature is disabled.

`google_analytics_4_id`

If you want to track Grafana usage with Google Analytics 4 specify your GA4 ID here. By default this feature is disabled.

`google_tag_manager_id`

Google Tag Manager ID, only enabled if you enter an ID here.

`rudderstack_write_key`

If you want to track Grafana usage via RudderStack specify your RudderStack Write Key here. The rudderstack_data_plane_url must also be provided for this feature to be enabled. By default this feature is disabled.

`rudderstack_data_plane_url`

RudderStack data plane URL to receive RudderStack events. You must also provide the rudderstack_write_key to enable this feature.

`rudderstack_sdk_url`

Optional. If tracking with RudderStack is enabled, you can provide a custom URL to load the RudderStack SDK.

`rudderstack_v3_sdk_url`

Optional. This is mirroring the old configuration option, which will be deprecated. If rudderstack_sdk_url and rudderstack_v3_sdk_url are both set, the feature toggle rudderstackUpgrade will control which one is loaded.

`rudderstack_config_url`

Optional. If tracking with RudderStack is enabled, you can provide a custom URL to load the RudderStack configuration.

`rudderstack_integrations_url`

Optional. If tracking with RudderStack is enabled, you can provide a custom URL to load the SDK for destinations running in device mode. This setting is only valid for RudderStack version 1.1 and higher.

`application_insights_connection_string`

If you want to track Grafana usage via Azure Application Insights, then specify your Application Insights connection string. Since the connection string contains semicolons, you need to wrap it in backticks (`). By default, tracking usage is disabled.

`application_insights_endpoint_url`

Optionally, use this option to override the default endpoint address for Application Insights data collecting. For details, refer to the Azure documentation.

`application_insights_auto_route_tracking`

Optionally, use this to configure enableAutoRouteTracking in Azure Application Insights. Defaults to true. For more details, refer to the Azure documentation

`feedback_links_enabled`

Set to false to remove all feedback links from the UI. Default is true.

`[security]`

`disable_initial_admin_creation`

Disable creation of a Grafana Admin user on first start of Grafana. Default is false.

`admin_user`

The name of the default Grafana Admin user, who has full permissions. Default is admin.

`admin_password`

The password of the default Grafana Admin. Set once on first-run. Default is admin.

`admin_email`

The email of the default Grafana Admin, created on startup. Default is admin@localhost.

`secret_key`

Used for signing some data source settings like secrets and passwords, the encryption format used is AES-256 in CFB mode. Cannot be changed without requiring an update to data source settings to re-encode them.

`disable_gravatar`

Set to true to disable the use of Gravatar for user profile images. Default is false.

`data_source_proxy_whitelist`

Define a allowlist of IP addresses or domains with ports, that can be used in data source URLs with the Grafana data source proxy.

The format is <IP> or <DOMAIN>:<PORT> separated by spaces. PostgreSQL, MySQL, and MSSQL data sources don’t use the proxy and are not affected by this setting.

`disable_brute_force_login_protection`

Set to true to disable brute force login protection. Default is false. Login is blocked for five minutes if all login attempts are spent within a 5 minute window.

`brute_force_login_protection_max_attempts`

Configure how many login attempts can be made within a five minute window before being blocked. Default is 5.

`disable_username_login_protection`

Set to true to disable brute force login protection by username. Default is false. User will be unable to login for 5 minutes if all login attempts are spent within a 5 minute window.

`disable_ip_address_login_protection`

Set to true to disable brute force login protection by IP address. Default is true. Anyone from the IP address will be unable to login for 5 minutes if all login attempts are spent within a 5 minute window.

`cookie_secure`

Set to true if you host Grafana behind HTTPS. Default is false.

`cookie_samesite`

Sets the SameSite cookie attribute and prevents the browser from sending this cookie along with cross-site requests. The main goal is to mitigate the risk of cross-origin information leakage. This setting also provides some protection against cross-site request forgery attacks (CSRF), read more about SameSite here. Valid values are lax, strict, none, and disabled. Default is lax. Using value disabled does not add any SameSite attribute to cookies.

If you want to use OAuth/SAML for login, it is necessary to configure this attribute as lax.

`allow_embedding`

When false, the HTTP header X-Frame-Options: deny is set in Grafana HTTP responses which instructs browsers to not allow rendering Grafana in a <frame>, <iframe>, <embed> or <object>. The main goal is to mitigate the risk of Clickjacking. Default is false.

`strict_transport_security`

Set to true if you want to enable HTTP Strict-Transport-Security (HSTS) response header. Only use this when HTTPS is enabled in your configuration, or when there is another upstream system that ensures your application does HTTPS (like a frontend load balancer). HSTS tells browsers that the site should only be accessed using HTTPS.

`strict_transport_security_max_age_seconds`

Sets how long a browser should cache HSTS in seconds. Only applied if strict_transport_security is enabled. The default value is 86400.

`strict_transport_security_preload`

Set to true to enable HSTS preloading option. Only applied if strict_transport_security is enabled. The default value is false.

`strict_transport_security_subdomains`

Set to true to enable the HSTS includeSubDomains option. Only applied if strict_transport_security is enabled. The default value is false.

`x_content_type_options`

Set to false to disable the X-Content-Type-Options response header. The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. The default value is true.

`x_xss_protection`

Set to false to disable the X-XSS-Protection header, which tells browsers to stop pages from loading when they detect reflected cross-site scripting (XSS) attacks. The default value is true.

`content_security_policy`

Set to true to add the Content-Security-Policy header to your requests. The Content Security Policy (CSP) controls which resources that the user agent can load and helps prevent XSS attacks.

`content_security_policy_template`

Set the policy template that’s used to add the Content-Security-Policy header to your requests. $NONCE in the template includes a random nonce.

`content_security_policy_report_only`

Set to true to add the Content-Security-Policy-Report-Only header to your requests. CSP in “Report Only” mode lets you to experiment with policies by monitoring their effects without enforcing them. You can enable both policies simultaneously.

`content_security_policy_template`

Set the policy template that’s used to add the Content-Security-Policy-Report-Only header to your requests. $NONCE in the template includes a random nonce.

`actions_allow_post_url`

Sets API paths to be accessible between plugins using the POST verb. If the value is empty, you can only pass remote requests through the proxy. If the value is set, you can also send authenticated POST requests to the local server. You typically use this to enable backend communication between plugins.

This is a comma-separated list which uses glob matching.

The following example allows access to all plugins that have a backend:

actions_allow_post_url=/api/plugins/*

The following example limits access to the backend of a single plugin:

actions_allow_post_url=/api/plugins/grafana-special-app

`csrf_trusted_origins`

List of additional allowed URLs to pass by the CSRF check. Suggested when authentication comes from an IdP.

`csrf_additional_headers`

List of allowed headers to be set by the user. Suggested to use for if authentication lives behind reverse proxies.

`csrf_always_check`

Set to true to execute the CSRF check even if the login cookie is not in a request (default false).

`enable_frontend_sandbox_for_plugins`

Comma-separated list of plugins IDs to load inside the frontend sandbox.

`[snapshots]`

`enabled`

Set to false to disable the snapshot feature (default true).

`external_enabled`

Set to false to disable external snapshot publish endpoint (default true).

`external_snapshot_url`

Set root URL to a Grafana instance where you want to publish external snapshots (defaults to https://snapshots.raintank.io).

`external_snapshot_name`

Set name for external snapshot button. Defaults to Publish to snapshots.raintank.io.

`public_mode`

Set to true to enable this Grafana instance to act as an external snapshot server and allow unauthenticated requests for creating and deleting snapshots. Default is false.

`[dashboards]`

`versions_to_keep`

Number dashboard versions to keep (per dashboard). Default: 20, Minimum: 1.

`min_refresh_interval`

This feature prevents users from setting the dashboard refresh interval to a lower value than a given interval value. The default interval value is 5 seconds. The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d). For example 30s or 1m.

This also limits the refresh interval options in Explore.

`default_home_dashboard_path`

Path to the default home dashboard. If this value is empty, then Grafana uses StaticRootPath + “dashboards/home.json”.

Note
On Linux, Grafana uses /usr/share/grafana/public/dashboards/home.json as the default home dashboard location.

`[dashboard_cleanup]`

Settings related to cleaning up associated dashboards information if the dashboard was deleted through /apis.

`interval`

How often to run the job to cleanup associated resources. The default interval is 30s. The minimum allowed value is 10s to ensure the system isn’t overloaded.

The interval string must include a unit suffix (ms, s, m, h), e.g. 30s or 1m.

`batch_size`

Number of deleted dashboards to process in each batch during the cleanup process. Default: 10, Minimum: 5, Maximum: 200.

Increasing this value allows processing more dashboards in each cleanup cycle but may impact system performance.

`[datasources]`

`default_manage_alerts_ui_toggle`

Default behavior for the “Manage alerts via Alerting UI” toggle when configuring a data source. It only works if the data source’s jsonData.manageAlerts prop does not contain a previously configured value.

`default_allow_recording_rules_target_alerts_ui_toggle`

Default behavior for the “Allow as recording rules target” toggle when configuring a data source. It only works if the data source’s jsonData.allowAsRecordingRulesTarget prop does not contain a previously configured value.

`[sql_datasources]`

`max_open_conns_default`

For SQL data sources (MySql, Postgres, MSSQL) you can override the default maximum number of open connections (default: 100). The value configured in data source settings is preferred over the default value.

`max_idle_conns_default`

For SQL data sources (MySql, Postgres, MSSQL) you can override the default allowed number of idle connections (default: 100). The value configured in data source settings is preferred over the default value.

`max_conn_lifetime_default`

For SQL data sources (MySql, Postgres, MSSQL) you can override the default maximum connection lifetime specified in seconds (default: 14400). The value configured in data source settings is preferred over the default value.

`[users]`

`allow_sign_up`

Set to false to prohibit users from being able to sign up or create user accounts. Default is false. A Grafana Admin can still create users. For more information about creating a user, refer to Add a user.

`allow_org_create`

Set to false to prohibit users from creating new organizations. Default is false.

`auto_assign_org`

Set to true to automatically add new users to the main organization (ID 1). When set to false, new users automatically cause a new organization to be created for that new user. The organization is created even if the allow_org_create setting is set to false. Default is true.

`auto_assign_org_id`

Set this value to automatically add new users to the provided org. This requires auto_assign_org to be set to true. The organization must already exist. Default is 1.

`auto_assign_org_role`

The auto_assign_org_role setting determines the default role assigned to new users in the main organization if auto_assign_org setting is set to true. You can set this to one of the following roles: (Viewer (default), Admin, Editor, and None). For example:

auto_assign_org_role = Viewer

`verify_email_enabled`

Require email validation before sign up completes or when updating a user email address. Default is false.

`login_default_org_id`

Set the default organization for users when they sign in. The default is -1.

`login_hint`

Text used as placeholder text on login page for login/username input.

`password_hint`

Text used as placeholder text on login page for password input.

`default_theme`

Sets the default UI theme: dark, light, or system. The default theme is dark.

system matches the user’s system theme.

`default_language`

This option sets the default UI language if a supported IETF language tag like en-US is available. If set to detect, the default UI language is determined by browser preference. The default is en-US.

`home_page`

Path to a custom home page. Users are only redirected to this if the default home dashboard is used. It should match a frontend route and contain a leading slash.

`External user management`

If you manage users externally you can replace the user invite button for organizations with a link to an external site together with a description.

`viewers_can_edit`

Note
This option is deprecated - assign your viewers as editors, if you are using RBAC assign the data sources explorer role to your users.

Viewers can access and use Explore and perform temporary edits on panels in dashboards they have access to. They cannot save their changes. Default is false.

`user_invite_max_lifetime_duration`

The duration in time a user invitation remains valid before expiring. This setting should be expressed as a duration. Examples: 6h (hours), 2d (days), 1w (week). Default is 24h (24 hours). The minimum supported duration is 15m (15 minutes).

`verification_email_max_lifetime_duration`

The duration in time a verification email, used to update the email address of a user, remains valid before expiring. This setting should be expressed as a duration. Examples: 6h (hours), 2d (days), 1w (week). Default is 1h (1 hour).

`last_seen_update_interval`

The frequency of updating a user’s last seen time. This setting should be expressed as a duration. Examples: 1h (hour), 15m (minutes) Default is 15m (15 minutes). The minimum supported duration is 5m (5 minutes). The maximum supported duration is 1h (1 hour).

`hidden_users`

This is a comma-separated list of usernames. Users specified here are hidden in the Grafana UI. They are still visible to Grafana administrators and to themselves.

`[auth]`

Grafana provides many ways to authenticate users. Refer to the Grafana Authentication overview and other authentication documentation for detailed instructions on how to set up and configure authentication.

`login_cookie_name`

The cookie name for storing the auth token. Default is grafana_session.

`login_maximum_inactive_lifetime_duration`

The maximum lifetime (duration) an authenticated user can be inactive before being required to login at next visit. Default is 7 days (7d). This setting should be expressed as a duration such 5m (minutes), 6h (hours), 10d (days), 2w (weeks), or 1M (month). The lifetime resets at each successful token rotation (token_rotation_interval_minutes).

`login_maximum_lifetime_duration`

The maximum lifetime (duration) an authenticated user can be logged in since login time before being required to login. Default is 30 days (30d). This setting should be expressed as a duration such 5m (minutes), 6h (hours), 10d (days), 2w (weeks), or 1M (month).

`token_rotation_interval_minutes`

How often auth tokens are rotated for authenticated users when the user is active. The default is each 10 minutes.

`disable_login_form`

Set to true to disable (hide) the login form, useful if you use OAuth 2.0. Default is false.

`disable_signout_menu`

Set to true to disable the sign out link in the side menu. This is useful if you use auth.proxy. Default is false.

`signout_redirect_url`

The URL the user is redirected to upon signing out. To support OpenID Connect RP-Initiated Logout, the user must add post_logout_redirect_uri to the signout_redirect_url.

Example:

signout_redirect_url = http://localhost:8087/realms/grafana/protocol/openid-connect/logout?post_logout_redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Flogin

`oauth_auto_login`

Note
This option is deprecated - use auto_login option for specific OAuth provider instead.

Set to true to attempt login with OAuth automatically, skipping the login screen. This setting is ignored if multiple OAuth providers are configured. Default is false.

`oauth_state_cookie_max_age`

How many seconds the OAuth state cookie lives before being deleted. Default is 600 (seconds) Administrators can increase this if they experience OAuth login state mismatch errors.

`oauth_login_error_message`

A custom error message for when users are unauthorized. Default is a key for an internationalized phrase in the frontend, Login provider denied login request.

`oauth_refresh_token_server_lock_min_wait_ms`

Minimum wait time in milliseconds for the server lock retry mechanism. Default is 1000 (milliseconds). The server lock retry mechanism is used to prevent multiple Grafana instances from simultaneously refreshing OAuth tokens. This mechanism waits at least this amount of time before retrying to acquire the server lock.

There are five retries in total, so with the default value, the total wait time (for acquiring the lock) is at least 5 seconds (the wait time between retries is calculated as random(n, n + 500)), which means that the maximum token refresh duration must be less than 5-6 seconds.

If you experience issues with the OAuth token refresh mechanism, you can increase this value to allow more time for the token refresh to complete.

`oauth_skip_org_role_update_sync`

Note
This option is removed from G11 in favor of OAuth provider specific skip_org_role_sync settings. The following sections explain settings for each provider.

If you want to change the oauth_skip_org_role_update_sync setting from true to false, then each provider you have set up, use the skip_org_role_sync setting to specify whether you want to skip the synchronization.

Warning
Currently if no organization role mapping is found for a user, Grafana doesn’t update the user’s organization role.

If oauth_skip_org_role_update_sync option is set to false, users with no mapping are reset to the default organization role on every login.

For more information, refer to auto_assign_org_role option.

`skip_org_role_sync`

skip_org_role_sync prevents the synchronization of organization roles for a specific OAuth integration, while the deprecated setting oauth_skip_org_role_update_sync affects all configured OAuth providers.

The default value for skip_org_role_sync is false.

With skip_org_role_sync set to false, the users’ organization and role is reset on every new login, based on the external provider’s role. See your provider in the tables below.

With skip_org_role_sync set to true, when a user logs in for the first time, Grafana sets the organization role based on the value specified in auto_assign_org_role and forces the organization to auto_assign_org_id when specified, otherwise it falls back to OrgID 1.

Note
Enabling skip_org_role_sync also disables the synchronization of Grafana Admins from the external provider, as such allow_assign_grafana_admin is ignored.

Use this setting when you want to manage the organization roles of your users from within Grafana and be able to manually assign them to multiple organizations, or to prevent synchronization conflicts when they can be synchronized from another provider.

The behavior of oauth_skip_org_role_update_sync and skip_org_role_sync, can be seen in the tables below:

[auth.grafana_com]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with Grafana.com role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role synchronization for Grafana.com users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for Grafana.com users and all other OAuth providers. Role is set to `auto_assign_org_role`.	true

[auth.azuread]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with AzureAD role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role synchronization for AzureAD users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for AzureAD users and all other OAuth providers. Role is set to `auto_assign_org_role`.	true

[auth.google]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	User organization role is set to `auto_assign_org_role` and cannot be changed.	false
true	false	User organization role is set to `auto_assign_org_role` and can be changed in Grafana.	true
false	true	User organization role is set to `auto_assign_org_role` and can be changed in Grafana.	true
true	true	User organization role is set to `auto_assign_org_role` and can be changed in Grafana.	true

Note
For GitLab, GitHub, Okta, Generic OAuth providers, Grafana synchronizes organization roles and sets Grafana Admins. The allow_assign_grafana_admin setting is also accounted for, to allow or not setting the Grafana Admin role from the external provider.

[auth.github]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with GitHub role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for GitHub users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for GitHub users. Role is set to `auto_assign_org_role`.	true

[auth.gitlab]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with GitLab role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for GitLab users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for GitLab users. Role is set to `auto_assign_org_role`.	true

[auth.generic_oauth]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with the provider’s role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for the provider’s users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for the provider’s users. Role is set to `auto_assign_org_role`.	true

[auth.okta]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with Okta role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for Okta users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for Okta users. Role is set to `auto_assign_org_role`.	true

Example `skip_org_role_sync`

[auth.google]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Example Scenario
false	false	Synchronized with Google Auth organization roles	A user logs in to Grafana using their Google account and their organization role is automatically set based on their role in Google.
true	false	Skipped synchronization of organization roles from all OAuth providers	A user logs in to Grafana using their Google account and their organization role is not set based on their role. But Grafana Administrators can modify the role from the UI.
false	true	Skipped synchronization of organization roles Google	A user logs in to Grafana using their Google account and their organization role is not set based on their role in Google. But Grafana Administrators can modify the role from the UI.
true	true	Skipped synchronization of organization roles from all OAuth providers including Google	A user logs in to Grafana using their Google account and their organization role is not set based on their role in Google. But Grafana Administrators can modify the role from the UI.

`api_key_max_seconds_to_live`

Limit of API key seconds to live before expiration. Default is -1 (unlimited).

`sigv4_auth_enabled`

Set to true to enable the AWS Signature Version 4 Authentication option for HTTP-based data sources. Default is false.

`sigv4_verbose_logging`

Set to true to enable verbose request signature logging when AWS Signature Version 4 Authentication is enabled. Default is false.

`managed_service_accounts_enabled`

Only available in Grafana 11.3+.

Set to true to enable the use of managed service accounts for plugin authentication. Default is false.

Note
This feature only supports single-organization deployments. The plugin’s service account is automatically created in the default organization. This means the plugin can only access data and resources within that specific organization.

`[auth.anonymous]`

Refer to Anonymous authentication for detailed instructions.

`[auth.github]`

Refer to GitHub OAuth2 authentication for detailed instructions.

`[auth.gitlab]`

Refer to GitLab OAuth 2.0 authentication for detailed instructions.

`[auth.google]`

Refer to Google OAuth2 authentication for detailed instructions.

`[auth.grafananet]`

Legacy key names, still in the configuration file so they work in environment variables.

`[auth.grafana_com]`

Legacy key names, still in the configuration file so they work in environment variables.

`[auth.azuread]`

Refer to Entra ID OAuth2 authentication for detailed instructions.

`[auth.okta]`

Refer to Okta OAuth2 authentication for detailed instructions.

`[auth.generic_oauth]`

Refer to Generic OAuth authentication for detailed instructions.

`[auth.basic]`

Refer to Basic authentication for detailed instructions.

`[auth.proxy]`

Refer to Auth proxy authentication for detailed instructions.

`[auth.ldap]`

Refer to LDAP authentication for detailed instructions.

`[aws]`

You can configure core and external AWS plugins.

`allowed_auth_providers`

Specify what authentication providers the AWS plugins allow. For a list of allowed providers, refer to the data source configuration page for a given plugin. If you configure a plugin by provisioning, only providers that are specified in allowed_auth_providers are allowed.

Options: default (AWS SDK default), keys (Access and secret key), credentials (Credentials file), ec2_iam_role (EC2 IAM role)

`assume_role_enabled`

Set to false to disable AWS authentication from using an assumed role with temporary security credentials. For details about assume roles, refer to the AWS API reference documentation about the AssumeRole operation.

If this option is disabled, the Assume Role and the External Id field are removed from the AWS data source configuration page. If the plugin is configured using provisioning, it is possible to use an assumed role as long as assume_role_enabled is set to true.

`list_metrics_page_limit`

Use the List Metrics API option to load metrics for custom namespaces in the Amazon CloudWatch data source. By default, the page limit is 500.

`[azure]`

Grafana supports additional integration with Azure services when hosted in the Azure Cloud.

`cloud`

Azure cloud environment where Grafana is hosted:

Azure Cloud	Value
Microsoft Azure public cloud	AzureCloud (default)
Microsoft Chinese national cloud	AzureChinaCloud
US Government cloud	AzureUSGovernment
Microsoft German national cloud (“Black Forest”)	AzureGermanCloud

`clouds_config`

The JSON configuration defines a list of Azure clouds and their associated properties when hosted in custom Azure environments.

For example:

clouds_config = `[
		{
			"name":"CustomCloud1",
			"displayName":"Custom Cloud 1",
			"aadAuthority":"https://login.cloud1.contoso.com/",
			"properties":{
				"azureDataExplorerSuffix": ".kusto.windows.cloud1.contoso.com",
				"logAnalytics":            "https://api.loganalytics.cloud1.contoso.com",
				"portal":                  "https://portal.azure.cloud1.contoso.com",
				"prometheusResourceId":    "https://prometheus.monitor.azure.cloud1.contoso.com",
				"resourceManager":         "https://management.azure.cloud1.contoso.com"
			}
		}]`

`managed_identity_enabled`

Specifies whether Grafana is running in Azure with Managed Identity configured (for example, running in a Azure Virtual Machines instance). Disabled by default, needs to be explicitly enabled.

`managed_identity_client_id`

The client ID to use for user-assigned managed identity.

Should be set for user-assigned identity and should be empty for system-assigned identity.

`workload_identity_enabled`

Specifies whether Entra ID Workload Identity authentication should be enabled in data sources that support it.

For more documentation on Entra ID Workload Identity, review Entra ID Workload Identity documentation.

Disabled by default, needs to be explicitly enabled.

`workload_identity_tenant_id`

Tenant ID of the Entra ID Workload Identity.

Allows to override default tenant ID of the Entra ID identity associated with the Kubernetes service account.

`workload_identity_client_id`

Client ID of the Entra ID Workload Identity.

Allows to override default client ID of the Entra ID identity associated with the Kubernetes service account.

`workload_identity_token_file`

Custom path to token file for the Entra ID Workload Identity.

Allows to set a custom path to the projected service account token file.

`user_identity_enabled`

Specifies whether user identity authentication (on behalf of currently signed-in user) should be enabled in data sources that support it (requires AAD authentication).

Disabled by default, needs to be explicitly enabled.

`user_identity_fallback_credentials_enabled`

Specifies whether user identity authentication fallback credentials should be enabled in data sources. Enabling this allows data source creators to provide fallback credentials for backend-initiated requests, such as alerting, recorded queries, and so on.

It is by default and needs to be explicitly disabled. It doesn’t have any effect if user identity authentication is disabled.

`user_identity_token_url`

Override token URL for Azure Active Directory.

By default is the same as token URL configured for AAD authentication settings.

`user_identity_client_authentication`

Override client authentication method for Azure Active Directory. Currently supported values are client_secret_post and managed_identity.

By default is the same as client authentication method configured for AAD authentication settings.

`user_identity_client_id`

Override ADD application ID which would be used to exchange users token to an access token for the data source.

By default is the same as used in AAD authentication or can be set to another application (for OBO flow).

`user_identity_client_secret`

Override the AAD application client secret.

By default is the same as used in AAD authentication or can be set to another application (for OBO flow).

`user_identity_managed_identity_client_id`

Override the AAD application managed identity client ID of the federated credential configured as a user-assigned managed identity.

By default is the same as used in AAD authentication or can be set to another managed identity (for OBO flow).

`user_identity_federated_credential_audience`

Override the AAD federated credential audience of the federated credential configured as a user-assigned managed identity.

By default is the same as used in AAD authentication or can be set to another audience (for OBO flow).

`forward_settings_to_plugins`

Set plugins to receive Azure settings via plugin context.

By default, this includes all Grafana Labs owned Azure plugins or those that use Azure settings (Azure Monitor, Azure Data Explorer, Prometheus, MSSQL).

`azure_entra_password_credentials_enabled`

Specifies whether Entra password authentication can be used for the MSSQL data source. This authentication isn’t recommended and consideration should be taken before enabling this.

Disabled by default, needs to be explicitly enabled.

`[auth.jwt]`

Refer to JWT authentication for more information.

`[smtp]`

Email server settings.

`enabled`

Enable this to allow Grafana to send email. Default is false.

`host`

Default is localhost:25. Use port 465 for implicit TLS.

`user`

In case of SMTP auth, default is empty.

`password`

In case of SMTP auth, default is empty. If the password contains # or ;, then you have to wrap it with triple quotes. Example: “”"#password;"""

`cert_file`

File path to a cert file, default is empty.

`key_file`

File path to a key file, default is empty.

`skip_verify`

Verify SSL for SMTP server, default is false.

`from_address`

Address used when sending out emails, default is admin@grafana.localhost.

`from_name`

Name to be used when sending out emails, default is Grafana.

`ehlo_identity`

Name to be used as client identity for EHLO in SMTP conversation, default is <instance_name>.

`startTLS_policy`

Either OpportunisticStartTLS, MandatoryStartTLS, NoStartTLS, or empty. Default is empty.

`enable_tracing`

Enable trace propagation in email headers, using the traceparent, tracestate and (optionally) baggage fields. Default is false. To enable, you must first configure tracing in one of the tracing.opentelemetry.* sections.

`[smtp.static_headers]`

Enter key-value pairs on their own lines to be included as headers on outgoing emails. All keys must be in canonical mail header format. Examples: Foo=bar, Foo-Header=bar.

`[emails]`

`welcome_email_on_sign_up`

Default is false.

`templates_pattern`

Enter a comma separated list of template patterns. Default is emails/*.html, emails/*.txt.

`content_types`

Enter a comma-separated list of content types that should be included in the emails that are sent. List the content types according descending preference. For example, text/html, text/plain for HTML as the most preferred. The order of the parts is significant as the mail clients uses the media type that is supported and most preferred by the sender. Supported content types are text/html and text/plain. Default is text/html.

`[log]`

Grafana logging options.

`mode`

Options are console, file, and syslog. Default is console and file. Use spaces to separate multiple modes, for example, console file.

`level`

Options are debug, info, warn, error. critical is an alias for error. Default is info.

`filters`

Optional settings to set different levels for specific loggers. For example: filters = sqlstore:debug

You can use multiple filters with a comma-seperated list: For example: filters = sqlstore:debug,plugins:info

The equivalent for a docker-compose.yaml looks like this:

GF_LOG_FILTERS: sqlstore:debug,plugins:info
GF_LOG_LEVEL: error

`user_facing_default_error`

Use this configuration option to set the default error message shown to users. This message is displayed instead of sensitive backend errors, which should be obfuscated. The default message is Please inspect the Grafana server log for details..

`[log.console]`

Only applicable when console is used in [log] mode.

`level`

See [log] level for values. Default is inherited from [log] level.

`format`

Log line format, valid options are text, console, and json. Default is console.

`[log.file]`

Only applicable when file used in [log] mode.

`level`

See [log] level for values. Default is inherited from [log] level.

`format`

Log line format, valid options are text, console, and json. Default is text.

`log_rotate`

Enable automated log rotation, valid options are false or true. Default is true. When enabled use the max_lines, max_size_shift, daily_rotate and max_days to configure the behavior of the log rotation.

`max_lines`

Maximum lines per file before rotating it. Default is 1000000.

`max_size_shift`

Maximum size of file before rotating it. Default is 28, which means 1 << 28, 256MB.

`daily_rotate`

Enable daily rotation of files, valid options are false or true. Default is true.

`max_days`

Maximum number of days to keep log files. Default is 7.

`[log.syslog]`

Only applicable when syslog used in [log] mode.

`level`

See [log] level for values. Default is inherited from [log] level.

`format`

Log line format, valid options are text, console, and json. Default is text.

`network and address`

Syslog network type and address. This can be UDP, TCP, or UNIX. If left blank, then the default UNIX endpoints are used.

`facility`

Syslog facility. Valid options are user, daemon or local0 through local7. Default is empty.

`tag`

Syslog tag. By default, the process’s argv[0] is used.

`[log.frontend]`

`enabled`

Grafana Faro instrumentation is initialized. Default is false. Enables the default set of instrumentations from getWebInstrumentations. See the options below to selectively disable some of these.

`custom_endpoint`

Custom HTTP endpoint to send events captured by the Grafana Faro agent to. Default, /log-grafana-javascript-agent, logs the events to standard output.

`api_key`

If custom_endpoint required authentication, you can set the API key here. Only relevant for Grafana JavaScript Agent provider.

`instrumentations_console_enabled`

Enables the Console instrumentation for Grafana Faro, defaults to true.

`instrumentations_performance_enabled`

Enables the Performance instrumentation for Grafana Faro, defaults to true.

`instrumentations_csp_enabled`

Enables the Content Security Policy Violations instrumentation for Grafana Faro, defaults to true.

`instrumentations_tracing_enabled`

Enables the Tracing instrumentation for Grafana Faro, defaults to true.

`log_endpoint_requests_per_second_limit`

Requests per second limit enforced per an extended period, for Grafana backend log ingestion endpoint, /log-grafana-javascript-agent. Default is 3.

`log_endpoint_burst_limit`

Maximum requests accepted per short interval of time for Grafana backend log ingestion endpoint, /log-grafana-javascript-agent. Default is 15.

`bot_filter_enabled`

Enables the bot filter for the Grafana Faro JavaScript agent integration. Default is false. When enabled, it will filter out requests from known bots and crawlers.

`[quota]`

Set quotas to -1 to make unlimited.

`enabled`

Enable usage quotas. Default is false.

`org_user`

Limit the number of users allowed per organization. Default is 10.

`org_dashboard`

Limit the number of dashboards allowed per organization. Default is 100.

`org_data_source`

Limit the number of data sources allowed per organization. Default is 10.

`org_api_key`

Limit the number of API keys that can be entered per organization. Default is 10.

`org_alert_rule`

Limit the number of alert rules that can be entered per organization. Default is 100.

`user_org`

Limit the number of organizations a user can create. Default is 10.

`global_user`

Sets a global limit of users. Default is -1 (unlimited).

`global_org`

Sets a global limit on the number of organizations that can be created. Default is -1 (unlimited).

`global_dashboard`

Sets a global limit on the number of dashboards that can be created. Default is -1 (unlimited).

`global_api_key`

Sets global limit of API keys that can be entered. Default is -1 (unlimited).

`global_session`

Sets a global limit on number of users that can be logged in at one time. Default is -1 (unlimited).

`global_alert_rule`

Sets a global limit on number of alert rules that can be created. Default is -1 (unlimited).

`global_correlations`

Sets a global limit on number of correlations that can be created. Default is -1 (unlimited).

`alerting_rule_evaluation_results`

Limit the number of query evaluation results per alert rule. If the condition query of an alert rule produces more results than this limit, the evaluation results in an error. Default is -1 (unlimited).

`[unified_alerting]`

For more information about the Grafana alerts, refer to Grafana Alerting.

`enabled`

Enable or disable Grafana Alerting. The default value is true.

Alerting rules migrated from dashboards and panels include a link back via the annotations.

`disabled_orgs`

Comma-separated list of organization IDs for which to disable Grafana 8 Unified Alerting.

`admin_config_poll_interval`

Specify the frequency of polling for configuration changes. The default value is 60s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), for example, 30s or 1m.

`alertmanager_config_poll_interval`

Specify the frequency of polling for Alertmanager configuration changes. The default value is 60s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), for example, 30s or 1m.

`alertmanager_max_template_output_bytes`

Maximum size in bytes that the expanded result of any single template expression (e.g. {{ .CommonAnnotations.description }}, {{ .ExternalURL }}, etc.) may reach during notification rendering. The limit is checked after template execution for each templated field, but before the value is inserted into the final notification payload sent to the receiver. If exceeded, the notification will contain output truncated up to the limit and a warning will be logged. The default value is 10,485,760 bytes (10Mb).

`ha_redis_address`

Redis server address or addresses. It can be a single Redis address if using Redis standalone, or a list of comma-separated addresses if using Redis Cluster/Sentinel.

Note
For more information on Redis, refer to Enable alerting high availability using Redis.

`ha_redis_cluster_mode_enabled`

Set to true when using Redis in Cluster mode. Mutually exclusive with ha_redis_sentinel_mode_enabled.

`ha_redis_sentinel_mode_enabled`

Set to true when using Redis in Sentinel mode. Mutually exclusive with ha_redis_cluster_mode_enabled.

`ha_redis_sentinel_master_name`

Redis Sentinel master name. Only applicable when ha_redis_sentinel_mode_enabled is set to true.

`ha_redis_username`

The username that should be used to authenticate with Redis.

`ha_redis_password`

The password that should be used to authenticate with Redis.

`ha_redis_sentinel_username`

The username that should be used to authenticate with Redis Sentinel. Only applicable when ha_redis_sentinel_mode_enabled is set to true.

`ha_redis_sentinel_password`

The password that should be used to authenticate with Redis Sentinel. Only applicable when ha_redis_sentinel_mode_enabled is set to true.

`ha_redis_db`

The Redis database. The default value is 0.

`ha_redis_prefix`

A prefix that is used for every key or channel that is created on the Redis server as part of HA for alerting. Useful if you plan to share Redis with multiple Grafana instances.

`ha_redis_peer_name`

The name of the cluster peer to use as an identifier. If none is provided, a random one is generated.

`ha_redis_max_conns`

The maximum number of simultaneous Redis connections.

`ha_redis_tls_enabled`

Enable TLS on the client used to communicate with the Redis server. This should be set to true if using any of the other ha_redis_tls_* fields.

`ha_redis_tls_cert_path`

Path to the PEM-encoded TLS client certificate file used to authenticate with the Redis server. Required if using Mutual TLS.

`ha_redis_tls_key_path`

Path to the PEM-encoded TLS private key file. Also requires the client certificate to be configured. Required if using Mutual TLS.

`ha_redis_tls_ca_path`

Path to the PEM-encoded CA certificates file. If not set, the host’s root CA certificates are used.

`ha_redis_tls_server_name`

Overrides the expected name of the Redis server certificate.

`ha_redis_tls_insecure_skip_verify`

Skips validating the Redis server certificate.

`ha_redis_tls_cipher_suites`

Overrides the default TLS cipher suite list.

`ha_redis_tls_min_version`

Overrides the default minimum TLS version. Allowed values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13

`ha_listen_address`

Listen IP address and port to receive unified alerting messages for other Grafana instances. The port is used for both TCP and UDP. It is assumed other Grafana instances are also running on the same port. The default value is 0.0.0.0:9094.

`ha_advertise_address`

Explicit IP address and port to advertise other Grafana instances. The port is used for both TCP and UDP.

`ha_peers`

Comma-separated list of initial instances (in a format of <HOST>:<PORT>) that form the HA cluster. Configuring this setting enables the High Availability mode for alerting.

`ha_peer_timeout`

Time to wait for an instance to send a notification via the Alertmanager. In HA, each Grafana instance is assigned a position (for example, 0, 1). We then multiply this position with the timeout to indicate how long should each instance wait before sending the notification to take into account replication lag. The default value is 15s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), for example, 30s or 1m.

`ha_label`

The label is an optional string to include on each packet and stream. It uniquely identifies the cluster and prevents cross-communication issues when sending gossip messages in an environment with multiple clusters.

`ha_gossip_interval`

The interval between sending gossip messages. By lowering this value (more frequent) gossip messages are propagated across cluster more quickly at the expense of increased bandwidth usage. The default value is 200ms.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), for example, 30s or 1m.

`ha_reconnect_timeout`

Length of time to attempt to reconnect to a lost peer. When running Grafana in a Kubernetes cluster, set this duration to less than 15m.

The string is a possibly signed sequence of decimal numbers followed by a unit suffix (ms, s, m, h, d), such as 30s or 1m.

`ha_push_pull_interval`

The interval between gossip full state syncs. Setting this interval lower (more frequent) increases convergence speeds across larger clusters at the expense of increased bandwidth usage. The default value is 60s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), for example, 30s or 1m.

`execute_alerts`

Enable or disable alerting rule execution. The default value is true. The alerting UI remains visible.

`evaluation_timeout`

Sets the alert evaluation timeout when fetching data from the data source. The default value is 30s.

The timeout string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), for example, 30s or 1m.

`max_attempts`

The maximum number of times Grafana retries evaluating an alert rule before giving up on that evaluation. Default is 3.

The retry mechanism:

Adds jitter to retry delays to prevent thundering herd problems when multiple rules fail simultaneously.
Stops when either max_attempts is reached or the rule’s evaluation interval is exceeded.

You can customize retry behaviour with initial_retry_delay, max_retry_delay, and randomization_factor.

`initial_retry_delay`

The initial delay before retrying a failed alert evaluation. Default is 1s.

This value is the starting point for exponential backoff.

`initialization_timeout`

Allows the context deadline for the AlertNG service to be configurable. The default timeout is 30s.

`max_retry_delay`

The maximum delay between retries during exponential backoff. Default is 4s.

After the retry delay reaches max_retry_delay, all subsequent retries use this delay.

To avoid overlapping retries with scheduled evaluations, max_retry_delay must be less than the rule’s evaluation interval.

`randomization_factor`

The randomization factor for exponential backoff retries. Default is 0.1.

The value must be between 0 and 1.

The actual retry delay is chosen randomly between:

[current_delay*(1-randomization_factor), current_delay*(1+randomization_factor)]

`min_interval`

Sets the minimum interval to enforce between rule evaluations. The default value is 10s which equals the scheduler interval. Rules are adjusted if they are less than this value or if they are not multiple of the scheduler interval (10s). Higher values can help with resource management as Grafana schedules fewer evaluations over time.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), for example, 30s or 1m.

Note
This setting has precedence over each individual rule frequency. If a rule frequency is lower than this value, then this value is enforced.

`rule_version_record_limit`

Defines the limits for how many alert rule versions are stored in the database per alert rule.

The default 0 value means there’s no limit.

`[unified_alerting.screenshots]`

For more information about screenshots, refer to Images in notifications.

`capture`

Enable screenshots in notifications. This option requires a remote HTTP image rendering service. For more information, refer to [rendering].

`capture_timeout`

The timeout for capturing screenshots. If a screenshot cannot be captured within the timeout then the notification is sent without a screenshot. The maximum duration is 30 seconds. This timeout should be less than the minimum Interval of all Evaluation Groups to avoid back pressure on alert rule evaluation.

`max_concurrent_screenshots`

The maximum number of screenshots that can be taken at the same time. This option is different from concurrent_render_request_limit as max_concurrent_screenshots sets the number of concurrent screenshots that can be taken at the same time for all firing alerts where as concurrent_render_request_limit sets the total number of concurrent screenshots across all Grafana services.

`upload_external_image_storage`

Uploads screenshots to the local Grafana server or remote storage such as Azure, S3 and GCS. For more information, refer to [external_image_storage]. If this option is false then screenshots are persisted to disk for up to temp_data_lifetime.

`[unified_alerting.reserved_labels]`

For more information about Grafana Reserved Labels, refer to Labels in Grafana Alerting

`disabled_labels`

Comma-separated list of reserved labels added by the Grafana Alerting engine that should be disabled.

For example: disabled_labels=grafana_folder

`[unified_alerting.state_history]`

This section configures where Grafana Alerting writes alert state history. Refer to Configure alert state history for end-to-end setup and examples.

`enabled`

Enables recording alert state history. Default is false.

`backend`

Select the backend used to store alert state history. Supported values: loki, prometheus, multiple.

`loki_remote_url`

The URL of the Loki server used when backend = loki (or when backend = multiple and Loki is a primary/secondary).

`prometheus_target_datasource_uid`

Target Prometheus data source UID used for writing alert state changes when backend = prometheus (or when backend = multiple and Prometheus is a secondary).

`prometheus_metric_name`

Optional. Metric name for the alert state metric. Default is GRAFANA_ALERTS.

`prometheus_write_timeout`

Optional. Timeout for writing alert state data to the target data source. Default is 10s.

`primary`

Used only when backend = multiple. Selects the primary backend (for example loki).

`secondaries`

Used only when backend = multiple. Comma-separated list of secondary backends (for example prometheus).

`[unified_alerting.state_history.annotations]`

This section controls retention of annotations automatically created while evaluating alert rules when alerting state history backend is configured to be annotations (see setting [unified_alerting.state_history].backend)

`max_age`

Configures for how long alert annotations are stored. Default is 0, which keeps them forever. This setting should be expressed as an duration. Ex 6h (hours), 10d (days), 2w (weeks), 1M (month).

`max_annotations_to_keep`

Configures max number of alert annotations that Grafana stores. Default value is 0, which keeps all alert annotations.

`[unified_alerting.prometheus_conversion]`

This section applies only to rules imported as Grafana-managed rules. For more information about the import process, refer to Import data source-managed rules to Grafana-managed rules.

`rule_query_offset`

Set the query offset to imported Grafana-managed rules when query_offset is not defined in the original rule group configuration. The default value is 1m.

`default_datasource_uid`

Set the default data source UID to use for query execution when importing Prometheus rules. Grafana uses this default when the X-Grafana-Alerting-Datasource-UID header isn’t provided during import. If this option isn’t set, the header becomes required. The default value is empty.

`[annotations]`

`cleanupjob_batchsize`

Configures the batch size for the annotation clean-up job. This setting is used for dashboard, API, and alert annotations.

`tags_length`

Enforces the maximum allowed amount of tags for any newly introduced annotations. This value can be between 500 and 4096 (inclusive). The default value is 500. Setting it to a higher value would impact performance and is therefore not recommended.

`[annotations.dashboard]`

Dashboard annotations means that annotations are associated with the dashboard they are created on.

`max_age`

Configures how long dashboard annotations are stored. Default is 0, which keeps them forever. This setting should be expressed as a duration. Examples: 6h (hours), 10d (days), 2w (weeks), 1M (month).

`max_annotations_to_keep`

Configures max number of dashboard annotations that Grafana stores. Default value is 0, which keeps all dashboard annotations.

`[annotations.api]`

API annotations means that the annotations have been created using the API without any association with a dashboard.

`max_age`

Configures how long Grafana stores API annotations. Default is 0, which keeps them forever. This setting should be expressed as a duration. Examples: 6h (hours), 10d (days), 2w (weeks), 1M (month).

`max_annotations_to_keep`

Configures max number of API annotations that Grafana keeps. Default value is 0, which keeps all API annotations.

`[explore]`

For more information about this feature, refer to Explore.

`enabled`

Enable or disable the Explore section. Default is enabled.

`defaultTimeOffset`

Set a default time offset from now on the time picker. Default is 1 hour. This setting should be expressed as a duration. Examples: 1h (hour), 1d (day), 1w (week), 1M (month).

`hide_logs_download`

Show or hide the button to download logs in Explore. Default is false, so that the button will be visible.

`[help]`

Configures the help section.

`enabled`

Enable or disable the Help section. Default is enabled.

`[profile]`

Configures the Profile section.

`enabled`

Enable or disable the Profile section. Default is enabled.

`[news]`

`news_feed_enabled`

Enables the news feed section. Default is true

`[query]`

`concurrent_query_limit`

Set the number of queries that can be executed concurrently in a mixed data source panel. Default is the number of CPUs.

`[query_history]`

Configures Query history in Explore.

`enabled`

Enable or disable the Query history. Default is enabled.

`[short_links]`

Configures settings around the short link feature.

`expire_time`

Short links that are never accessed are considered expired or stale and can be deleted as cleanup. Set the expiration time in days. The default is -1 days (never expire). The maximum is 365 days.

A setting above the maximum uses the value 365 instead. A negative value such as -1 disables expiry.

`[metrics]`

For detailed instructions, refer to Internal Grafana metrics.

`enabled`

Enable metrics reporting. defaults true. Available via HTTP API <URL>/metrics.

`interval_seconds`

Flush/write interval when sending metrics to external TSDB. Defaults to 10.

`disable_total_stats`

If set to true, then total stats generation (stat_totals_* metrics) is disabled. Default is false.

`total_stats_collector_interval_seconds`

Sets the total stats collector interval. The default is 1800 seconds (30 minutes).

`basic_auth_username and basic_auth_password`

If both are set, then basic authentication is required to access the metrics endpoint.

`[metrics.environment_info]`

Adds dimensions to the grafana_environment_info metric, which can expose more information about the Grafana instance.

; exampleLabel1 = exampleValue1
; exampleLabel2 = exampleValue2

`[metrics.graphite]`

Use these options if you want to send internal Grafana metrics to Graphite.

`address`

Enable by setting the address. Format is <Hostname or ip>:port.

`prefix`

Graphite metric prefix. Defaults to prod.grafana.%(instance_name)s.

`[grafana_net]`

Refer to [grafana_com] configuration as that’s the preferred configuration name. The [grafana_net] configuration is still accepted and parsed as [grafana_com] configuration.

`[grafana_com]`

`url`

Default is https://grafana.com. The default authentication identity provider for Grafana Cloud.

`[tracing.jaeger]`

[Deprecated - use tracing.opentelemetry.jaeger or tracing.opentelemetry.otlp instead]

Configure a Jaeger client in Grafana for distributed tracing.

You can also use the standard JAEGER_* environment variables to configure Jaeger. For the full list, refer to the table in Trace configuration via environment variables. Environment variables override any settings provided here.

`address`

The host:port destination for reporting spans. (ex: localhost:6831)

Can be set with the environment variables JAEGER_AGENT_HOST and JAEGER_AGENT_PORT.

`always_included_tag`

Comma-separated list of tags to include in all new spans, such as tag1:value1,tag2:value2.

Can be set with the environment variable JAEGER_TAGS (use = instead of : with the environment variable).

`sampler_type`

Default value is const.

Specifies the type of sampler: const, probabilistic, ratelimiting, or remote.

Refer to https://www.jaegertracing.io/docs/1.16/sampling/#client-sampling-configuration for details on the different tracing types.

Can be set with the environment variable JAEGER_SAMPLER_TYPE.

To override this setting, enter sampler_type in the tracing.opentelemetry section.

`sampler_param`

Default value is 1.

This is the sampler configuration parameter. Depending on the value of sampler_type, it can be 0, 1, or a decimal value in between.

For const sampler, 0 or 1 for always false/true respectively
For probabilistic sampler, a probability between 0 and 1.0
For rateLimiting sampler, the number of spans per second
For remote sampler, the argument is the same as for probabilistic and indicates the initial sampling rate before the actual ones received from the remote.

May be set with the environment variable JAEGER_SAMPLER_PARAM.

Setting sampler_param in the tracing.opentelemetry section overrides this setting.

`sampling_server_url`

sampling_server_url is the URL of a sampling manager providing a sampling strategy.

Setting sampling_server_url in the tracing.opentelemetry section overrides this setting.

`zipkin_propagation`

Default value is false.

Controls whether or not to use the Zipkin span propagation format (with x-b3- HTTP headers). By default, the Jaeger format is used.

Can be set with the environment variable and value JAEGER_PROPAGATION=b3.

`disable_shared_zipkin_spans`

Default value is false.

Setting this to true turns off shared RPC spans. Leaving this available is the most common setting when using Zipkin elsewhere in your infrastructure.

`[tracing.opentelemetry]`

Configure general parameters shared between OpenTelemetry providers.

`custom_attributes`

Comma-separated list of attributes to include in all new spans, such as key1:value1,key2:value2.

Can be set or overridden with the environment variable OTEL_RESOURCE_ATTRIBUTES (use = instead of : with the environment variable). The service name can be set or overridden using attributes or with the environment variable OTEL_SERVICE_NAME.

`sampler_type`

Default value is const.

Specifies the type of sampler: const, probabilistic, ratelimiting, or remote.

`sampler_param`

Default value is 1.

Depending on the value of sampler_type, the sampler configuration parameter can be 0, 1, or any decimal value between 0 and 1.

For the const sampler, use 0 to never sample or 1 to always sample
For the probabilistic sampler, you can use a decimal value between 0.0 and 1.0
For the rateLimiting sampler, enter the number of spans per second
For the remote sampler, use a decimal value between 0.0 and 1.0 to specify the initial sampling rate used before the first update is received from the sampling server

`sampling_server_url`

When sampler_type is remote, this specifies the URL of the sampling server. This can be used by all tracing providers.

Use a sampling server that supports the Jaeger remote sampling API, such as jaeger-agent, jaeger-collector, opentelemetry-collector-contrib, or Grafana Alloy.

`[tracing.opentelemetry.jaeger]`

Configure Grafana with a Jaeger client for distributed tracing.

`address`

The <HOST>:<PORT> destination for reporting spans. For example, localhost:14268/api/traces.

`propagation`

The propagation specifies the text map propagation format. The values jaeger and w3c are supported. Add a comma (,) between values to specify multiple formats (for example, "jaeger,w3c"). The default value is w3c.

`[tracing.opentelemetry.otlp]`

Configure Grafana with an OTLP client for distributed tracing.

`address`

The <HOST>:<PORT> destination for reporting spans. For example, localhost:4317.

`propagation`

`insecure`

Toggles the insecure communication setting, defaults to true. When set to false, the OTLP client will use TLS credentials with the default system cert pool for communication.

`[external_image_storage]`

These options control how images should be made public so they can be shared on services like Slack or email message.

`provider`

Options are s3, webdav, gcs, azure_blob, local). If left empty, then Grafana ignores the upload action.

`[external_image_storage.s3]`

`endpoint`

Optional endpoint URL (hostname or fully qualified URI) to override the default generated S3 endpoint. If you want to keep the default, just leave this empty. You must still provide a region value if you specify an endpoint.

`path_style_access`

Set this to true to force path-style addressing in S3 requests, which uses http://s3.amazonaws.com/<BUCKET>/<KEY>, instead of the default, which is virtual hosted bucket addressing when possible (http://<BUCKET>.s3.amazonaws.com/<KEY>).

Note
This option is specific to the Amazon S3 service.

`bucket_url`

(for backward compatibility, only works when no bucket or region are configured) Bucket URL for S3. AWS region can be specified within URL or defaults to ‘us-east-1’, for example,

`bucket`

Bucket name for S3. For example, grafana.snapshot.

`region`

Region name for S3. For example, us-east-1 or `cn-north-1.

`path`

Optional extra path inside bucket, useful to apply expiration policies.

`access_key`

Access key, for example, AAAAAAAAAAAAAAAAAAAA.

Access key requires permissions to the S3 bucket for the ‘s3:PutObject’ and ‘s3:PutObjectAcl’ actions.

`secret_key`

Secret key, for example, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.

`[external_image_storage.webdav]`

`url`

URL where Grafana sends PUT request with images.

`username`

Basic auth username.

`password`

Basic auth password.

`public_url`

Optional URL to send to users in notifications. If the string contains the sequence {{file}}, it is replaced with the uploaded filename. Otherwise, the filename is appended to the path part of the URL, leaving any query string unchanged.

`[external_image_storage.gcs]`

`key_file`

Optional path to JSON key file associated with a Google service account to authenticate and authorize. If no value is provided it tries to use the application default credentials. Service Account keys can be created and downloaded from https://console.developers.google.com/permissions/serviceaccounts.

Service Account should have “Storage Object Writer” role. The access control model of the bucket needs to be “Set object-level and bucket-level permissions”. Grafana makes the images public readable when signed URLs aren’t enabled.

`bucket`

Bucket Name on Google Cloud Storage.

`path`

Optional extra path inside bucket.

`enable_signed_urls`

If set to true, Grafana creates a signed URL for the image uploaded to Google Cloud Storage.

`signed_url_expiration`

Sets the signed URL expiration, which defaults to seven days.

`[external_image_storage.azure_blob]`

`account_name`

Storage account name.

`account_key`

Storage account key

`container_name`

Container name where to store “Blob” images with random names. Creating the blob container beforehand is required. Only public containers are supported.

`sas_token_expiration_days`

Number of days for SAS token validity. If specified, a SAS token is attached to image URL. Allow storing images in private containers.

`[external_image_storage.local]`

This option does not require any configuration.

`[rendering]`

Options to configure a remote HTTP image rendering service, for example, using https://github.com/grafana/grafana-image-renderer.

`renderer_token`

An authentication token is be sent to and verified by the renderer. The renderer denies any request without an authentication token matching the one configured on the renderer.

`server_url`

URL to a remote HTTP image renderer service, for example, http://localhost:8081/render, that Grafana can use to render panels and dashboards to PNG-images using HTTP requests to an external service.

`callback_url`

If the remote HTTP image renderer service runs on a different server than the Grafana server you may have to configure this to a URL where Grafana is reachable, for example, http://grafana.domain/.

The callback_url can also be configured to support usage of the image renderer running as a plugin with support for SSL / HTTPS. For example https://localhost:3000/.

`concurrent_render_request_limit`

Concurrent render request limit affects when the /render HTTP endpoint is used. Rendering many images at the same time can overload the server, which this setting can help protect against by only allowing a certain number of concurrent requests. Default is 30.

`ca_cert_file_path`

Path to the PEM-encoded CA certificate file from the Image Renderer server.

`default_image_width`

Configures the width of the rendered image. The default width is 1000.

`default_image_height`

Configures the height of the rendered image. The default height is 500.

`default_image_scale`

Configures the scale of the rendered image. The default scale is 1.

`[panels]`

`enable_alpha`

Set to true if you want to test alpha panels that are not yet ready for general usage. Default is false.

`disable_sanitize_html`

Note
This configuration is not available in Grafana Cloud instances.

If set to true Grafana allows script tags in text panels. Not recommended as it enables XSS vulnerabilities. Default is false.

`[plugins]`

`enable_alpha`

Set to true if you want to test alpha plugins that are not yet ready for general usage. Default is false.

`allow_loading_unsigned_plugins`

Enter a comma-separated list of plugin identifiers to identify plugins to load even if they are unsigned. Plugins with modified signatures are never loaded.

We do not recommend using this option. For more information, refer to Plugin signatures.

`plugin_admin_enabled`

Available to Grafana administrators only, enables installing, uninstalling, and updating plugins directly from the Grafana UI. Set to true by default. Setting it to false hides the controls.

For more information, refer to Plugin catalog.

`plugin_admin_external_manage_enabled`

Set to true if you want to enable external management of plugins. Default is false. This is only applicable to Grafana Cloud users.

`plugin_catalog_url`

Custom install/learn more URL for enterprise plugins. Defaults to https://grafana.com/grafana/plugins/.

`plugin_catalog_hidden_plugins`

Enter a comma-separated list of plugin identifiers to hide in the plugin catalog.

`public_key_retrieval_disabled`

Disable download of the public key for verifying plugin signature. The default is false. If disabled, it uses the hard-coded public key.

`public_key_retrieval_on_startup`

Force download of the public key for verifying plugin signature on startup. The default is false. If disabled, the public key is retrieved every 10 days. Requires public_key_retrieval_disabled to be false to have any effect.

`disable_plugins`

Enter a comma-separated list of plugin identifiers to avoid loading (including core plugins). These plugins are hidden in the catalog.

`preinstall`

Enter a comma-separated list of plugin identifiers to install on startup, using the Grafana catalog as the source. Preinstalled plugins cannot be uninstalled from the Grafana user interface; they need to be removed from this list first.

Plugins are installed asynchronously, as a background process. This means that Grafana starts up faster, but the plugins may not be available immediately.

To pin plugins to a specific version, use the format plugin_id@version, for example,grafana-piechart-panel@1.6.0. If no version is specified, the latest version is installed. The plugin is automatically updated to the latest version when a new version is available in the Grafana plugin catalog on startup (except for new major versions).

To use a custom URL to download a plugin, use the format plugin_id@version@url, for example, grafana-piechart-panel@1.6.0@https://example.com/grafana-piechart-panel-1.6.0.zip.

By default, Grafana installs some suggested plugins on startup. For a list of default preinstalled plugins, refer to pkg/setting/setting_plugins.go:35.

`preinstall_sync`

Enter a comma-separated list of plugin identifiers to install on startup, using the Grafana catalog as the source. Same as preinstall, but installs plugins synchronously.

These will be installed before starting Grafana. Useful when used with provisioning.

`preinstall_disabled`

This option disables all preinstalled plugins. The default is false. To disable a specific plugin from being preinstalled, use the disable_plugins option.

`preinstall_auto_update`

Enable automatic updates for preinstalled plugins on start-up. When enabled, preinstalled plugins without a pinned version are automatically updated to the latest version when Grafana starts.

The default is true.

To prevent automatic updates for specific plugins, pin them to a specific version using the format plugin_id@version in the preinstall setting.

`[live]`

`max_connections`

The max_connections option specifies the maximum number of connections to the Grafana Live WebSocket endpoint per Grafana server instance. Default is 100.

Refer to Grafana Live configuration documentation if you specify a number higher than default since this can require some operating system and infrastructure tuning.

0 disables Grafana Live, -1 means unlimited connections.

`allowed_origins`

The allowed_origins option is a comma-separated list of additional origins (Origin header of HTTP Upgrade request during WebSocket connection establishment) that is accepted by Grafana Live.

If not set (default), then the origin is matched over root_url which should be sufficient for most scenarios.

Origin patterns support wildcard symbol “*”.

For example:

[live]
allowed_origins = "https://*.example.com"

`ha_engine`

Experimental

The high availability (HA) engine name for Grafana Live. By default, it’s not set. The only possible value is redis.

For more information, refer to the Configure Grafana Live HA setup.

`ha_engine_address`

Experimental

Address string of selected the high availability (HA) Live engine. For Redis, it’s a host:port string. Example:

[live]
ha_engine = redis
ha_engine_address: redis-headless.grafana.svc.cluster.local:6379
ha_engine_password: $__file{/your/redis/password/secret/mount}

`[plugin.plugin_id]`

This section can be used to configure plugin-specific settings. Replace the plugin_id attribute with the plugin ID present in plugin.json.

Properties described in this section are available for all plugins, but you must set them individually for each plugin.

`tracing`

Note
OpenTelemetry must be configured as well.

If true, propagate the tracing context to the plugin backend and enable tracing (if the backend supports it).

`as_external`

Load an external version of a core plugin if it has been installed.

`[plugin.grafana-image-renderer]`

For more information, refer to Image rendering.

`rendering_timezone`

Instruct headless browser instance to use a default timezone when not provided by Grafana, for example, when rendering panel image of alert. Refer to the ICU metaZones.txt file for a list of supported timezone IDs. Fallbacks to TZ environment variable if not set.

`rendering_language`

Instruct headless browser instance to use a default language when not provided by Grafana, for example, when rendering panel image of alert. Refer to the HTTP header Accept-Language to understand how to format this value, for example, ‘fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5’.

`rendering_viewport_device_scale_factor`

Instruct headless browser instance to use a default device scale factor when not provided by Grafana, for example, when rendering panel image of alert. Default is 1. Using a higher value produces more detailed images (higher DPI), but requires more disk space to store an image.

`rendering_ignore_https_errors`

Instruct headless browser instance whether to ignore HTTPS errors during navigation. Per default HTTPS errors are not ignored. Due to the security risk, we do not recommend that you ignore HTTPS errors.

`rendering_verbose_logging`

Instruct headless browser instance whether to capture and log verbose information when rendering an image. Default is false and only captures and log error messages.

When enabled, debug messages are captured and logged as well.

For the verbose information to be included in the Grafana server log you have to adjust the rendering log level to debug, configure [log].filter = rendering:debug.

`rendering_dumpio`

Instruct headless browser instance whether to output its debug and error messages into running process of remote rendering service. Default is false.

It can be useful to set this to true when troubleshooting.

`rendering_timing_metrics`

Note
Available from grafana-image-renderer v3.9.0+

Instruct a headless browser instance on whether to record metrics for the duration of every rendering step. Default is false.

Setting this to true when optimizing the rendering mode settings to improve the plugin performance or when troubleshooting can be useful.

`rendering_args`

Additional arguments to pass to the headless browser instance. Defaults are --no-sandbox,--disable-gpu. The list of Chromium flags can be found at (https://peter.sh/experiments/chromium-command-line-switches/). Separate multiple arguments with commas.

`rendering_chrome_bin`

You can configure the plugin to use a different browser binary instead of the pre-packaged version of Chromium.

Note that this is not recommended. You might encounter problems if the installed version of Chrome or Chromium is not compatible with the plugin.

`rendering_mode`

Instruct how headless browser instances are created. Default is default and creates a new browser instance on each request.

Mode clustered makes sure that only a maximum of browsers or incognito pages can execute concurrently.

Mode reusable uses one browser instance and creates a new incognito page on each request.

`rendering_clustering_mode`

When rendering_mode = clustered, you can instruct how many browsers or incognito pages can execute concurrently. Default is browser and clusters using browser instances.

Mode context clusters using incognito pages.

`rendering_clustering_max_concurrency`

When rendering_mode = clustered, you can define the maximum number of browser instances or incognito pages that can execute concurrently. Default is 5.

`rendering_clustering_timeout`

Note
Available in grafana-image-renderer v3.3.0 and later versions.

When rendering_mode = clustered, you can specify the duration a rendering request can take before it times out. Default is 30 seconds.

`rendering_viewport_max_width`

Limit the maximum viewport width that can be requested.

`rendering_viewport_max_height`

Limit the maximum viewport height that can be requested.

`rendering_viewport_max_device_scale_factor`

Limit the maximum viewport device scale factor that can be requested.

`grpc_host`

Change the listening host of the gRPC server. Default host is 127.0.0.1.

`grpc_port`

Change the listening port of the gRPC server. Default port is 0 and uses a port not in use.

`[enterprise]`

For more information about Grafana Enterprise, refer to Grafana Enterprise.

`[feature_toggles]`

`enable`

Keys of features to enable, separated by space.

`FEATURE_NAME = <value>`

Use a key-value pair to set feature flag values explicitly, overriding any default values. A few different types are supported, following the OpenFeature specification. See the defaults.ini file for more details.

For example, to disable an on-by-default feature toggle named exploreMixedDatasource, specify exploreMixedDatasource = false.

`[date_formats]`

This section controls system-wide defaults for date formats used in time ranges, graphs, and date input boxes.

The format patterns use Moment.js formatting tokens.

`full_date`

Full date format used by time range picker and in other places where a full date is rendered.

`intervals`

These intervals formats are used in the graph to show only a partial date or time. For example, if there are only minutes between Y-axis tick labels then the interval_minute format is used.

Defaults

interval_second = HH:mm:ss
interval_minute = HH:mm
interval_hour = MM/DD HH:mm
interval_day = MM/DD
interval_month = YYYY-MM
interval_year = YYYY

`use_browser_locale`

Set this to true to have date formats automatically derived from your browser location. Defaults to false. This is an experimental feature.

`default_timezone`

Used as the default time zone for user preferences. Can be either browser for the browser local time zone or a time zone name from the IANA Time Zone database, such as UTC or Europe/Amsterdam.

`default_week_start`

Set the default start of the week, valid values are: saturday, sunday, monday or browser to use the browser locale to define the first day of the week. Default is browser.

`[time_picker]`

This section controls system-wide defaults for the time picker, such as the default quick ranges.

`quick_ranges`

Set the default set of quick relative offset time ranges that show up in the right column of the time picker. Each configuration entry must have a from, to, and display field. Any configuration for this field must be in valid JSON format made up of a list of quick range configurations.

The from and to fields should be valid relative time ranges. For more information the relative time formats, refer to Time units and relative ranges.. The from field is required, but omitting to will result in the from value being used in both fields.

If no configuration is provided, the default time ranges will be used.

For example:

[time_picker]
quick_ranges = """[
{"from":"now-6s","to":"now","display":"Last 6 seconds"},
{"from":"now-10m","to":"now","display":"Last 10 minutes"},
{"from":"now-25h","to":"now","display":"Last 24 hours"},
{"from":"now/w","to":"now/w","display":"This week"},
{"from":"now-1w/w","to":"now-1w/w","display":"Last week"},
{"from":"now-10d","to":"now","display":"Last 10 days"}
]"""

`[expressions]`

`enabled`

Set this to false to disable expressions and hide them in the Grafana UI. Default is true.

`sql_expression_cell_limit`

Set the maximum number of cells that can be passed to a SQL expression. Default is 100000. A setting of 0 means no limit.

`sql_expression_output_cell_limit`

Set the maximum number of cells that can be returned from a SQL expression. Default is 100000. A setting of 0 means no limit.

`sql_expression_query_length_limit`

Set the maximum length of a SQL query that can be used in a SQL expression. Default is 10000 characters. A setting of 0 means no limit.

`sql_expression_timeout`

The duration a SQL expression will run before being cancelled. The default is 10s. A setting of 0s means no limit.

`[geomap]`

This section controls the defaults settings for Geomap Plugin.

`default_baselayer_config`

The JSON configuration used to define the default base map. Four base map options to choose from are carto, esriXYZTiles, xyzTiles, standard. For example, to set cartoDB light as the default base layer:

default_baselayer_config = `{
  "type": "xyz",
  "config": {
    "attribution": "Open street map",
    "url": "https://tile.openstreetmap.org/{z}/{x}/{y}.png"
  }
}`

`enable_custom_baselayers`

Set this to false to disable loading other custom base maps and hide them in the Grafana UI. Default is true.

`[rbac]`

Refer to Role-based access control for more information.

`[navigation.app_sections]`

Move an app plugin (referenced by its id), including all its pages, to a specific navigation section. Format: <pluginId> = <sectionId> <sortWeight>

`[navigation.app_standalone_pages]`

Move an individual app plugin page (referenced by its path field) to a specific navigation section. Format: <pageUrl> = <sectionId> <sortWeight>

`[public_dashboards]`

This section configures the shared dashboards feature.

`enabled`

Set this to false to disable the shared dashboards feature. This prevents users from creating new shared dashboards and disables existing ones.

Start the Grafana server

Fri, 03 Apr 2026 19:43:06 +0000

Start the Grafana server

This topic includes instructions for starting the Grafana server. For certain configuration changes, you might have to restart the Grafana server for them to take effect.

The following instructions start the grafana-server process as the grafana user, which was created during the package installation.

If you installed with the APT repository or .deb package, then you can start the server using systemd or init.d. If you installed a binary .tar.gz file, then you execute the binary.

Linux

The following subsections describe three methods of starting and restarting the Grafana server: with systemd, initd, or by directly running the binary. You should follow only one set of instructions, depending on how your machine is configured.

Start the Grafana server with systemd

Complete the following steps to start the Grafana server using systemd and verify that it is running.

To start the service, run the following commands:

sudo systemctl daemon-reload
sudo systemctl start grafana-server

To verify that the service is running, run the following command:
Bash
```
sudo systemctl status grafana-server
```

Configure the Grafana server to start at boot using systemd

To configure the Grafana server to start at boot, run the following command:

sudo systemctl enable grafana-server.service

Serve Grafana on a port < 1024

If you are using systemd and want to start Grafana on a port that is lower than 1024, you must add a systemd unit override.

Run the following command to create an override file in your configured editor.

# Alternatively, create a file in /etc/systemd/system/grafana-server.service.d/override.conf
sudo systemctl edit grafana-server.service

Add the following additional settings to grant the CAP_NET_BIND_SERVICE capability.

To learn more about capabilities, refer to capabilities(7) — Linux manual page.

[Service]
# Give the CAP_NET_BIND_SERVICE capability
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# A private user cannot have process capabilities on the host's user
# namespace and thus CAP_NET_BIND_SERVICE has no effect.
PrivateUsers=false

Restart the Grafana server using systemd

To restart the Grafana server, run the following command:

sudo systemctl restart grafana-server

Note
SUSE or openSUSE users might need to start the server with the systemd method, then use the init.d method to configure Grafana to start at boot.

Start the Grafana server using init.d

Complete the following steps to start the Grafana server using init.d and verify that it is running:

To start the Grafana server, run the following command:
Bash
```
sudo service grafana-server start
```
To verify that the service is running, run the following command:
Bash
```
sudo service grafana-server status
```

Configure the Grafana server to start at boot using init.d

To configure the Grafana server to start at boot, run the following command:

sudo update-rc.d grafana-server defaults

Restart the Grafana server using init.d

To restart the Grafana server, run the following command:

sudo service grafana-server restart

Start the server using the binary

The grafana binary .tar.gz needs the working directory to be the root install directory where the binary and the public folder are located.

To start the Grafana server, run the following command:

./bin/grafana server

Docker

To restart the Grafana service, use the docker restart command.

docker restart grafana

Alternatively, you can use the docker compose restart command to restart Grafana. For more information, refer to docker compose documentation.

Docker compose example

Configure your docker-compose.yml file. For example:

version: '3.8'
services:
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    environment:
      - TERM=linux
      - GF_PLUGINS_PREINSTALL=grafana-clock-panel,grafana-polystat-panel
    ports:
      - '3000:3000'
    volumes:
      - 'grafana_storage:/var/lib/grafana'
volumes:
  grafana_storage: {}

Start the Grafana server:

docker compose up -d

This starts the Grafana server container in detached mode along with the two plugins specified in the YAML file.

To restart the running container, use this command:

docker compose restart grafana

Windows

Complete the following steps to start the Grafana server on Windows:

Execute grafana.exe server; the grafana binary is located in the bin directory.

We recommend that you run grafana.exe server from the command line.

If you want to run Grafana as a Windows service, you can download NSSM.
To run Grafana, open your browser and go to the Grafana port (http://localhost:3000/ is default).

Note: The default Grafana port is 3000. This port might require extra permissions on Windows. If it does not appear in the default port, you can try changing to a different port.
To change the port, complete the following steps:

a. In the conf directory, copy sample.ini to custom.ini.

Note: You should edit custom.ini, never defaults.ini.

b. Edit custom.ini and uncomment the http_port configuration option (; is the comment character in ini files) and change it to something similar to 8080, which should not require extra Windows privileges.

To restart the Grafana server, complete the following steps:

Open the Services app.
Right-click on the Grafana service.
In the context menu, click Restart.

macOS

Restart methods differ depending on whether you installed Grafana using Homebrew or as standalone macOS binaries.

Start Grafana using Homebrew

To start Grafana using Homebrew, run the following start command:

brew services start grafana

Restart Grafana using Homebrew

Use the Homebrew restart command:

brew services restart grafana

Restart standalone macOS binaries

To restart Grafana:

Open a terminal and go to the directory where you copied the install setup files.
Run the command:

./bin/grafana server

Next steps

After the Grafana server is up and running, consider taking the next steps:

Refer to Get Started to learn how to build your first dashboard.
Refer to Configuration to learn about how you can customize your environment.

Sign in to Grafana

Fri, 03 Apr 2026 19:43:06 +0000

This topic describes how to sign in to Grafana.

Before you begin

Install Grafana

Steps

To sign in to Grafana for the first time, follow these steps:

Open your web browser and go to root URL specified in Grafana configuration file.

Unless you have configured Grafana differently, it is set to use http://localhost:3000 by default.
On the signin page, enter admin for username and password.
Click Sign in.

If successful, you will see a prompt to change the password.
Click OK on the prompt and change your password.

Note: We strongly recommend that you change the default administrator password.

Configure security

Fri, 03 Apr 2026 19:43:06 +0000

Configure security

If you run non-Grafana web services on your Grafana server or within its local network, then they might be vulnerable to exploitation through the Grafana data source proxy or other methods.

To prevent this type of exploitation from happening, we recommend that you apply one or more of the precautions listed below.

Limit IP addresses/hostnames for data source URL

You can configure Grafana to only allow certain IP addresses or hostnames to be used as data source URLs and proxied through the Grafana data source proxy. Refer to data_source_proxy_whitelist for usage instructions.

Request security

The request security configuration option allows users to limit requests from the Grafana server. It targets requests that are generated by users. For more information, refer to Request security.

Note
Request security is available in Grafana Enterprise v7.4 and later versions.

Firewall rules

Configure a firewall to restrict Grafana from making network requests to sensitive internal web services.

There are many firewall tools available. Refer to the documentation for your specific security tool. For example, Linux users can use iptables.

Proxy server

You can require all network requests made by Grafana to go through a proxy server.

Self-hosted reverse proxy options include but are not limited to:

Pomerium, which has a guide for securing Grafana
NGINX using their guide on restricting access with HTTP basic authentication
OAuth2 proxy

Configure CORS

If you want to enable CORS for your Grafana instance, run Grafana behind a reverse proxy and configure the CORS headers in the reverse proxy.

For more information, refer to Run Grafana behind a reverse proxy.

Note
Grafana doesn’t recommend using wildcard values (*) as header values and recommends using a URL instead.

Limit Viewer query permissions

Users with the Viewer role can enter any possible query in any of the data sources available in the organization, not just the queries that are defined on the dashboards for which the user has Viewer permissions.

For example, in a Grafana instance with one data source, one dashboard, and one panel that has one query defined, you might assume that a Viewer can only see the result of the query defined in that panel. Actually, the Viewer has access to send any query to the data source. With a command-line tool like curl (there are many tools for this), the Viewer can make their own query to the data source and potentially access sensitive data.

To address this vulnerability, you can restrict data source query access in the following ways:

Create multiple data sources with some restrictions added in data source configuration that restrict access (like database name or credentials). Then use the Data Source Permissions Enterprise feature to restrict user access to the data source in Grafana.
Create a separate Grafana organization, and in that organization, create a separate data source. Make sure the data source has some option/user/credentials setting that limits access to a subset of the data. Not all data sources have an option to limit access.

Implications of enabling anonymous access to dashboards

When you enable anonymous access in Grafana, any visitor or user can use Grafana as a Viewer without signing in. This section lists the security implications of enabling Anonymous access.

Anyone with the URL of a dashboard accessible by the Viewer role can access that dashboard.
New dashboards are publicly available unless the dashboard creator hides them from all Viewers.
Anyone can edit or delete dashboards that have granted Edit or Admin abilities to Viewers.
Anyone can make view calls to the API and list all folders, dashboards, and data sources.
Anyone can make arbitrary queries to any data source that the Grafana instance is configured with.

Plan your IAM integration strategy

Fri, 03 Apr 2026 19:43:06 +0000

Plan your IAM integration strategy

This section describes the decisions you should make when using an Identity and Access Management (IAM) provider to manage access to Grafana. IAM ensures that users have secure access to sensitive data and other resources, simplifying user management and authentication.

Benefits of integrating with an IAM provider

Integrating with an IAM provider provides the following benefits:

User management: By providing Grafana access to your current user management system, you eliminate the overhead of replicating user information and instead have centralized user management for users’ roles and permissions to Grafana resources.
Security: Many IAM solutions provide advanced security features such as multi-factor authentication, RBAC, and audit trails, which can help to improve the security of your Grafana installation.
SSO: Properly setting up Grafana with your current IAM solution enables users to access Grafana with the same credentials they use for other applications.
Scalability: User additions and updates in your user database are immediately reflected in Grafana.

In order to plan an integration with Grafana, assess your organization’s current needs, requirements, and any existing IAM solutions being used. This includes thinking about how roles and permissions will be mapped to users in Grafana and how users can be grouped to access shared resources.

Internal vs external users

As a first step, determine how you want to manage users who will access Grafana.

Do you already use an identity provider to manage users? If so, Grafana might be able to integrate with your identity provider through one of our IdP integrations. Refer to Configure authentication documentation for the list of supported providers.

If you are not interested in setting up an external identity provider, but still want to limit access to your Grafana instance, consider using Grafana’s basic authentication.

Finally, if you want your Grafana instance to be accessible to everyone, you can enable anonymous access to Grafana. For information, refer to the anonymous authentication documentation.

Ways to organize users

Organize users in subgroups that are sensible to the organization. For example:

Security: Different groups of users or customers should only have access to their intended resources.
Simplicity: Reduce the scope of dashboards and resources available.
Cost attribution: Track and bill costs to individual customers, departments, or divisions.
Customization: Each group of users could have a personalized experience like different dashboards or theme colors.

Users in Grafana teams

You can organize users into teams and assign them roles and permissions reflecting the current organization. For example, instead of assigning five users access to the same dashboard, you can create a team of those users and assign dashboard permissions to the team.

A user can belong to multiple teams and be a member or an administrator for a given team. Team members inherit permissions from the team but cannot edit the team itself. Team administrators can add members to a team and update its settings, such as the team name, team members, roles assigned, and UI preferences.

Teams are a perfect solution for working with a subset of users. Teams can share resources with other teams.

Users in Grafana organizations

Grafana organizations allow complete isolation of resources, such as dashboards and data sources. Users can be members of one or several organizations, and they can only access resources from an organization they belong to.

Having multiple organizations in a single instance of Grafana lets you manage your users in one place while completely separating resources.

Organizations provide a higher measure of isolation within Grafana than teams do and can be helpful in certain scenarios. However, because organizations lack the scalability and flexibility of teams and folders, we do not recommend using them as the default way to group users and resources.

Note that Grafana Cloud does not support having more than 1 organizations per instance.

Choosing between teams and organizations

Grafana teams and Grafana organizations serve similar purposes in the Grafana platform. Both are designed to help group users and manage and control access to resources.

Teams provide more flexibility, as resources can be accessible by multiple teams, and team creation and management are simple.

In contrast, organizations provide more isolation than teams, as resources cannot be shared between organizations. They are more difficult to manage than teams, as you must create and update resources for each organization individually. Organizations cater to bigger companies or users with intricate access needs, necessitating complete resource segregation.

Access to external systems

Consider the need for machine-to-machine M2M communications. If a system needs to interact with Grafana, ensure it has proper access.

Consider the following scenarios:

Schedule reports: Generate reports periodically from Grafana through the reporting API and have them delivered to different communications channels like email, instant messaging, or keep them in a shared storage.

Define alerts: Define alert rules to be triggered when a specific condition is met. Route alert notifications to different teams according to your organization’s needs.

Provisioning file: Provisioning files can be used to automate the creation of dashboards, data sources, and other resources.

These are just a few examples of how Grafana can be used in M2M scenarios. The platform is highly flexible and can be used in various M2M applications, making it a powerful tool for organizations seeking insights into their systems and devices.

Service accounts

You can use a service account to run automated workloads in Grafana, such as dashboard provisioning, configuration, or report generation. Create service accounts and service accounts tokens to authenticate applications, such as Terraform, with the Grafana API.

Note
Service accounts will eventually replace API keys as the primary way to authenticate applications that interact with Grafana.

A common use case for creating a service account is to perform operations on automated or triggered tasks. You can use service accounts to:

Schedule reports for specific dashboards to be delivered on a daily/weekly/monthly basis
Define alerts in your system to be used in Grafana
Set up an external SAML authentication provider
Interact with Grafana without signing in as a user

In Grafana Enterprise, you can also use service accounts in combination with role-based access control to grant very specific permissions to applications that interact with Grafana.

Note
Service accounts can only act in the organization they are created for. We recommend creating service accounts in each organization if you have the same task needed for multiple organizations.

The following video shows how to migrate from API keys to service accounts.

Service account tokens

To authenticate with Grafana’s HTTP API, a randomly generated string known as a service account token can be used as an alternative to a password.

When a service account is created, it can be linked to multiple access tokens. These service access tokens can be utilized in the same manner as API keys, providing a means to programmatically access Grafana HTTP API.

You can create multiple tokens for the same service account. You might want to do this if:

Multiple applications use the same permissions, but you want to audit or manage their actions separately.
You need to rotate or replace a compromised token.

Note
In Grafana’s audit logs it will still show up as the same service account.

Service account access tokens inherit permissions from the service account.

How to work with roles?

Grafana roles control the access of users and service accounts to specific resources and determine their authorized actions.

You can assign roles through the user interface or APIs, establish them through Terraform, or synchronize them automatically via an external IAM provider.

What are roles?

Within an organization, Grafana has established three primary organization roles - organization administrator, editor, and viewer - which dictate the user’s level of access and permissions, including the ability to edit data sources or create teams. Grafana also has an empty role that you can start with and to which you can gradually add custom permissions. To be a member of any organization, every user must be assigned a role.

In addition, Grafana provides a server administrator role that grants access to and enables interaction with resources that affect the entire instance, including organizations, users, and server-wide settings. This particular role can only be accessed by users of self-hosted Grafana instances. It is a significant role intended for the administrators of the Grafana instance.

What are permissions?

Each role consists of a set of permissions that determine the tasks a user can perform in the system. For example, the Admin role includes permissions that let an administrator create and delete users.

Grafana allows for precise permission settings on both dashboards and folders, giving you the ability to control which users and teams can view, edit, and administer them. For example, you might want a certain viewer to be able to edit a dashboard. While that user can see all dashboards, you can grant them access to update only one of them.

In Grafana Enterprise, you can also grant granular permissions for data sources to control who can query and edit them.

Dashboard, folder, and data source permissions can be set through the UI or APIs or provisioned through Terraform.

Role-based access control

Note
Available in Grafana Enterprise and Grafana Cloud.

If you think that the basic organization and server administrator roles are too limiting, it might be beneficial to employ role-based access control (RBAC). RBAC is a flexible approach to managing user access to Grafana resources, including users, data sources, and reports. It enables easy granting, changing, and revoking of read and write access for users.

RBAC comes with pre-defined roles, such as data source writer, which allows updating, reading, or querying all data sources. You can assign these roles to users, teams, and service accounts.

In addition, RBAC empowers you to generate personalized roles and modify permissions authorized by the standard Grafana roles.

User synchronization between Grafana and identity providers

When connecting Grafana to an identity provider, it’s important to think beyond just the initial authentication setup. You should also think about the maintenance of user bases and roles. Using Grafana’s team and role synchronization features ensures that updates you make to a user in your identity provider will be reflected in their role assignment and team memberships in Grafana.

Team sync

Team sync is a feature that allows you to synchronize teams or groups from your authentication provider with teams in Grafana. This means that users of specific teams or groups in LDAP, OAuth, or SAML will be automatically added or removed as members of corresponding teams in Grafana. Whenever a user logs in, Grafana will check for any changes in the teams or groups of the authentication provider and update the user’s teams in Grafana accordingly. This makes it easy to manage user permissions across multiple systems.

Note
Available in Grafana Enterprise and to customers on select Grafana Cloud plans. For pricing information, visit pricing or contact our sales team.

Note
Team synchronization occurs only when a user logs in. However, if you are using LDAP, it is possible to enable active background synchronization. This allows for the continuous synchronization of teams.

Role Sync

Grafana can synchronize basic roles from your authentication provider by mapping attributes from the identity provider to the user role in Grafana. This means that users with specific attributes, like role, team, or group membership in LDAP, OAuth, or SAML, can be automatically assigned the corresponding role in Grafana. Whenever a user logs in, Grafana checks for any changes in the user information retrieved from the authentication provider and updates the user’s role in Grafana accordingly.

Organization sync

Organization sync is the process of binding all the users from an organization in Grafana. This delegates the role of managing users to the identity provider. This way, there’s no need to manage user access from Grafana because the identity provider will be queried whenever a new user tries to log in.

With organization sync, you can assign users from identity provider groups to corresponding Grafana organizations. This functionality is similar to role sync but with the added benefit of specifying the organization that a user belongs to for a particular identity provider group. Please note that this feature is only available for self-hosted Grafana instances, as Cloud Grafana instances have a single organization limit.

Note
The following applies:

Organization sync is currently only supported for SAML and LDAP.

You can only map basic roles with Organization sync.

You don’t need to invite users through Grafana when syncing with Organization sync.

Set up Grafana monitoring

Fri, 03 Apr 2026 19:43:06 +0000

Set up Grafana monitoring

Grafana supports tracing.

Grafana can emit Jaeger or OpenTelemetry Protocol (OTLP) traces for its HTTP API endpoints and propagate Jaeger and w3c Trace Context trace information to compatible data sources. All HTTP endpoints are logged evenly (annotations, dashboard, tags, and so on). When a trace ID is propagated, it is reported with operation ‘HTTP /datasources/proxy/:id/*’.

Refer to Configuration’s OpenTelemetry section for a reference of tracing options available in Grafana.

View Grafana internal metrics

Grafana collects some metrics about itself internally. Grafana supports pushing metrics to Graphite or exposing them to be scraped by Prometheus.

For more information about configuration options related to Grafana metrics, refer to metrics and metrics.graphite in Configuration.

Available metrics

When enabled, Grafana exposes a number of metrics, including:

Active Grafana instances
Number of dashboards, users, and playlists
HTTP status codes
Requests by routing group
Grafana active alerts
Grafana performance

Native histogram format

Grafana exposes HTTP request metrics using native histograms for a more accurate representation of metric distributions. By default, both native histograms and classic histogram buckets are exposed for compatibility.

To reduce metric cardinality, you can disable classic histogram buckets and expose only native histograms by setting the following option in your configuration file:

[metrics]
# Enable classic HTTP histogram buckets alongside native histograms
# Set to false to only expose native histogram format (reduces cardinality)
classic_http_histogram_enabled = false

Pull metrics from Grafana into Prometheus

These instructions assume you have already added Prometheus as a data source in Grafana.

Enable Prometheus to scrape metrics from Grafana. In your configuration file (grafana.ini or custom.ini depending on your operating system) remove the semicolon to enable the following configuration options:

# Metrics available at HTTP URL /metrics and /metrics/plugins/:pluginId
[metrics]
# Disable / Enable internal metrics
enabled           = true

# Disable total stats (stat_totals_*) metrics to be generated
disable_total_stats = false

(optional) If you want to require authorization to view the metrics endpoints, then uncomment and set the following options:
```
basic_auth_username =
basic_auth_password =
```
Restart Grafana. Grafana now exposes metrics at http://localhost:3000/metrics.

Add the job to your prometheus.yml file. Example:

- job_name: 'grafana_metrics'

  scrape_interval: 15s
  scrape_timeout: 5s

  static_configs:
    - targets: ['localhost:3000']

Restart Prometheus. Your new job should appear on the Targets tab.
In Grafana, click Connections in the left-side menu.
Under your connections, click Data Sources.
Select the Prometheus data source.
Under the name of your data source, click Dashboards.
On the Dashboards tab, click Import in the Grafana metrics row to import the Grafana metrics dashboard. All scraped Grafana metrics are available in the dashboard.

View Grafana metrics in Graphite

These instructions assume you have already added Graphite as a data source in Grafana.

Enable sending metrics to Graphite. In your configuration file (grafana.ini or custom.ini depending on your operating system) remove the semicolon to enable the following configuration options:

# Metrics available at HTTP API Url /metrics
[metrics]
# Disable / Enable internal metrics
enabled           = true

# Disable total stats (stat_totals_*) metrics to be generated
disable_total_stats = false

Enable [metrics.graphite] options:

# Send internal metrics to Graphite
[metrics.graphite]
# Enable by setting the address setting (ex localhost:2003)
address = <hostname or ip>:<port#>
prefix = prod.grafana.%(instance_name)s.

Restart Grafana. Grafana now exposes metrics at http://localhost:3000/metrics and sends them to the Graphite location you specified.

Pull metrics from Grafana backend plugin into Prometheus

Any installed backend plugin exposes a metrics endpoint through Grafana that you can configure Prometheus to scrape.

These instructions assume you have already added Prometheus as a data source in Grafana.

Enable Prometheus to scrape backend plugin metrics from Grafana. In your configuration file (grafana.ini or custom.ini depending on your operating system) remove the semicolon to enable the following configuration options:

# Metrics available at HTTP URL /metrics and /metrics/plugins/:pluginId
[metrics]
# Disable / Enable internal metrics
enabled           = true

# Disable total stats (stat_totals_*) metrics to be generated
disable_total_stats = false

(optional) If you want to require authorization to view the metrics endpoints, then uncomment and set the following options:
```
basic_auth_username =
basic_auth_password =
```
Restart Grafana. Grafana now exposes metrics at http://localhost:3000/metrics/plugins/<plugin id>, e.g. http://localhost:3000/metrics/plugins/grafana-github-datasource if you have the Grafana GitHub datasource installed.

Add the job to your prometheus.yml file. Example:

- job_name: 'grafana_github_datasource'

  scrape_interval: 15s
  scrape_timeout: 5s
  metrics_path: /metrics/plugins/grafana-test-datasource

  static_configs:
    - targets: ['localhost:3000']

Restart Prometheus. Your new job should appear on the Targets tab.
In Grafana, hover your mouse over the Configuration (gear) icon on the left sidebar and then click Data Sources.
Select the Prometheus data source.
Import a Golang application metrics dashboard - for example Go Processes.

Set up Grafana for high availability

Fri, 03 Apr 2026 19:43:06 +0000

Set up Grafana for high availability

Note
To prevent duplicate alerts in Grafana high availability, additional steps are required.

Please refer to Alerting high availability for more information.

Grafana uses an embedded sqlite3 database to store users, dashboards, and other persistent data by default. For high availability, you must use a shared database to store this data. This shared database can be either MySQL or Postgres.

Architecture

Your Grafana high availability environment will consist of two or more Grafana servers (cluster nodes) served by a load balancing reverse proxy. The cluster uses an active-active architecture with the load balancer allocating traffic between nodes and re-allocating traffic to surviving nodes should there be failures. You need to configure your load balancer with a listener that responds to a shared cluster hostname. The shared name is the hostname your users use to access Grafana.

For ease of use, we recommend you configure your load balancer to provide SSL termination. The shared Grafana database tracks session information, so your load balancer won’t need to provide session affinity services. See your load balancer’s documentation for details on its configuration and operations.

Before you begin

Before you complete the following tasks, configure a MySQL or Postgres database to be highly available. Configuring the MySQL or Postgres database for high availability is out of the scope of this guide, but you can find instructions online for each database.

Configure multiple Grafana servers to use the same database

Once you have a Postgres or MySQL database available, you can configure your multiple Grafana instances to use a shared backend database. Grafana has default and custom configuration files, and you can update the database settings by updating your custom configuration file as described in the [database]. Once configured to use a shared database, your multiple Grafana instances will persist all long-term data in that database.

Grafana Enterprise only: License your Grafana servers

If you’re using Grafana Enterprise:

Get a license token in the name of your cluster’s shared hostname.
Edit the root_url setting in each node’s grafana.ini configuration file to reflect the cluster’s shared hostname.
Install the license key as normal. For more information on installing your license key, refer to Add your license to a Grafana instance.

Alerting high availability

Grafana Alerting provides a high availability mode. It preserves the semantics of legacy dashboard alerting by executing all alerts on every server and by sending notifications only once per alert. Load distribution between servers is not supported at this time.

For further information and instructions on setting up alerting high availability, refer to Enable alerting high availability.

Legacy dashboard alerts

Legacy Grafana Alerting supports a limited form of high availability. In this model, alert notifications are deduplicated when running multiple servers. This means all alerts are executed on every server, but alert notifications are only sent once per alert. Grafana does not support load distribution between servers.

Grafana Live

Grafana Live works with limitations in highly available setup. For details, refer to the Configure Grafana Live HA setup.

User sessions

Grafana uses auth token strategy with database by default. This means that a load balancer can send a user to any Grafana server without having to log in on each server.

Set up Grafana HTTPS for secure web traffic

Fri, 03 Apr 2026 19:43:06 +0000

Set up Grafana HTTPS for secure web traffic

When accessing the Grafana UI through the web, it is important to set up HTTPS to ensure the communication between Grafana and the end user is encrypted, including login credentials and retrieved metric data.

In order to ensure secure traffic over the internet, Grafana must have a key for encryption and a Secure Socket Layer (SSL) Certificate to verify the identity of the site.

The following image shows a browser lock icon which confirms the connection is safe.

This topic shows you how to:

Obtain a certificate and key
Configure Grafana HTTPS
Restart the Grafana server

Before you begin

To follow these instructions, you need:

You must have shell access to the system and sudo access to perform actions as root or administrator.
For the CA-signed option, you need a domain name that you possess and that is associated with the machine you are using.

Obtain a certificate and key

You can use one of two methods to obtain a certificate and a key. The faster and easier self-signed option might show browser warnings to the user that they will have to accept each time they visit the site. Alternatively, the Certificate Authority (CA) signed option requires more steps to complete, but it enables full trust with the browser. To learn more about the difference between these options, refer to Difference between self-signed CA and self-signed certificate.

Generate a self-signed certificate

This section shows you how to use openssl tooling to generate all necessary files from the command line.

Run the following command to generate a 2048-bit RSA private key, which is used to decrypt traffic:
Bash
```
sudo openssl genrsa -out /etc/grafana/grafana.key 2048
```

Run the following command to generate a certificate, using the private key from the previous step.

sudo openssl req -new -key /etc/grafana/grafana.key -out /etc/grafana/grafana.csr

When prompted, answer the questions, which might include your fully-qualified domain name, email address, country code, and others. The following example is similar to the prompts you will see.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Virginia
Locality Name (eg, city) []:Richmond
Organization Name (eg, company) [Internet Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:subdomain.mysite.com
Email Address []:me@mysite.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Run the following command to self-sign the certificate with the private key, for a period of validity of 365 days:

sudo openssl x509 -req -days 365 -in /etc/grafana/grafana.csr -signkey /etc/grafana/grafana.key -out /etc/grafana/grafana.crt

Run the following commands to set the appropriate permissions for the files:
Bash
```
sudo chown grafana:grafana /etc/grafana/grafana.crt
sudo chown grafana:grafana /etc/grafana/grafana.key
sudo chmod 400 /etc/grafana/grafana.key /etc/grafana/grafana.crt
```
Note: When using these files, browsers might provide warnings for the resulting website because a third-party source does not trust the certificate. Browsers will show trust warnings; however, the connection will remain encrypted.

The following image shows an insecure HTTP connection.

Insecure HTTPS connection

Obtain a signed certificate from LetsEncrypt

LetsEncrypt is a nonprofit certificate authority that provides certificates without any charge. For signed certificates, there are multiple companies and certificate authorities (CAs) available. The principles for generating the certificates might vary slightly in accordance with the provider but will generally remain the same.

The examples in this section use LetsEncrypt because it is free.

Note
The instructions provided in this section are for a Debian-based Linux system. For other distributions and operating systems, please refer to the certbot instructions. Also, these instructions require you to have a domain name that you are in control of. Dynamic domain names like those from Amazon EC2 or DynDNS providers will not function.

Install `snapd` and `certbot`

certbot is an open-source program used to manage LetsEncrypt certificates, and snapd is a tool that assists in running certbot and installing the certificates.

To install snapd, run the following commands:

sudo apt-get install snapd
sudo snap install core; sudo snap refresh core

Run the following commands to install:
Bash
```
sudo apt-get remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
```
These commands:
- Uninstall certbot from your system if it has been installed using a package manager
- Install certbot using snapd

Generate certificates using `certbot`

The sudo certbot certonly --standalone command prompts you to answer questions before it generates a certificate. This process temporarily opens a service on port 80 that LetsEncrypt uses to verify communication with your host.

To generate certificates using certbot, complete the following steps:

Ensure that port 80 traffic is permitted by applicable firewall rules.

Run the following command to generate certificates:

$ sudo certbot certonly --standalone

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): me@mysite.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let’s Encrypt project and the non-profit organization that
develops Certbot? We’d like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: n
Account registered.
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): subdomain.mysite.com
Requesting a certificate for subdomain.mysite.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/subdomain.mysite.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/subdomain.mysite.com/privkey.pem
This certificate expires on 2023-06-20.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let’s Encrypt:   https://letsencrypt.org/donate
* Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Set up symlinks to Grafana

Symbolic links, also known as symlinks, enable you to create pointers to existing LetsEncrypt files in the /etc/grafana directory. By using symlinks rather than copying files, you can use certbot to refresh or request updated certificates from LetsEncrypt without the need to reconfigure the Grafana settings.

To set up symlinks to Grafana, run the following commands:

$ sudo ln -s /etc/letsencrypt/live/subdomain.mysite.com/privkey.pem /etc/grafana/grafana.key
$ sudo ln -s /etc/letsencrypt/live/subdomain.mysite.com/fullchain.pem /etc/grafana/grafana.crt

Adjust permissions

Grafana usually runs under the grafana Linux group, and you must ensure that the Grafana server process has permission to read the relevant files. Without read access, the HTTPS server fails to start properly.

To adjust permissions, perform the following steps:

Run the following commands to set the appropriate permissions and groups for the files:

$ sudo chgrp -R grafana /etc/letsencrypt/*
$ sudo chmod -R g+rx /etc/letsencrypt/*
$ sudo chgrp -R grafana /etc/grafana/grafana.crt /etc/grafana/grafana.key
$ sudo chmod 440 /etc/grafana/grafana.crt /etc/grafana/grafana.key

Run the following command to verify that the grafana group can read the symlinks:

$ $ ls -l /etc/grafana/grafana.*

lrwxrwxrwx 1 root grafana    67 Mar 22 14:15 /etc/grafana/grafana.crt -> /etc/letsencrypt/live/subdomain.mysite.com/fullchain.pem
-rw-r----- 1 root grafana 54554 Mar 22 14:13 /etc/grafana/grafana.ini
lrwxrwxrwx 1 root grafana    65 Mar 22 14:15 /etc/grafana/grafana.key -> /etc/letsencrypt/live/subdomain.mysite.com/privkey.pem

Configure Grafana HTTPS and restart Grafana

In this section you edit the grafana.ini file so that it includes the certificate you created. If you need help identifying where to find this file, or what each key means, refer to Configuration file location.

To configure Grafana HTTPS and restart Grafana, complete the following steps.

Open the grafana.ini file and edit the following configuration parameters:
```
[server]
http_addr =
http_port = 3000
domain = mysite.com
root_url = https://subdomain.mysite.com:3000
cert_key = /etc/grafana/grafana.key
cert_file = /etc/grafana/grafana.crt
enforce_domain = False
protocol = https
```
Note: The standard port for SSL traffic is 443, which you can use instead of Grafana’s default port 3000. This change might require additional operating system privileges or configuration to bind to lower-numbered privileged ports.
Optional. From Grafana v11.2, edit the cert_pass configuration option with the decryption password if you are using encrypted certificates.
Restart the Grafana server using systemd, init.d, or the binary as appropriate for your environment.

Troubleshooting

Refer to the following troubleshooting tips as required.

Failure to obtain a certificate

The following reasons explain why the certbot process might fail:

To make sure you can get a certificate from LetsEncrypt, you need to ensure that port 80 is open so that LetsEncrypt can communicate with your machine. If port 80 is blocked or firewall is enabled, the exchange will fail and you won’t be able to receive a certificate.
LetsEncrypt requires proof that you control the domain, so attempts to obtain certificates for domains you do not control might be rejected.

Grafana starts, but HTTPS is unavailable

When you configure HTTPS, the following errors might appear in Grafana’s logs.

Permission denied

level=error msg="Stopped background service" service=*api.HTTPServer reason="open /etc/grafana/grafana.crt: permission denied"

Resolution

To ensure secure HTTPS setup, it is essential that the cryptographic keys and certificates are as restricted as possible. However, if the file permissions are too restricted, the Grafana process may not have access to the necessary files, thus impeding a successful HTTPS setup. Please re-examine the listed instructions to double check the file permissions and try again.

Cannot assign requested address

listen tcp 34.148.30.243:3000: bind: cannot assign requested address

Resolution

Check the config to ensure the http_addr is left blank, allowing Grafana to bind to all interfaces. If you have set http_addr to a specific subdomain, such as subdomain.mysite.com, this might prevent the Grafana process from binding to an external address, due to network address translation layers being present.

Set up image rendering

Fri, 03 Apr 2026 19:43:06 +0000

Set up image rendering

The Grafana Image Renderer service enables you to render Grafana panels and dashboards as PNGs, PDFs, or CSV files.

You can export visualizations to share with stakeholders or configure automatic exports for alert notifications.

Image rendering works with Grafana OSS, Grafana Enterprise, and Grafana Cloud. Some features are exclusive to Grafana Enterprise and Grafana Cloud.

Caution
We historically provided this functionality as a Grafana plugin. This plugin is deprecated and no longer receives updates. Similarly, we only support the latest version of the service.

Note
At any given time, we commit to supporting all stable currently supported versions of Grafana. If you find a bug, consider reporting it on our issue tracker.

Before you begin

Before you install the image renderer, ensure you have the following:

A running Grafana instance
Docker installed, or the ability to run binaries on Linux or Windows
At least 16 GiB of memory and 4 CPU cores available for the renderer service

Installation

To install the service, we recommend using Docker or other containerization software. This isn’t strictly required, so you can adapt to your specific environment as needed.

We ship images for linux/amd64 and linux/arm64. Windows and macOS can run these images with Docker Desktop. Additionally, we ship binaries for Windows and Linux on our GitHub Releases page.

To run the service, use a server with significant memory and CPU resources available. Some rendering tasks require several gigabytes of memory and many cores in a spiky pattern. We recommend you allocate at least 16 GiB of memory and at least 4 CPU cores. You may need to adapt this to your specific use case if your load is significant.

Install with Docker

While we ship a latest tag, prefer pinning a specific version in production environments. We commit to keeping the latest tag the latest stable release.

The following example creates a Docker network and starts both the renderer and Grafana services. This configuration demonstrates what environment variables to set, but it doesn’t use a production-ready Grafana instance:

docker network create grafana
docker run --network grafana --name renderer --rm --detach grafana/grafana-image-renderer:latest
docker run --network grafana --name grafana --rm --detach -p 3000:3000 --env GF_RENDERING_SERVER_URL=http://renderer:8081/render --env GF_RENDERING_CALLBACK_URL=http://grafana:3000/ grafana/grafana-enterprise:latest

Alternatively, if you prefer docker compose:

services:
  renderer:
    image: grafana/grafana-image-renderer:latest

  grafana:
    image: grafana/grafana-enterprise:latest
    ports:
      - "3000:3000"
    environment:
      GF_RENDERING_SERVER_URL: http://renderer:8081/render
      GF_RENDERING_CALLBACK_URL: http://grafana:3000/

If you’re running with memory limits, set the GOMEMLIMIT environment variable to a lower value than the limit, such as 1GiB. Don’t set GOMEMLIMIT to match the container’s limit because Chromium needs free memory on top. We recommend 1 GiB of GOMEMLIMIT per 8 GiB of container memory limit.

If you don’t use memory limits, the previous configuration can still be useful, especially if you run the service alongside other services on the same host.

Install with binaries

Binaries are released for Linux and Windows, for amd64 and arm64 architectures. macOS isn’t supported at this time. If you’re using macOS, prefer Docker Desktop.

The binaries don’t ship with a browser. You must install your own Chromium-based browser and configure it to be used. Examples include Google Chrome and Microsoft Edge. Configure the path to this browser binary with --browser.path.

The binaries are hosted on GitHub Releases. Download the appropriate binary for your platform and run it from the terminal. For example, run ./grafana-image-renderer server. See --help for more information.

Grafana configuration

Grafana includes options to specify where to find the renderer service and which authentication token to use in communication.

To configure these, use the following options in the .ini configuration file for Grafana:

[rendering]
; The URL is an HTTP(S) URL to the service, and its rendering endpoint.
; By default, the path is `/render`. This can be changed with nginx or similar reverse proxies.
server_url = http://renderer:8081/render

; The token is any _one_ token configured in the renderer service.
; If you configured multiple tokens in the service, choose one for Grafana.
; By default, a single token is configured, with the value of `-`.
renderer_token = -

For Docker or similar setups that use environment variables, use the following options:

GF_RENDERING_SERVER_URL
GF_RENDERING_RENDERER_TOKEN

Configuration

You can configure the service in the following ways:

CLI flags: Run with --help to see available flag names.
Environment variables: Run with --help to see names and current values. Most, but not all, variables map 1:1 to the CLI flag names.
Configuration file: Create a JSON or YAML configuration file in the service’s working directory. Name the file config.json, config.yaml, or config.yml. Dot-separated keys are nested keys. For example, a.b becomes {"a": {"b": "VALUE"}} in the file.

You can use --help to see all configuration options. For example, if you’re using Docker:

docker run --rm grafana/grafana-image-renderer:latest server --help

Security

The service requires a secret token to be present in all render requests. Set this token using --server.auth-token (AUTH_TOKEN). You can specify multiple tokens and have a unique key per Grafana instance. By default, the token used is -. In Grafana, set this to match one of the tokens with the [rendering] renderer_token (GF_RENDERING_RENDERER_TOKEN) configuration setting.

Monitor the image renderer

You can monitor the service using Prometheus or Grafana Mimir for metrics and any OpenTelemetry-compatible tracing backend for traces, such as Grafana Tempo.

Metrics are exposed on the /metrics endpoint. Traces are sent as configured in the configuration options. See --help for trace configuration options.

For a pre-built monitoring dashboard, refer to this example dashboard.

Set up Grafana Live

Fri, 03 Apr 2026 19:43:06 +0000

Set up Grafana Live

Grafana Live is a real-time messaging engine you can use to push event data to a frontend as soon as an event occurs.

This could be notifications about dashboard changes, new frames for rendered data, and so on. Live features can help eliminate a page reload or polling in many places, it can stream Internet of things (IoT) sensors or any other real-time data to panels.

Note
By real-time, we indicate a soft real-time. Due to network latencies, garbage collection cycles, and so on, the delay of a delivered message can be up to several hundred milliseconds or higher.

Concepts

Grafana Live sends data to clients over persistent WebSocket connections, based on a Pub/Sub model. The Grafana frontend subscribes on each channel to receive data that has been published in that channel. All subscriptions on a page are multiplexed inside a single WebSocket connection. There are some rules regarding Live channel names – see Grafana Live channel.

Handling persistent connections like WebSocket in scale may require operating system and infrastructure tuning. That’s why by default Grafana Live supports 100 simultaneous connections max. For more details on how to tune this limit, refer to Live configuration section.

Features

Having a way to send data to clients in real-time opens a road for new ways of data interaction and visualization. Below we describe Grafana Live features supported at the moment.

Dashboard change notifications

As soon as there is a change to the dashboard layout, it is automatically reflected on other devices connected to Grafana Live.

Data streaming from plugins

With Grafana Live, backend data source plugins can stream updates to frontend panels.

For data source plugin channels, Grafana uses ds scope. Namespace in the case of data source channels is a data source unique ID (UID) which is issued by Grafana at the moment of data source creation. The path is a custom string that plugin authors free to choose themselves (just make sure it consists of allowed symbols).

For example, a data source channel looks like this: ds/<DATASOURCE_UID>/<CUSTOM_PATH>.

Refer to the tutorial about building a streaming data source backend plugin for more details.

The basic streaming example included in Grafana core streams frames with some generated data to a panel. To look at it create a new panel and point it to the -- Grafana -- data source. Next, choose Live Measurements and select the plugin/testdata/random-20Hz-stream channel.

Data streaming from Telegraf

A new API endpoint /api/live/push/:streamId allows accepting metrics data in InfluxDB line protocol format from Telegraf. These metrics are transformed into Grafana data frames and published to channels.

Important: When streaming data from Telegraf, ensure that:

The data format is set to influx in your Telegraf configuration
Timestamps are in nanoseconds (Unix epoch time)

Refer to the tutorial about streaming metrics from Telegraf to Grafana for more information.

Grafana Live channel

Grafana Live is a PUB/SUB server, clients subscribe to channels to receive real-time updates published to those channels.

Channel structure

Channel is a string identifier. In Grafana channel consists of 3 parts delimited by /:

Scope
Namespace
Path

For example, the channel grafana/dashboard/xyz has the scope grafana, namespace dashboard, and path xyz.

Scope, namespace and path can only have ASCII alphanumeric symbols (A-Z, a-z, 0-9), _ (underscore) and - (dash) at the moment. The path part can additionally have /, . and = symbols. The meaning of scope, namespace and path is context-specific.

The maximum length of a channel is 160 symbols.

Scope determines the purpose of a channel in Grafana. For example, for data source plugin channels Grafana uses ds scope. For built-in features like dashboard edit notifications Grafana uses grafana scope.

Namespace has a different meaning depending on scope. For example, for grafana scope this could be a name of built-in real-time feature like dashboard (i.e. dashboards events).

The path, which is the final part of a channel, usually contains the identifier of some concrete resource such as the ID of a dashboard that a user is currently looking at. But a path can be anything.

Channels are lightweight and ephemeral - they are created automatically on user subscription and removed as soon as last user left a channel.

Data format

Data sent over Live channels supports multiple formats depending on the endpoint:

WebSocket channels

Data transmitted through WebSocket channels for real-time streaming to frontend clients must be JSON-encoded. This applies to:

Dashboard change notifications
Data source plugin streaming (ds scope channels)
Custom application channels

HTTP Push API

The /api/live/push/:streamId endpoint accepts metrics data in InfluxDB line protocol format. This is particularly useful for streaming metrics from tools like Telegraf.

The line protocol format follows this structure:

<measurement>[,<tag_key>=<tag_value>[,<tag_key>=<tag_value>]] <field_key>=<field_value>[,<field_key>=<field_value>] [<timestamp>]

Important: Timestamps must be encoded in nanoseconds (Unix epoch time in nanoseconds).

Example:

temperature,location=room1,sensor=A temp_celsius=23.5,humidity=45 1651498849000000000

In this example:

temperature is the measurement name
location=room1 and sensor=A are tags
temp_celsius=23.5 and humidity=45 are fields
1651498849000000000 is the timestamp in nanoseconds

When data is received via the HTTP Push API, it is automatically transformed into Grafana data frames and published to the appropriate channels for visualization.

For more information about the InfluxDB line protocol format, refer to the InfluxDB line protocol documentation.

Configure Grafana Live

Grafana Live is enabled by default. In Grafana v8.0, it has a strict default for a maximum number of connections per Grafana server instance.

Max number of connections

Grafana Live uses persistent connections (WebSocket at the moment) to deliver real-time updates to clients.

WebSocket is a persistent connection that starts with an HTTP Upgrade request (using the same HTTP port as the rest of Grafana) and then switches to a TCP mode where WebSocket frames can travel in both directions between a client and a server. Each logged-in user opens a WebSocket connection – one per browser tab.

The number of maximum WebSocket connections users can establish with Grafana is limited to 100 by default. See max_connections option.

In case you want to increase this limit, ensure that your server and infrastructure allow handling more connections. The following sections discuss several common problems which could happen when managing persistent connections, in particular WebSocket connections.

Request origin check

To avoid hijacking of WebSocket connection Grafana Live checks the Origin request header sent by a client in an HTTP Upgrade request. Requests without Origin header pass through without any origin check.

By default, Live accepts connections with Origin header that matches configured root_url (which is a public Grafana URL).

It is possible to provide a list of additional origin patterns to allow WebSocket connections from. This can be achieved using the allowed_origins option of Grafana Live configuration.

Resource usage

Each persistent connection costs some memory on a server. Typically, this should be about 50 KB per connection at this moment. Thus a server with 1 GB RAM is expected to handle about 20k connections max. Each active connection consumes additional CPU resources since the client and server send PING/PONG frames to each other to maintain a connection.

Using the streaming functionality results in additional CPU usage. The exact CPU resource utilization can be hard to estimate as it heavily depends on the Grafana Live usage pattern.

Open file limit

Each WebSocket connection costs a file descriptor on a server machine where Grafana runs. Most operating systems have a quite low default limit for the maximum number of descriptors that process can open.

To look at the current limit on Unix run:

ulimit -n

On a Linux system, you can also check out the current limits for a running process with:

cat /proc/<PROCESS_PID>/limits

The open files limit shows approximately how many user connections your server can currently handle.

To increase this limit, refer to these instructions for popular operating systems.

Ephemeral port exhaustion

Ephemeral port exhaustion problem can happen between your load balancer (or reverse proxy) software and Grafana server. For example, when you load balance requests/connections between different Grafana instances. If you connect directly to a single Grafana server instance, then you should not come across this issue.

The problem arises because each TCP connection uniquely identified in the OS by the 4-part-tuple:

source ip | source port | destination ip | destination port

By default, on load balancer/server boundary you are limited to 65535 possible variants. But actually, due to some OS limits (for example on Unix available ports defined in ip_local_port_range sysctl parameter) and sockets in TIME_WAIT state, the number is even less.

In order to eliminate a problem you can:

Increase the ephemeral port range by tuning ip_local_port_range kernel option.
Deploy more Grafana server instances to load balance across.
Deploy more load balancer instances.
Use virtual network interfaces.

WebSocket and proxies

Not all proxies can transparently proxy WebSocket connections by default. For example, if you are using Nginx before Grafana you need to configure WebSocket proxy like this:

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream grafana {
        server 127.0.0.1:3000;
    }

    server {
        listen 8000;

        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $http_host;
            proxy_pass http://grafana;
        }
    }
}

See the Nginx blog on their website for more information. Also, refer to your load balancer/reverse proxy documentation to find out more information on dealing with WebSocket connections.

Some corporate proxies can remove headers required to properly establish a WebSocket connection. In this case, you should tune intermediate proxies to not remove required headers. However, the better option is to use Grafana with TLS. Now WebSocket connection will inherit TLS and thus must be handled transparently by proxies.

Proxies like Nginx and Envoy have default limits on maximum number of connections which can be established. Make sure you have a reasonable limit for max number of incoming and outgoing connections in your proxy configuration.

Configure Grafana Live HA setup

By default, Grafana Live uses in-memory data structures and in-memory PUB/SUB hub for handling subscriptions.

In a high availability Grafana setup involving several Grafana server instances behind a load balancer, you can find the following limitations:

Built-in features like dashboard change notifications will only be broadcasted to users connected to the same Grafana server process instance.
Streaming from Telegraf will deliver data only to clients connected to the same instance which received Telegraf data, active stream cache is not shared between different Grafana instances.
A separate unidirectional stream between Grafana and backend data source may be opened on different Grafana servers for the same channel.

To bypass these limitations, Grafana has a Live HA engine that requires Redis to work.

Configure Redis Live engine

When the Redis engine is configured, Grafana Live keeps its state in Redis and uses Redis PUB/SUB functionality to deliver messages to all subscribers throughout all Grafana server nodes.

Here is an example configuration:

[live]
ha_engine = redis
ha_engine_address = 127.0.0.1:6379

For additional information, refer to the ha_engine and ha_engine_address options.

After running:

All built-in real-time notifications like dashboard changes are delivered to all Grafana server instances and broadcasted to all subscribers.
Streaming from Telegraf delivers messages to all subscribers.
A separate unidirectional stream between Grafana and backend data source opens on different Grafana servers. Publishing data to a channel delivers messages to instance subscribers, as a result, publications from different instances on different machines do not produce duplicate data on panels.

Note
Live currently does not support Redis Sentinel. We recommend using a Redis Cluster for high-availability via a k8s helm chart such as the Bitnami Redis chart which has values to provision a Redis Cluster. Grafana Live can then be pointed to the redis-headless service.
 live:
   ha_engine: redis
   ha_engine_address: redis-headless.grafana.svc.cluster.local:6379
   ha_engine_password: $__file{/your/redis/password/secret/mount}

Note
The Redis Live HA engine does not currently support TLS.

Configure a Grafana Docker image

Fri, 03 Apr 2026 19:43:06 +0000

Caution
Starting with Grafana release 12.4.0, the grafana/grafana-oss Docker Hub repository will no longer be updated. Instead, we encourage you to use the grafana/grafana Docker Hub repository. These two repositories have the same Grafana OSS docker images.

Configure a Grafana Docker image

This topic explains how to run Grafana on Docker in complex environments that require you to:

Use different images
Change logging levels
Define secrets on the Cloud
Configure plugins

Note: The examples in this topic use the Grafana Enterprise Docker image. You can use the Grafana Open Source edition by changing the Docker image to grafana/grafana.

Supported Docker image variants

You can install and run Grafana using the following official Docker images.

Grafana Enterprise: grafana/grafana-enterprise
Grafana Open Source: grafana/grafana

Each edition is available in two variants: Alpine and Ubuntu.

Alpine image (recommended)

Alpine Linux is a Linux distribution not affiliated with any commercial entity. It is a versatile operating system that caters to users who prioritize security, efficiency, and user-friendliness. Alpine Linux is much smaller than other distribution base images, allowing for slimmer and more secure images to be created.

By default, the images are built using the widely used Alpine Linux project base image, which can be found in the Alpine docker repo. If you prioritize security and want to minimize the size of your image, it is recommended that you use the Alpine variant. However, it’s important to note that the Alpine variant uses musl libc instead of glibc and others. As a result, some software might encounter problems depending on their libc requirements. Nonetheless, most software should not experience any issues, so the Alpine variant is generally reliable.

Ubuntu image

The Ubuntu-based Grafana Enterprise and OSS images are built using the Ubuntu base image, which can be found in the Ubuntu docker repo. An Ubuntu-based image can be a good option for users who prefer an Ubuntu-based image or require certain tools unavailable on Alpine.

Grafana Enterprise: grafana/grafana-enterprise:<version>-ubuntu
Grafana Open Source: grafana/grafana:<version>-ubuntu

Run a specific version of Grafana

You can also run a specific version of Grafana or a beta version based on the main branch of the grafana/grafana GitHub repository.

Note: If you use a Linux operating system such as Debian or Ubuntu and encounter permission errors when running Docker commands, you might need to prefix the command with sudo or add your user to the docker group. The official Docker documentation provides instructions on how to run Docker without a non-root user.

To run a specific version of Grafana, add it in the command section:

docker run -d -p 3000:3000 --name grafana grafana/grafana-enterprise:<version number>

Example:

The following command runs the Grafana Enterprise container and specifies version 9.4.7. If you want to run a different version, modify the version number section.

docker run -d -p 3000:3000 --name grafana grafana/grafana-enterprise:9.4.7

For recent releases of Grafana, there are also minor version tags in the grafana/grafana and grafana/grafana-enterprise docker repositories. For example, if you want to always have the latest 12.1 version, you can use grafana/grafana-enterprise:12.1 or grafana/grafana-enterprise:12.1-ubuntu.

Run the Grafana main branch

After every successful build of the main branch, two tags, grafana/grafana:main and grafana/grafana:main-ubuntu, are updated. Additionally, two new tags are created: grafana/grafana-dev:<version> and grafana/grafana-dev:<version>-ubuntu, where version is a prerelease version of Grafana. For example, if 1234 is the GitHub Run ID of the build, 12.2.0-1234. These tags provide access to the most recent Grafana main builds. For more information, refer to grafana/grafana-dev.

To ensure stability and consistency, we strongly recommend using the grafana/grafana-dev:<version> tag when running the Grafana main branch in a production environment. This tag ensures that you are using a specific version of Grafana instead of the most recent commit, which could potentially introduce bugs or issues. It also avoids polluting the tag namespace for the main Grafana images with thousands of pre-release tags.

For a list of available tags, refer to grafana/grafana and grafana/grafana-dev.

Default paths

Grafana comes with default configuration parameters that remain the same among versions regardless of the operating system or the environment (for example, virtual machine, Docker, Kubernetes, etc.). You can refer to the Configure Grafana documentation to view all the default configuration settings.

The following configurations are set by default when you start the Grafana Docker container. When running in Docker you cannot change the configurations by editing the conf/grafana.ini file. Instead, you can modify the configuration using environment variables.

Setting	Default value
GF_PATHS_CONFIG	/etc/grafana/grafana.ini
GF_PATHS_DATA	/var/lib/grafana
GF_PATHS_HOME	/usr/share/grafana
GF_PATHS_LOGS	/var/log/grafana
GF_PATHS_PLUGINS	/var/lib/grafana/plugins
GF_PATHS_PROVISIONING	/etc/grafana/provisioning

Install plugins in the Docker container

You can install publicly available plugins and plugins that are private or used internally in an organization. For plugin installation instructions, refer to Install plugins in the Docker container.

Install plugins from other sources

To install plugins from other sources, you must define the custom URL and specify it immediately before the plugin name in the GF_PLUGINS_PREINSTALL environment variable: GF_PLUGINS_PREINSTALL=<plugin ID>@[<plugin version>]@<url to plugin zip>.

Example:

The following command runs Grafana Enterprise on port 3000 in detached mode and installs the custom plugin, which is specified as a URL parameter in the GF_PLUGINS_PREINSTALL environment variable.

docker run -d -p 3000:3000 --name=grafana \
  -e "GF_PLUGINS_PREINSTALL=custom-plugin@@http://plugin-domain.com/my-custom-plugin.zip,grafana-clock-panel" \
  grafana/grafana-enterprise

Build a custom Grafana Docker image

In the Grafana GitHub repository, the packaging/docker/custom/ folder includes a Dockerfile that you can use to build a custom Grafana image. The Dockerfile accepts GRAFANA_VERSION, GF_INSTALL_PLUGINS, and GF_INSTALL_IMAGE_RENDERER_PLUGIN as build arguments.

The GRAFANA_VERSION build argument must be a valid grafana/grafana Docker image tag. By default, Grafana builds an Alpine-based image. To build an Ubuntu-based image, append -ubuntu to the GRAFANA_VERSION build argument.

Example:

The following example shows you how to build and run a custom Grafana Docker image based on the latest official Ubuntu-based Grafana Docker image:

# go to the custom directory
cd packaging/docker/custom

# run the docker build command to build the image
docker build \
  --build-arg "GRAFANA_VERSION=latest-ubuntu" \
  -t grafana-custom .

# run the custom grafana container using docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom

Build Grafana with the Image Renderer plugin pre-installed

Note: This feature is experimental.

Currently, the Grafana Image Renderer plugin requires dependencies that are not available in the Grafana Docker image (see GitHub Issue#301 for more details). However, you can create a customized Docker image using the GF_INSTALL_IMAGE_RENDERER_PLUGIN build argument as a solution. This will install the necessary dependencies for the Grafana Image Renderer plugin to run.

Example:

The following example shows how to build a customized Grafana Docker image that includes the Image Renderer plugin.

# go to the folder
cd packaging/docker/custom

# running the build command
docker build \
  --build-arg "GRAFANA_VERSION=latest" \
  --build-arg "GF_INSTALL_IMAGE_RENDERER_PLUGIN=true" \
  -t grafana-custom .

# running the docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom

Build a Grafana Docker image with pre-installed plugins

If you run multiple Grafana installations with the same plugins, you can save time by building a customized image that includes plugins available on the Grafana Plugin download page. When you build a customized image, Grafana doesn’t have to install the plugins each time it starts, making the startup process more efficient.

Note: To specify the version of a plugin, you can use the GF_INSTALL_PLUGINS build argument and add the version number. The latest version is used if you don’t specify a version number. For example, you can use --build-arg "GF_INSTALL_PLUGINS=grafana-clock-panel 1.0.1,grafana-simple-json-datasource 1.3.5" to specify the versions of two plugins.

Example:

The following example shows how to build and run a custom Grafana Docker image with pre-installed plugins.

# go to the custom directory
cd packaging/docker/custom

# running the build command
# include the plugins you want e.g. clock planel etc
docker build \
  --build-arg "GRAFANA_VERSION=latest" \
  --build-arg "GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-simple-json-datasource" \
  -t grafana-custom .

# running the custom Grafana container using the docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom

Build a Grafana Docker image with pre-installed plugins from other sources

You can create a Docker image containing a plugin that is exclusive to your organization, even if it is not accessible to the public. Simply use the GF_INSTALL_PLUGINS build argument to specify the plugin’s URL and installation folder name, such as GF_INSTALL_PLUGINS=<url to plugin zip>;<plugin install folder name>.

The following example demonstrates creating a customized Grafana Docker image that includes a custom plugin from a URL link, the clock panel plugin, and the simple-json-datasource plugin. You can define these plugins in the build argument using the Grafana Plugin environment variable.

# go to the folder
cd packaging/docker/custom

# running the build command
docker build \
  --build-arg "GRAFANA_VERSION=latest" \
  --build-arg "GF_INSTALL_PLUGINS=http://plugin-domain.com/my-custom-plugin.zip;my-custom-plugin,grafana-clock-panel,grafana-simple-json-datasource" \
  -t grafana-custom .

# running the docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom

Logging

By default, Docker container logs are directed to STDOUT, a common practice in the Docker community. You can change this by setting a different log mode such as console, file, or syslog. You can use one or more modes by separating them with spaces, for example, console file. By default, both console and file modes are enabled.

Example:

The following example runs Grafana using the console file log mode that is set in the GF_LOG_MODE environment variable.

# Run Grafana while logging to both standard out
# and /var/log/grafana/grafana.log

docker run -p 3000:3000 -e "GF_LOG_MODE=console file" grafana/grafana-enterprise

Configure Grafana with Docker Secrets

You can input confidential data like login credentials and secrets into Grafana using configuration files. This method works well with Docker Secrets, as the secrets are automatically mapped to the /run/secrets/ location within the container.

You can apply this technique to any configuration options in conf/grafana.ini by setting GF_<SectionName>_<KeyName>__FILE to the file path that contains the secret information. For more information about Docker secret command usage, refer to docker secret.

The following example demonstrates how to set the admin password:

Admin password secret: /run/secrets/admin_password
Environment variable: GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/admin_password

Configure Docker secrets credentials for AWS CloudWatch

Grafana ships with built-in support for the Amazon CloudWatch datasource. To configure the data source, you must provide information such as the AWS ID-Key, secret access key, region, and so on. You can use Docker secrets as a way to provide this information.

Example:

The example below shows how to use Grafana environment variables via Docker Secrets for the AWS ID-Key, secret access key, region, and profile.

The example uses the following values for the AWS Cloudwatch data source:

AWS_default_ACCESS_KEY_ID=aws01us02
AWS_default_SECRET_ACCESS_KEY=topsecret9b78c6
AWS_default_REGION=us-east-1

Create a Docker secret for each of the values noted above.

echo "aws01us02" | docker secret create aws_access_key_id -

echo "topsecret9b78c6" | docker secret create aws_secret_access_key -

echo "us-east-1" | docker secret create aws_region -

Run the following command to determine that the secrets were created.

$ docker secret ls

The output from the command should look similar to the following:

ID                          NAME           DRIVER    CREATED              UPDATED
i4g62kyuy80lnti5d05oqzgwh   aws_access_key_id             5 minutes ago        5 minutes ago
uegit5plcwodp57fxbqbnke7h   aws_secret_access_key         3 minutes ago        3 minutes ago
fxbqbnke7hplcwodp57fuegit   aws_region                    About a minute ago   About a minute ago

Where:

ID = the secret unique ID that will be use in the docker run command

NAME = the logical name defined for each secret

Add the secrets to the command line when you run Docker.

docker run -d -p 3000:3000 --name grafana \
  -e "GF_DEFAULT_INSTANCE_NAME=my-grafana" \
  -e "GF_AWS_PROFILES=default" \
  -e "GF_AWS_default_ACCESS_KEY_ID__FILE=/run/secrets/aws_access_key_id" \
  -e "GF_AWS_default_SECRET_ACCESS_KEY__FILE=/run/secrets/aws_secret_access_key" \
  -e "GF_AWS_default_REGION__FILE=/run/secrets/aws_region" \
  -v grafana-data:/var/lib/grafana \
  grafana/grafana-enterprise

You can also specify multiple profiles to GF_AWS_PROFILES (for example, GF_AWS_PROFILES=default another).

The following list includes the supported environment variables:

GF_AWS_${profile}_ACCESS_KEY_ID: AWS access key ID (required).
GF_AWS_${profile}_SECRET_ACCESS_KEY: AWS secret access key (required).
GF_AWS_${profile}_REGION: AWS region (optional).

Troubleshoot a Docker deployment

By default, the Grafana log level is set to INFO, but you can increase the log level to DEBUG mode when you want to reproduce a problem.

For more information about logging, refer to logs.

Increase log level using the Docker run (CLI) command

To increase the log level to DEBUG mode, add the environment variable GF_LOG_LEVEL to the command line.

docker run -d -p 3000:3000 --name=grafana \
  -e "GF_LOG_LEVEL=debug" \
  grafana/grafana-enterprise

Increase log level using the Docker Compose

To increase the log level to DEBUG mode, add the environment variable GF_LOG_LEVEL to the docker-compose.yaml file.

version: '3.8'
services:
  grafana:
    image: grafana/grafana-enterprise
    container_name: grafana
    restart: unless-stopped
    environment:
      # increases the log level from info to debug
      - GF_LOG_LEVEL=debug
    ports:
      - '3000:3000'
    volumes:
      - 'grafana_storage:/var/lib/grafana'
volumes:
  grafana_storage: {}

Validate Docker Compose YAML file

The chance of syntax errors appearing in a YAML file increases as the file becomes more complex. You can use the following command to check for syntax errors.

# go to your docker-compose.yaml directory
cd /path-to/docker-compose/file

# run the validation command
docker compose config

If there are errors in the YAML file, the command output highlights the lines that contain errors. If there are no errors in the YAML file, the output includes the content of the docker-compose.yaml file in detailed YAML format.

Set up Grafana on Grafana Labs

Install Grafana

Install Grafana

Supported operating systems

Hardware recommendations

Sizing your deployment

Deployment tiers

Small

Medium

Large

Supported databases

Supported web browsers

Configure Grafana

Configure Grafana

Configuration file location

Linux

Docker

Windows

macOS

Grafana Cloud

Remove comments in the .ini files

Override configuration with environment variables

Variable expansion

env provider

file provider

vault provider

Configuration options

app_mode

instance_name

[paths]

data

temp_data_lifetime

logs

plugins

provisioning

[server]

protocol

min_tls_version

http_addr

http_port

domain

enforce_domain

root_url

serve_from_sub_path

router_logging

static_root_path

enable_gzip

cert_file

cert_key

cert_pass

certs_watch_interval

socket_gid

socket_mode

socket

cdn_url

read_timeout

[server.custom_response_headers]

[database]

type

host

name

user

password

url

max_idle_conn

max_open_conn

conn_max_lifetime

migration_locking

locking_attempt_timeout_sec

log_queries

ssl_mode

ssl_sni

isolation_level

ca_cert_path

client_key_path

client_cert_path

server_cert_name

path

cache_mode

wal

`env` provider

`file` provider

`vault` provider

`app_mode`

`instance_name`

`[paths]`

`data`

`temp_data_lifetime`

`logs`

`plugins`

`provisioning`

`[server]`

`protocol`

`min_tls_version`

`http_addr`

`http_port`

`domain`

`enforce_domain`

`root_url`

`serve_from_sub_path`

`router_logging`

`static_root_path`

`enable_gzip`

`cert_file`

`cert_key`

`cert_pass`

`certs_watch_interval`

`socket_gid`

`socket_mode`

`socket`

`cdn_url`

`read_timeout`

`[server.custom_response_headers]`

`[database]`

`type`

`host`

`name`

`user`

`password`

`url`

`max_idle_conn`

`max_open_conn`

`conn_max_lifetime`

`migration_locking`

`locking_attempt_timeout_sec`

`log_queries`

`ssl_mode`

`ssl_sni`

`isolation_level`

`ca_cert_path`

`client_key_path`

`client_cert_path`

`server_cert_name`

`path`

`cache_mode`

`wal`

`query_retries`

`transaction_retries`

`instrument_queries`

`skip_dashboard_uid_migration_on_startup`

`[remote_cache]`

`type`

`connstr`

`database`

`redis`

`memcache`

`[dataproxy]`

`logging`

`timeout`

`keep_alive_seconds`

`tls_handshake_timeout_seconds`

`expect_continue_timeout_seconds`

`max_conns_per_host`

`max_idle_connections`

`idle_conn_timeout_seconds`

`send_user_header`

`response_limit`

`row_limit`

`user_agent`

`[analytics]`