---
aliases:
- ../operators-guide/configure/reference-configuration-parameters/
- ../operators-guide/configuring/reference-configuration-parameters/
- ../reference-configuration-parameters/
- ../references/configuration-parameters/
description: Describes parameters used to configure Grafana Mimir.
menuTitle: Configuration parameters
title: Grafana Mimir configuration parameters
weight: 130
---

# Grafana Mimir configuration parameters

{{ .GeneratedFileWarning }}

You can configure Grafana Mimir by using a YAML file or via command-line flags
that represent configuration parameters.
To specify the YAML file, use the `-config.file` command-line option.
If you specify both the command-line flags and YAML configuration parameters,
the command-line flags take precedence over values in a YAML file.

To see the current configuration of any component,
go to the `/config` HTTP API endpoint.
Passwords are filtered out of this endpoint.

Parameters are
written in [YAML format](https://en.wikipedia.org/wiki/YAML), and
brackets indicate that a parameter is optional.

## Generic placeholders

- `<boolean>`: a boolean that can take the values `true` or `false`
- `<int>`: any integer matching the regular expression `[1-9]+[0-9]*`
- `<duration>`: a duration matching the regular expression `[0-9]+(ns|us|µs|ms|s|m|h|d|w|y)` where y = 365 days
- `<string>`: a string
- `<url>`: a URL
- `<filepath>`: a string containing an absolute or relative path and filename to a file on disk
- `<prefix>`: a CLI flag prefix based on the context (look at the parent configuration block to see which CLI flags prefix should be used)
- `<relabel_config>`: a [Prometheus relabeling configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config)
- `<time>`: a timestamp, with available formats:
  - `2006-01-20` (midnight, local timezone)
  - `2006-01-20T15:04` (local timezone)
  - RFC 3339 formats: `2006-01-20T15:04:05Z` (UTC) or `2006-01-20T15:04:05+07:00` (explicit timezone)

## Parameter categories

In order to simplify Mimir configuration, we categorize parameters by
maturity level and intended use:

- **Basic** parameters are ones that we expect the majority of users to modify.
  Examples of basic parameters are object store credentials and
  other dependency connection information.
  These parameters will generally remain stable for long periods of time,
  and they focus on user goals.
  In this reference, any parameters that are not marked as `(advanced)` or
  `(experimental)` are in the basic category.

- **Advanced** parameters are ones that few users will change
  from their default values.
  There are strong use cases for altered values.
  In this reference, advanced-category parameters include `(advanced)` at
  the beginning of their description.

- **Experimental** parameters are for new and experimental features.
  These parameters permit
  early adopters and Mimir developers to gain confidence with new
  features.
  In this reference, experimental-category parameters include `(experimental)` at
  the beginning of their description.

### Parameter lifecycle

When new parameters are added, they can be introduced as **basic**, **advanced**, or **experimental**.

**Experimental** parameters will remain experimental until they are either made stable or removed. Parameters that are made stable will be classified as either **basic** or **advanced**. We aim to make this decision on an experimental parameter within 6 months of its initial release, but this decision may take longer depending on what we discover during testing, or if upstream dependencies (e.g., Prometheus) of our code changes.

If we decide to eliminate a **basic** or **advanced** parameter, we will first mark it deprecated. After two more minor releases, a deprecated flag will be removed entirely. Use the metric `deprecated_flags_inuse_total` to determine whether you're using deprecated flags.
A configuration parameter is in maintenance and usable as expected between its deprecation and removal.
If you configure Mimir with a removed parameter, Mimir will fail to start.

![Parameter states](param-states.png)

## Use environment variables in the configuration

You can use environment variable references in the YAML configuration file
to set values that need to be configurable during deployment.
To do this, pass `-config.expand-env=true` on the command line and use
`${VAR}`,
where `VAR` is the name of the environment variable.

Each variable reference is replaced at startup by the value of the environment variable.
The replacement is case-sensitive and occurs before the YAML file is parsed.
References to undefined variables are replaced by empty strings unless you specify a default value or custom error text.

To specify a default value, use `${VAR:default_value}`,
where `default_value` is the value to use if the environment variable is undefined.

## Configuration parameters

{{ .ConfigFile }}
