Environment variables **cannot** be used to configure the Consul client. They
_can_ be used when running other `consul` CLI commands that connect with a
running agent, e.g. `CONSUL_HTTP_ADDR=192.168.0.1:8500 consul members`.
See [Consul Commands](/commands#environment-variables) for more
information.
## Command-line Options ((#commandline_options))
-> **Note:** Some CLI arguments may be different from HCL keys. See [Configuration Key Reference](#config_key_reference) for equivalent HCL Keys.
The agent configuration options below are all specified on the command-line.
- `-advertise` ((#\_advertise)) - The advertise address is used to change
the address that we advertise to other nodes in the cluster. By default, the [`-bind`](#_bind)
address is advertised. However, in some cases, there may be a routable address
that cannot be bound. This flag enables gossiping a different address to support
this. If this address is not routable, the node will be in a constant flapping
state as other nodes will treat the non-routability as a failure. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
template that is resolved at runtime.
<CodeBlockConfig heading="Using a static network interface name">
```shell-session
$ consul agent -advertise '{{ GetInterfaceIP "eth0" }}'
```
</CodeBlockConfig>
- `-advertise-wan` ((#\_advertise-wan)) - The advertise WAN address is used
to change the address that we advertise to server nodes joining through the WAN.
This can also be set on client agents when used in combination with the [`translate_wan_addrs`](#translate_wan_addrs) configuration option. By default, the [`-advertise`](#_advertise) address
is advertised. However, in some cases all members of all datacenters cannot be
on the same physical or virtual network, especially on hybrid setups mixing cloud
and private datacenters. This flag enables server nodes gossiping through the public
network for the WAN while using private VLANs for gossiping to each other and their
client agents, and it allows client agents to be reached at this address when being
accessed from a remote datacenter if the remote datacenter is configured with [`translate_wan_addrs`](#translate_wan_addrs). In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
template that is resolved at runtime.
- `-bootstrap` ((#\_bootstrap)) - This flag is used to control if a server
is in "bootstrap" mode. It is important that no more than one server **per** datacenter
be running in this mode. Technically, a server in bootstrap mode is allowed to
self-elect as the Raft leader. It is important that only a single node is in this
mode; otherwise, consistency cannot be guaranteed as multiple nodes are able to
self-elect. It is not recommended to use this flag after a cluster has been bootstrapped.
- `-bootstrap-expect` ((#\_bootstrap_expect)) - This flag provides the number
of expected servers in the datacenter. Either this value should not be provided
or the value must agree with other servers in the cluster. When provided, Consul
waits until the specified number of servers are available and then bootstraps the
cluster. This allows an initial leader to be elected automatically. This cannot
be used in conjunction with the legacy [`-bootstrap`](#_bootstrap) flag. This flag
requires [`-server`](#_server) mode.
- `-bind` ((#\_bind)) - The address that should be bound to for internal
cluster communications. This is an IP address that should be reachable by all other
nodes in the cluster. By default, this is "0.0.0.0", meaning Consul will bind to
all addresses on the local machine and will [advertise](/docs/agent/options#_advertise)
the private IPv4 address to the rest of the cluster. If there are multiple private
IPv4 addresses available, Consul will exit with an error at startup. If you specify
`"[::]"`, Consul will [advertise](/docs/agent/options#_advertise) the public
IPv6 address. If there are multiple public IPv6 addresses available, Consul will
exit with an error at startup. Consul uses both TCP and UDP and the same port for
both. If you have any firewalls, be sure to allow both protocols. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
template that must resolve at runtime to a single address. Some example templates:
<CodeBlockConfig heading="Using address within a specific CIDR">
```shell-session
$ consul agent -bind '{{ GetPrivateInterfaces | include "network" "10.0.0.0/8" | attr "address" }}'
```
</CodeBlockConfig>
<CodeBlockConfig heading="Using a static network interface name">
```shell-session
$ consul agent -bind '{{ GetInterfaceIP "eth0" }}'
```
</CodeBlockConfig>
<CodeBlockConfig heading="Using regular expression matching for network interface name that is forwardable and up">
```shell-session
$ consul agent -bind '{{ GetAllInterfaces | include "name" "^eth" | include "flags" "forwardable|up" | attr "address" }}'
```
</CodeBlockConfig>
- `-serf-wan-bind` ((#\_serf_wan_bind)) - The address that should be bound
to for Serf WAN gossip communications. By default, the value follows the same rules
as [`-bind` command-line flag](#_bind), and if this is not specified, the `-bind`
option is used. This is available in Consul 0.7.1 and later. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
template that is resolved at runtime.
- `-serf-lan-bind` ((#\_serf_lan_bind)) - The address that should be bound
to for Serf LAN gossip communications. This is an IP address that should be reachable
by all other LAN nodes in the cluster. By default, the value follows the same rules
as [`-bind` command-line flag](#_bind), and if this is not specified, the `-bind`
option is used. This is available in Consul 0.7.1 and later. In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
template that is resolved at runtime.
- `-check_output_max_size` - Override the default
limit of 4k for maximum size of checks, this is a positive value. By limiting this
size, it allows to put less pressure on Consul servers when many checks are having
a very large output in their checks. In order to completely disable check output
capture, it is possible to use [`discard_check_output`](#discard_check_output).
- `-client` ((#\_client)) - The address to which Consul will bind client
interfaces, including the HTTP, HTTPS, gRPC and DNS servers. By default, this is "127.0.0.1",
allowing only loopback connections. In Consul 1.0 and later this can be set to
a space-separated list of addresses to bind to, or a [go-sockaddr]
template that can potentially resolve to multiple addresses.
<CodeBlockConfig hideClipboard heading="Bind consul client interfaces to private IPv4 interfaces">
- `-config-file` ((#\_config_file)) - A configuration file to load. For
more information on the format of this file, read the [Configuration Files](#configuration_files)
section. This option can be specified multiple times to load multiple configuration
files. If it is specified multiple times, configuration files loaded later will
merge with configuration files loaded earlier. During a config merge, single-value
keys (string, int, bool) will simply have their values replaced while list types
will be appended together.
- `-config-dir` ((#\_config_dir)) - A directory of configuration files to
load. Consul will load all files in this directory with the suffix ".json" or ".hcl".
The load order is alphabetical, and the the same merge routine is used as with
the [`config-file`](#_config_file) option above. This option can be specified multiple
times to load multiple directories. Sub-directories of the config directory are
not loaded. For more information on the format of the configuration files, see
the [Configuration Files](#configuration_files) section.
- `-config-format` ((#\_config_format)) - The format of the configuration
files to load. Normally, Consul detects the format of the config files from the
".json" or ".hcl" extension. Setting this option to either "json" or "hcl" forces
Consul to interpret any file with or without extension to be interpreted in that
format.
- `-data-dir` ((#\_data_dir)) - This flag provides a data directory for
the agent to store state. This is required for all agents. The directory should
be durable across reboots. This is especially critical for agents that are running
in server mode as they must be able to persist cluster state. Additionally, the
directory must support the use of filesystem locking, meaning some types of mounted
folders (e.g. VirtualBox shared folders) may not be suitable.
**Note:** both server and non-server agents may store ACL tokens in the state in this directory so read access may grant access to any tokens on servers and to any tokens used during service registration on non-servers. On Unix-based platforms the files are written with 0600 permissions so you should ensure only trusted processes can execute as the same user as Consul. On Windows, you should ensure the directory has suitable permissions configured as these will be inherited.
- `-datacenter` ((#\_datacenter)) - This flag controls the datacenter in
which the agent is running. If not provided, it defaults to "dc1". Consul has first-class
support for multiple datacenters, but it relies on proper configuration. Nodes
in the same datacenter should be on a single LAN.
- `-dev` ((#\_dev)) - Enable development server mode. This is useful for
quickly starting a Consul agent with all persistence options turned off, enabling
an in-memory server which can be used for rapid prototyping or developing against
the API. In this mode, [Connect is enabled](/docs/connect/configuration) and
will by default create a new root CA certificate on startup. This mode is **not**
intended for production use as it does not write any data to disk. The gRPC port
is also defaulted to `8502` in this mode.
- `-disable-host-node-id` ((#\_disable_host_node_id)) - Setting this to
true will prevent Consul from using information from the host to generate a deterministic
node ID, and will instead generate a random node ID which will be persisted in
the data directory. This is useful when running multiple Consul agents on the same
host for testing. This defaults to false in Consul prior to version 0.8.5 and in
0.8.5 and later defaults to true, so you must opt-in for host-based IDs. Host-based
IDs are generated using [gopsutil](https://github.com/shirou/gopsutil/tree/master/v3/host), which
is shared with HashiCorp's [Nomad](https://www.nomadproject.io/), so if you opt-in
to host-based IDs then Consul and Nomad will use information on the host to automatically
assign the same ID in both systems.
- `-disable-keyring-file` ((#\_disable_keyring_file)) - If set, the keyring
will not be persisted to a file. Any installed keys will be lost on shutdown, and
only the given `-encrypt` key will be available on startup. This defaults to false.
- `-dns-port` ((#\_dns_port)) - the DNS port to listen on. This overrides
the default port 8600. This is available in Consul 0.7 and later.
- `-domain` ((#\_domain)) - By default, Consul responds to DNS queries in
the "consul." domain. This flag can be used to change that domain. All queries
in this domain are assumed to be handled by Consul and will not be recursively
resolved.
- `-alt-domain` ((#\_alt_domain)) - This flag allows Consul to respond to
DNS queries in an alternate domain, in addition to the primary domain. If unset,
no alternate domain is used.
In Consul 1.10.4 and later, Consul DNS responses will use the same domain as in the query (`-domain` or `-alt-domain`) where applicable.
PTR query responses will always use `-domain`, since the desired domain cannot be included in the query.
- `-enable-script-checks` ((#\_enable_script_checks)) This controls whether
[health checks that execute scripts](/docs/discovery/checks) are enabled on this
agent, and defaults to `false` so operators must opt-in to allowing these. This
was added in Consul 0.9.0.
~> **Security Warning:** Enabling script checks in some configurations may
introduce a remote execution vulnerability which is known to be targeted by
malware. We strongly recommend `-enable-local-script-checks` instead. See [this
blog post](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
Like [`enable_script_checks`](#_enable_script_checks), but only enable them when
they are defined in the local configuration files. Script checks defined in HTTP
API registrations will still not be allowed.
- `-encrypt` ((#\_encrypt)) - Specifies the secret key to use for encryption
of Consul network traffic. This key must be 32-bytes that are Base64-encoded. The
easiest way to create an encryption key is to use [`consul keygen`](/commands/keygen).
All nodes within a cluster must share the same encryption key to communicate. The
provided key is automatically persisted to the data directory and loaded automatically
whenever the agent is restarted. This means that to encrypt Consul's gossip protocol,
this option only needs to be provided once on each agent's initial startup sequence.
If it is provided after Consul has been initialized with an encryption key, then
the provided key is ignored and a warning will be displayed.
- `-grpc-port` ((#\_grpc_port)) - the gRPC API port to listen on. Default
-1 (gRPC disabled). See [ports](#ports) documentation for more detail.
- `-hcl` ((#\_hcl)) - A HCL configuration fragment. This HCL configuration
fragment is appended to the configuration and allows to specify the full range
of options of a config file on the command line. This option can be specified multiple
times. This was added in Consul 1.0.
- `-http-port` ((#\_http_port)) - the HTTP API port to listen on. This overrides
the default port 8500. This option is very useful when deploying Consul to an environment
which communicates the HTTP port through the environment e.g. PaaS like CloudFoundry,
allowing you to set the port directly via a Procfile.
- `-https-port` ((#\_https_port)) - the HTTPS API port to listen on. Default
-1 (https disabled). See [ports](#ports) documentation for more detail.
- `-log-file` ((#\_log_file)) - writes all the Consul agent log messages
to a file. This value is used as a prefix for the log file name. The current timestamp
is appended to the file name. If the value ends in a path separator, `consul-`
will be appended to the value. If the file name is missing an extension, `.log`
is appended. For example, setting `log-file` to `/var/log/` would result in a log
file path of `/var/log/consul-{timestamp}.log`. `log-file` can be combined with
[`-log-rotate-bytes`](#_log_rotate_bytes) and [-log-rotate-duration](#_log_rotate_duration)
for a fine-grained log rotation experience.
- `-log-rotate-bytes` ((#\_log_rotate_bytes)) - to specify the number of
bytes that should be written to a log before it needs to be rotated. Unless specified,
there is no limit to the number of bytes that can be written to a log file.
- `-log-rotate-duration` ((#\_log_rotate_duration)) - to specify the maximum
duration a log should be written to before it needs to be rotated. Must be a duration
value such as 30s. Defaults to 24h.
- `-log-rotate-max-files` ((#\_log_rotate_max_files)) - to specify the maximum
number of older log file archives to keep. Defaults to 0 (no files are ever deleted).
Set to -1 to discard old log files when a new one is created.
- `-default-query-time` ((#\_default_query_time)) - This flag controls the
amount of time a blocking query will wait before Consul will force a response.
This value can be overridden by the `wait` query parameter. Note that Consul applies
some jitter on top of this time. Defaults to 300s.
- `-max-query-time` ((#\_max_query_time)) - this flag controls the maximum
amount of time a blocking query can wait before Consul will force a response. Consul
applies jitter to the wait time. The jittered time will be capped to this time.
Defaults to 600s.
- `-join` ((#\_join)) - Address of another agent to join upon starting up.
This can be specified multiple times to specify multiple agents to join. If Consul
is unable to join with any of the specified addresses, agent startup will fail.
By default, the agent won't join any nodes when it starts up. Note that using [`retry_join`](#retry_join) could be more appropriate to help mitigate node startup race conditions when automating
a Consul cluster deployment.
In Consul 1.1.0 and later this can be dynamically defined with a
[go-sockaddr]
template that is resolved at runtime.
If using Enterprise network segments, see [additional documentation on
joining a client to a segment](/docs/enterprise/network-segments#join_a_client_to_a_segment).
- `-retry-join` ((#\_retry_join)) - Similar to [`-join`](#_join) but allows retrying a join until
it is successful. Once it joins successfully to a member in a list of members
it will never attempt to join again. Agents will then solely maintain their
membership via gossip. This is useful for cases where you know the address will
eventually be available. This option can be specified multiple times to
specify multiple agents to join. The value can contain IPv4, IPv6, or DNS
addresses. IPv6 must use the "bracketed" syntax. If multiple values
are given, they are tried and retried in the order listed until the first
succeeds.
In Consul 1.1.0 and later this can be dynamically defined with a
[go-sockaddr]
template that is resolved at runtime.
If Consul is running on the non-default Serf LAN port, the port must
be specified in the join address, or configured as the agent's default Serf port
using the [`ports.serf_lan`](#serf_lan_port) configuration option or
[`-serf-lan-port`](#_serf_lan_port) command line flag.
If using network segments (Enterprise), see [additional documentation on
joining a client to a segment](/docs/enterprise/network-segments#join_a_client_to_a_segment).
Here are some examples of using `-retry-join`:
<CodeBlockConfig heading="Using a DNS entry">
```shell-session
$ consul agent -retry-join "consul.domain.internal"
```
</CodeBlockConfig>
<CodeBlockConfig heading="Using IPv4">
```shell-session
$ consul agent -retry-join "10.0.4.67"
```
</CodeBlockConfig>
<CodeBlockConfig heading="Using a non-default Serf LAN port">
$ consul agent -retry-join "provider=aws tag_key=..."
```
</CodeBlockConfig>
- `-retry-interval` ((#\_retry_interval)) - Time to wait between join attempts.
Defaults to 30s.
- `-retry-max` ((#\_retry_max)) - The maximum number of [`-join`](#_join)
attempts to be made before exiting with return code 1. By default, this is set
to 0 which is interpreted as infinite retries.
- `-join-wan` ((#\_join_wan)) - Address of another wan agent to join upon
starting up. This can be specified multiple times to specify multiple WAN agents
to join. If Consul is unable to join with any of the specified addresses, agent
startup will fail. By default, the agent won't [`-join-wan`](#_join_wan) any nodes
when it starts up.
In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
template that is resolved at runtime.
- `-retry-join-wan` ((#\_retry_join_wan)) - Similar to [`retry-join`](#_retry_join)
but allows retrying a wan join if the first attempt fails. This is useful for cases
where we know the address will become available eventually. As of Consul 0.9.3
[Cloud Auto-Joining](#cloud-auto-joining) is supported as well.
In Consul 1.1.0 and later this can be dynamically defined with a [go-sockaddr]
template that is resolved at runtime.
- `-retry-interval-wan` ((#\_retry_interval_wan)) - Time to wait between
[`-join-wan`](#_join_wan) attempts. Defaults to 30s.
- `-retry-max-wan` ((#\_retry_max_wan)) - The maximum number of [`-join-wan`](#_join_wan)
attempts to be made before exiting with return code 1. By default, this is set
to 0 which is interpreted as infinite retries.
- `-log-level` ((#\_log_level)) - The level of logging to show after the
Consul agent has started. This defaults to "info". The available log levels are
"trace", "debug", "info", "warn", and "err". You can always connect to an agent
via [`consul monitor`](/commands/monitor) and use any log level. Also,
the log level can be changed during a config reload.
- `-log-json` ((#\_log_json)) - This flag enables the agent to output logs
in a JSON format. By default this is false.
- `-node` ((#\_node)) - The name of this node in the cluster. This must
be unique within the cluster. By default this is the hostname of the machine.
- `-node-id` ((#\_node_id)) - Available in Consul 0.7.3 and later, this
is a unique identifier for this node across all time, even if the name of the node
or address changes. This must be in the form of a hex string, 36 characters long,
such as `adf4238a-882b-9ddc-4a9d-5b6758e4159e`. If this isn't supplied, which is
the most common case, then the agent will generate an identifier at startup and
persist it in the [data directory](#_data_dir) so that it will remain the same
across agent restarts. Information from the host will be used to generate a deterministic
node ID if possible, unless [`-disable-host-node-id`](#_disable_host_node_id) is
set to true.
- `-node-meta` ((#\_node_meta)) - Available in Consul 0.7.3 and later, this
specifies an arbitrary metadata key/value pair to associate with the node, of the
form `key:value`. This can be specified multiple times. Node metadata pairs have
the following restrictions:
- A maximum of 64 key/value pairs can be registered per node.
- Metadata keys must be between 1 and 128 characters (inclusive) in length
- Metadata keys must contain only alphanumeric, `-`, and `_` characters.
- Metadata keys must not begin with the `consul-` prefix; that is reserved for internal use by Consul.
- Metadata values must be between 0 and 512 (inclusive) characters in length.
- Metadata values for keys beginning with `rfc1035-` are encoded verbatim in DNS TXT requests, otherwise
the metadata kv-pair is encoded according [RFC1464](https://www.ietf.org/rfc/rfc1464.txt).
- `-pid-file` ((#\_pid_file)) - This flag provides the file path for the
agent to store its PID. This is useful for sending signals (for example, `SIGINT`
to close the agent or `SIGHUP` to update check definitions) to the agent.
- `-protocol` ((#\_protocol)) - The Consul protocol version to use. Consul
agents speak protocol 2 by default, however agents will automatically use protocol > 2 when speaking to compatible agents. This should be set only when [upgrading](/docs/upgrading). You can view the protocol versions supported by Consul by running `consul -v`.
- `-primary-gateway` ((#\_primary_gateway)) - Similar to [`retry-join-wan`](#_retry_join_wan)
but allows retrying discovery of fallback addresses for the mesh gateways in the
primary datacenter if the first attempt fails. This is useful for cases where we
know the address will become available eventually. [Cloud Auto-Joining](#cloud-auto-joining)
is supported as well as [go-sockaddr]
templates. This was added in Consul 1.8.0.
- `-raft-protocol` ((#\_raft_protocol)) - This controls the internal version
of the Raft consensus protocol used for server communications. This must be set
to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for more details.
- `-recursor` ((#\_recursor)) - Specifies the address of an upstream DNS
server. This option may be provided multiple times, and is functionally equivalent
to the [`recursors` configuration option](#recursors).
- `-rejoin` ((#\_rejoin)) - When provided, Consul will ignore a previous
leave and attempt to rejoin the cluster when starting. By default, Consul treats
leave as a permanent intent and does not attempt to join the cluster again when
starting. This flag allows the previous state to be used to rejoin the cluster.
- `-segment` ((#\_segment)) <EnterpriseAlert inline /> - This flag is used to set
the name of the network segment the agent belongs to. An agent can only join and
communicate with other agents within its network segment. Ensure the [join
operation uses the correct port for this segment](/docs/enterprise/network-segments#join_a_client_to_a_segment).
Review the [Network Segments documentation](/docs/enterprise/network-segments)
for more details. By default, this is an empty string, which is the `<default>`
network segment.
~> **Warning:** The `segment` flag cannot be used with the [`partition`](#partition-1) option.
- `-serf-lan-allowed-cidrs` ((#\_serf_lan_allowed_cidrs)) - The Serf LAN allowed CIDRs allow to accept incoming
connections for Serf only from several networks (multiple values are supported).
Those networks are specified with CIDR notation (eg: 192.168.1.0/24).
This is available in Consul 1.8 and later.
- `-serf-lan-port` ((#\_serf_lan_port)) - the Serf LAN port to listen on.
This overrides the default Serf LAN port 8301. This is available in Consul 1.2.2
and later.
- `-serf-wan-allowed-cidrs` ((#\_serf_wan_allowed_cidrs)) - The Serf WAN allowed CIDRs allow to accept incoming
connections for Serf only from several networks (multiple values are supported).
Those networks are specified with CIDR notation (eg: 192.168.1.0/24).
This is available in Consul 1.8 and later.
- `-serf-wan-port` ((#\_serf_wan_port)) - the Serf WAN port to listen on.
This overrides the default Serf WAN port 8302. This is available in Consul 1.2.2
and later.
- `-server` ((#\_server)) - This flag is used to control if an agent is
in server or client mode. When provided, an agent will act as a Consul server.
Each Consul cluster must have at least one server and ideally no more than 5 per
datacenter. All servers participate in the Raft consensus algorithm to ensure that
transactions occur in a consistent, linearizable manner. Transactions modify cluster
state, which is maintained on all server nodes to ensure availability in the case
of node failure. Server nodes also participate in a WAN gossip pool with server
nodes in other datacenters. Servers act as gateways to other datacenters and forward
traffic as appropriate.
- `-server-port` ((#\_server_port)) - the server RPC port to listen on.
This overrides the default server RPC port 8300. This is available in Consul 1.2.2
and later.
- `-non-voting-server` ((#\_non_voting_server)) <EnterpriseAlert inline /> - **This field
is deprecated in Consul 1.9.1. See the [`-read-replica`](#_read_replica) flag instead.**
- `-read-replica` ((#\_read_replica)) <EnterpriseAlert inline /> - This
flag is used to make the server not participate in the Raft quorum, and have it
only receive the data replication stream. This can be used to add read scalability
to a cluster in cases where a high volume of reads to servers are needed.
- `-syslog` ((#\_syslog)) - This flag enables logging to syslog. This is
only supported on Linux and OSX. It will result in an error if provided on Windows.
- `-ui` ((#\_ui)) - Enables the built-in web UI server and the required
HTTP routes. This eliminates the need to maintain the Consul web UI files separately
from the binary.
- `-ui-dir` ((#\_ui_dir)) - This flag provides the directory containing
the Web UI resources for Consul. This will automatically enable the Web UI. The
directory must be readable to the agent. Starting with Consul version 0.7.0 and
later, the Web UI assets are included in the binary so this flag is no longer necessary;
specifying only the `-ui` flag is enough to enable the Web UI. Specifying both
the '-ui' and '-ui-dir' flags will result in an error.
<!-- prettier-ignore -->
- `-ui-content-path` ((#\_ui\_content\_path)) - This flag provides the option
to change the path the Consul UI loads from and will be displayed in the browser.
By default, the path is `/ui/`, for example `http://localhost:8500/ui/`. Only alphanumerics,
`-`, and `_` are allowed in a custom path.`/v1/` is not allowed as it would overwrite
the API endpoint.
## Configuration Files ((#configuration_files))
In addition to the command-line options, configuration for the Consul agent can be put into
files. This may be easier in certain situations, for example when Consul is
being configured using a configuration management system.
The configuration files are formatted as HCL, or JSON. JSON formatted configs are easily readable
and editable by both humans and computers. JSON formatted configuration consists
of a single JSON object with multiple configuration keys specified within it.
operations. This token is required for servers outside the [`primary_datacenter`](#primary_datacenter) when ACLs are enabled. This token may be provided later using the [agent token API](/api-docs/agent#update-acl-tokens) on each server. This token must have at least "read" permissions on ACL data but if ACL token replication is enabled then it must have "write" permissions. This also enables Connect replication, for which the token will require both operator "write" and intention "read" permissions for replicating CA and Intention data.
- `acl_datacenter` - **This field is deprecated in Consul 1.4.0. See the [`primary_datacenter`](#primary_datacenter) field instead.**
This designates the datacenter which is authoritative for ACL information. It must be provided to enable ACLs. All servers and datacenters must agree on the ACL datacenter. Setting it on the servers is all you need for cluster-level enforcement, but for the APIs to forward properly from the clients,
it must be set on them too. In Consul 0.8 and later, this also enables agent-level enforcement
of ACLs. Please review the [ACL tutorial](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production) for more details.
- `acl_default_policy` ((#acl_default_policy_legacy)) - **Deprecated in Consul 1.4.0. See the [`acl.default_policy`](#acl_default_policy) field instead.**
Either "allow" or "deny"; defaults to "allow". The default policy controls the
behavior of a token when there is no matching rule. In "allow" mode, ACLs are a
denylist: any operation not specifically prohibited is allowed. In "deny" mode,
ACLs are an allowlist: any operation not specifically allowed is blocked. **Note**:
this will not take effect until you've set `primary_datacenter` to enable ACL support.
- `acl_down_policy` ((#acl_down_policy_legacy)) - **Deprecated in Consul
1.4.0. See the [`acl.down_policy`](#acl_down_policy) field instead.** Either "allow",
"deny", "extend-cache" or "async-cache"; "extend-cache" is the default. In the
case that the policy for a token cannot be read from the [`primary_datacenter`](#primary_datacenter)
or leader node, the down policy is applied. In "allow" mode, all actions are permitted,
"deny" restricts all operations, and "extend-cache" allows any cached ACLs to be
used, ignoring their TTL values. If a non-cached ACL is used, "extend-cache" acts
like "deny". The value "async-cache" acts the same way as "extend-cache" but performs
updates asynchronously when ACL is present but its TTL is expired, thus, if latency
is bad between ACL authoritative and other datacenters, latency of operations is
in Consul 1.4.0. See the [`acl.tokens.replication`](#acl_tokens_replication) field
instead.** Only used for servers outside the [`primary_datacenter`](#primary_datacenter)
running Consul 0.7 or later. When provided, this will enable [ACL replication](https://learn.hashicorp.com/tutorials/consul/access-control-replication-multiple-datacenters)
using this ACL replication using this token to retrieve and replicate the ACLs
to the non-authoritative local datacenter. In Consul 0.9.1 and later you can enable
ACL replication using [`acl.enable_token_replication`](#acl_enable_token_replication) and then
on each server. If the `acl_replication_token` is set in the config, it will automatically
set [`acl.enable_token_replication`](#acl_enable_token_replication) to true for backward compatibility.
If there's a partition or other outage affecting the authoritative datacenter, and the
[`acl_down_policy`](/docs/agent/options#acl_down_policy) is set to "extend-cache", tokens not
in the cache can be resolved during the outage using the replicated set of ACLs.
- `acl_token` ((#acl_token_legacy)) - **Deprecated in Consul 1.4.0. See
the [`acl.tokens.default`](#acl_tokens_default) field instead.** When provided,
the agent will use this token when making requests to the Consul servers. Clients
can override this token on a per-request basis by providing the "?token" query
parameter. When not provided, the empty token, which maps to the 'anonymous' ACL
policy, is used.
- `acl_ttl` ((#acl_ttl_legacy)) - **Deprecated in Consul 1.4.0. See the
[`acl.token_ttl`](#acl_token_ttl) field instead.**Used to control Time-To-Live
caching of ACLs. By default, this is 30 seconds. This setting has a major performance
impact: reducing it will cause more frequent refreshes while increasing it reduces
the number of refreshes. However, because the caches are not actively invalidated,
ACL policy may be stale up to the TTL value.
- `addresses` - This is a nested object that allows setting
bind addresses. In Consul 1.0 and later these can be set to a space-separated list
of addresses to bind to, or a [go-sockaddr] template that can potentially resolve to multiple addresses.
`http`, `https` and `grpc` all support binding to a Unix domain socket. A
socket can be specified in the form `unix:///path/to/socket`. A new domain
socket will be created at the given path. If the specified file path already
exists, Consul will attempt to clear the file and create the domain socket
in its place. The permissions of the socket file are tunable via the
[`unix_sockets` config construct](#unix_sockets).
When running Consul agent commands against Unix socket interfaces, use the
`-http-addr` argument to specify the path to the socket. You can also place
the desired values in the `CONSUL_HTTP_ADDR` environment variable.
For TCP addresses, the environment variable value should be an IP address
_with the port_. For example: `10.0.0.1:8500` and not `10.0.0.1`. However,
ports are set separately in the [`ports`](#ports) structure when
defining them in a configuration file.
The following keys are valid:
- `dns` - The DNS server. Defaults to `client_addr`
- `http` - The HTTP API. Defaults to `client_addr`
- `https` - The HTTPS API. Defaults to `client_addr`
- `grpc` - The gRPC API. Defaults to `client_addr`
- `advertise_addr` Equivalent to the [`-advertise` command-line flag](#_advertise).
- `advertise_addr_ipv4` This was added together with [`advertise_addr_ipv6`](#advertise_addr_ipv6) to support dual stack IPv4/IPv6 environments. Using this, both IPv4 and IPv6 addresses can be specified and requested during eg service discovery.
- `advertise_addr_ipv6` This was added together with [`advertise_addr_ipv4`](#advertise_addr_ipv4) to support dual stack IPv4/IPv6 environments. Using this, both IPv4 and IPv6 addresses can be specified and requested during eg service discovery.
- `advertise_addr_wan` Equivalent to the [`-advertise-wan` command-line flag](#_advertise-wan).
- `advertise_addr_wan_ipv4` This was added together with [`advertise_addr_wan_ipv6`](#advertise_addr_wan_ipv6) to support dual stack IPv4/IPv6 environments. Using this, both IPv4 and IPv6 addresses can be specified and requested during eg service discovery.
- `advertise_addr_wan_ipv6` This was added together with [`advertise_addr_wan_ipv4`](#advertise_addr_wan_ipv4) to support dual stack IPv4/IPv6 environments. Using this, both IPv4 and IPv6 addresses can be specified and requested during eg service discovery.
- `advertise_reconnect_timeout` This is a per-agent setting of the [`reconnect_timeout`](#reconnect_timeout) parameter.
This agent will advertise to all other nodes in the cluster that after this timeout, the node may be completely
removed from the cluster. This may only be set on client agents and if unset then other nodes will use the main
`reconnect_timeout` setting when determining when this node may be removed from the cluster.
- `alt_domain` Equivalent to the [`-alt-domain` command-line flag](#_alt_domain)
- `serf_lan` ((#serf_lan_bind)) Equivalent to the [`-serf-lan-bind` command-line flag](#_serf_lan_bind).
This is an IP address, not to be confused with [`ports.serf_lan`](#serf_lan_port).
- `serf_lan_allowed_cidrs` ((#serf_lan_allowed_cidrs)) Equivalent to the [`-serf-lan-allowed-cidrs` command-line flag](#_serf_lan_allowed_cidrs).
- `serf_wan` ((#serf_wan_bind)) Equivalent to the [`-serf-wan-bind` command-line flag](#_serf_wan_bind).
- `serf_wan_allowed_cidrs` ((#serf_wan_allowed_cidrs)) Equivalent to the [`-serf-wan-allowed-cidrs` command-line flag](#_serf_wan_allowed_cidrs).
- `audit` <EnterpriseAlert inline /> - Added in Consul 1.8, the audit object allow users to enable auditing
and configure a sink and filters for their audit logs. For more information, review the [audit log tutorial](https://learn.hashicorp.com/tutorials/consul/audit-logging).
<CodeTabs heading="Example audit configuration">
```hcl
audit {
enabled = true
sink "My sink" {
type = "file"
format = "json"
path = "data/audit/audit.json"
delivery_guarantee = "best-effort"
rotate_duration = "24h"
rotate_max_files = 15
rotate_bytes = 25165824
}
}
```
```json
{
"audit": {
"enabled": true,
"sink": {
"My sink": {
"type": "file",
"format": "json",
"path": "data/audit/audit.json",
"delivery_guarantee": "best-effort",
"rotate_duration": "24h",
"rotate_max_files": 15,
"rotate_bytes": 25165824
}
}
}
}
```
</CodeTabs>
The following sub-keys are available:
- `enabled` - Controls whether Consul logs out each time a user
performs an operation. ACLs must be enabled to use this feature. Defaults to `false`.
- `sink` - This object provides configuration for the destination to which
Consul will log auditing events. Sink is an object containing keys to sink objects, where the key is the name of the sink.
- `type` - Type specifies what kind of sink this is.
The following keys are valid:
- `file` - Currently only file sinks are available, they take the following keys.
- `format` - Format specifies what format the events will
be emitted with.
The following keys are valid:
- `json` - Currently only json events are offered.
- `path` - The directory and filename to write audit events to.
- `delivery_guarantee` - Specifies
the rules governing how audit events are written.
The following keys are valid:
- `best-effort` - Consul only supports `best-effort` event delivery.
- `mode` - The permissions to set on the audit log files.
- `rotate_duration` - Specifies the
interval by which the system rotates to a new log file. At least one of `rotate_duration` or `rotate_bytes`
must be configured to enable audit logging.
- `rotate_max_files` - Defines the
limit that Consul should follow before it deletes old log files.
- `rotate_bytes` - Specifies how large an
individual log file can grow before Consul rotates to a new file. At least one of `rotate_bytes` or
`rotate_duration` must be configured to enable audit logging.
- `autopilot` Added in Consul 0.8, this object allows a
number of sub-keys to be set which can configure operator-friendly settings for
Consul servers. When these keys are provided as configuration, they will only be
respected on bootstrapping. If they are not provided, the defaults will be used.
In order to change the value of these options after bootstrapping, you will need
to use the [Consul Operator Autopilot](/commands/operator/autopilot)
command. For more information about Autopilot, review the [Autopilot tutorial](https://learn.hashicorp.com/tutorials/consul/autopilot-datacenter-operations).
The following sub-keys are available:
- `cleanup_dead_servers` - This controls the
automatic removal of dead server nodes periodically and whenever a new server
is added to the cluster. Defaults to `true`.
- `last_contact_threshold` - Controls the
maximum amount of time a server can go without contact from the leader before
being considered unhealthy. Must be a duration value such as `10s`. Defaults
to `200ms`.
- `max_trailing_logs` - Controls the maximum number
of log entries that a server can trail the leader by before being considered
unhealthy. Defaults to 250.
- `min_quorum` - Sets the minimum number of servers necessary
in a cluster. Autopilot will stop pruning dead servers when this minimum is reached. There is no default.
- `datacenter` Equivalent to the [`-datacenter` command-line flag](#_datacenter).
- `data_dir` Equivalent to the [`-data-dir` command-line flag](#_data_dir).
- `disable_anonymous_signature` Disables providing an anonymous
signature for de-duplication with the update check. See [`disable_update_check`](#disable_update_check).
- `disable_host_node_id` Equivalent to the [`-disable-host-node-id` command-line flag](#_disable_host_node_id).
- `disable_http_unprintable_char_filter` Defaults to false. Consul 1.0.3 fixed a potential security vulnerability where malicious users could craft KV keys with unprintable chars that would confuse operators using the CLI or UI into taking wrong actions. Users who had data written in older versions of Consul that did not have this restriction will be unable to delete those values by default in 1.0.3 or later. This setting enables those users to **temporarily** disable the filter such that delete operations can work on those keys again to get back to a healthy state. It is strongly recommended that this filter is not disabled permanently as it exposes the original security vulnerability.
- `disable_remote_exec` Disables support for remote execution. When set to true, the agent will ignore
any incoming remote exec requests. In versions of Consul prior to 0.8, this defaulted
to false. In Consul 0.8 the default was changed to true, to make remote exec opt-in
instead of opt-out.
- `disable_update_check` Disables automatic checking for security bulletins and new version releases. This is disabled in Consul Enterprise.
- `discard_check_output` Discards the output of health checks before storing them. This reduces the number of writes to the Consul raft log in environments where health checks have volatile output like timestamps, process ids, ...
- `discovery_max_stale` - Enables stale requests for all service discovery HTTP endpoints. This is
equivalent to the [`max_stale`](#max_stale) configuration for DNS requests. If this value is zero (default), all service discovery HTTP endpoints are forwarded to the leader. If this value is greater than zero, any Consul server can handle the service discovery request. If a Consul server is behind the leader by more than `discovery_max_stale`, the query will be re-evaluated on the leader to get more up-to-date results. Consul agents also add a new `X-Consul-Effective-Consistency` response header which indicates if the agent did a stale read. `discover-max-stale` was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests from clients at the agent level, and defaults to zero which matches default consistency behavior in earlier Consul versions.
to be set which can tune how DNS queries are serviced. Check the tutorial on [DNS caching](https://learn.hashicorp.com/tutorials/consul/dns-caching) for more detail.
- `enable_additional_node_meta_txt` - When set to true, Consul
will add TXT records for Node metadata into the Additional section of the DNS responses for several query types such as SRV queries. When set to false those records are not emitted. This does not impact the behavior of those same TXT records when they would be added to the Answer section of the response like when querying with type TXT or ANY. This defaults to true.
- `soa` Allow to tune the setting set up in SOA. Non specified
- `enable_agent_tls_for_checks` When set, uses a subset of the agent's TLS configuration (`key_file`,
`cert_file`, `ca_file`, `ca_path`, and `server_name`) to set up the client for HTTP or gRPC health checks. This allows services requiring 2-way TLS to be checked using the agent's credentials. This was added in Consul 1.0.1 and defaults to false.
- `enable_central_service_config` When set, the Consul agent will look for any
[centralized service configuration](/docs/agent/config-entries)
that match a registering service instance. If it finds any, the agent will merge the centralized defaults with the service instance configuration. This allows for things like service protocol or proxy configuration to be defined centrally and inherited by any affected service registrations.
This defaults to `false` in versions of Consul prior to 1.9.0, and defaults to `true` in Consul 1.9.0 and later.
ACLs must be enabled for agents and the `enable_script_checks` option must be set to `true` to enable script checks in Consul 0.9.0 and later. See [Registering and Querying Node Information](/docs/security/acl/acl-rules#registering-and-querying-node-information) for related information.
~> **Security Warning:** Enabling script checks in some configurations may introduce a known remote execution vulnerability targeted by malware. We strongly recommend `enable_local_script_checks` instead. Refer to the following article for additional guidance: [_Protecting Consul from RCE Risk in Specific Configurations_](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
for more details.
- `enable_local_script_checks` Equivalent to the [`-enable-local-script-checks` command-line flag](#_enable_local_script_checks).
- `enable_syslog` Equivalent to the [`-syslog` command-line flag](#_syslog).
should be used, but this option is useful for removing access to HTTP API endpoints
completely, or on specific agents. This is available in Consul 0.9.0 and later.
- `response_headers` This object allows adding headers to the HTTP API and UI responses. For example, the following config can be used to enable [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) on the HTTP API endpoints:
<CodeTabs heading="Enable CORS on the HTTP API endpoints">
```hcl
http_config {
response_headers {
Access-Control-Allow-Origin = "*"
}
}
```
```json
{
"http_config": {
"response_headers": {
"Access-Control-Allow-Origin": "*"
}
}
}
```
</CodeTabs>
- `allow_write_http_from` This object is a list of networks in CIDR notation (eg "127.0.0.0/8") that are allowed to call the agent write endpoints. It defaults to an empty list, which means all networks are allowed. This is used to make the agent read-only, except for select ip ranges. - To block write calls from anywhere, use `[ "255.255.255.255/32" ]`. - To only allow write calls from localhost, use `[ "127.0.0.0/8" ]` - To only allow specific IPs, use `[ "10.0.0.1/32", "10.0.0.2/32" ]`
- `use_cache` ((#http_config_use_cache)) Defaults to true. If disabled, the agent won't be using [agent caching](/api-docs/features/caching) to answer the request. Even when the url parameter is provided.
- `max_header_bytes` This setting controls the maximum number of bytes the consul http server will read parsing the request header's keys and values, including the request line. It does not limit the size of the request body. If zero, or negative, http.DefaultMaxHeaderBytes is used, which equates to 1 Megabyte.
- `leave_on_terminate` If enabled, when the agent receives a TERM signal, it will send a `Leave` message to the rest of the cluster and gracefully leave. The default behavior for this feature varies based on whether or not the agent is running as a client or a server (prior to Consul 0.7 the default value was unconditionally set to `false`). On agents in client-mode, this defaults to `true` and for agents in server-mode, this defaults to `false`.
- `license_path` <EnterpriseAlert inline /> This specifies the path to a file that contains the Consul Enterprise license. Alternatively the license may also be specified in either the `CONSUL_LICENSE` or `CONSUL_LICENSE_PATH` environment variables. See the [licensing documentation](/docs/enterprise/license/overview) for more information about Consul Enterprise license management. Added in versions 1.10.0, 1.9.7 and 1.8.13. Prior to version 1.10.0 the value may be set for all agents to facilitate forwards compatibility with 1.10 but will only actually be used by client agents.
- `limits` Available in Consul 0.9.3 and later, this is a nested
object that configures limits that are enforced by the agent. Prior to Consul 1.5.2,
this only applied to agents in client mode, not Consul servers. The following parameters
are available:
- `http_max_conns_per_client` - Configures a limit of how many concurrent TCP connections a single client IP address is allowed to open to the agent's HTTP(S) server. This affects the HTTP(S) servers in both client and server agents. Default value is `200`.
- `https_handshake_timeout` - Configures the limit for how long the HTTPS server in both client and server agents will wait for a client to complete a TLS handshake. This should be kept conservative as it limits how many connections an unauthenticated attacker can open if `verify_incoming` is being using to authenticate clients (strongly recommended in production). Default value is `5s`.
- `rpc_handshake_timeout` - Configures the limit for how long servers will wait after a client TCP connection is established before they complete the connection handshake. When TLS is used, the same timeout applies to the TLS handshake separately from the initial protocol negotiation. All Consul clients should perform this immediately on establishing a new connection. This should be kept conservative as it limits how many connections an unauthenticated attacker can open if `verify_incoming` is being using to authenticate clients (strongly recommended in production). When `verify_incoming` is true on servers, this limits how long the connection socket and associated goroutines will be held open before the client successfully authenticates. Default value is `5s`.
- `rpc_max_conns_per_client` - Configures a limit of how many concurrent TCP connections a single source IP address is allowed to open to a single server. It affects both clients connections and other server connections. In general Consul clients multiplex many RPC calls over a single TCP connection so this can typically be kept low. It needs to be more than one though since servers open at least one additional connection for raft RPC, possibly more for WAN federation when using network areas, and snapshot requests from clients run over a separate TCP conn. A reasonably low limit significantly reduces the ability of an unauthenticated attacker to consume unbounded resources by holding open many connections. You may need to increase this if WAN federated servers connect via proxies or NAT gateways or similar causing many legitimate connections from a single source IP. Default value is `100` which is designed to be extremely conservative to limit issues with certain deployment patterns. Most deployments can probably reduce this safely. 100 connections on modern server hardware should not cause a significant impact on resource usage from an unauthenticated attacker though.
- `rpc_rate` - Configures the RPC rate limiter on Consul _clients_ by setting the maximum request rate that this agent is allowed to make for RPC requests to Consul servers, in requests per second. Defaults to infinite, which disables rate limiting.
- `rpc_max_burst` - The size of the token bucket used to recharge the RPC rate limiter on Consul _clients_. Defaults to 1000 tokens, and each token is good for a single RPC call to a Consul server. See https://en.wikipedia.org/wiki/Token_bucket for more details about how token bucket rate limiters operate.
- `kv_max_value_size` - **(Advanced)** Configures the maximum number of bytes for a kv request body to the [`/v1/kv`](/api-docs/kv) endpoint. This limit defaults to [raft's](https://github.com/hashicorp/raft) suggested max size (512KB). **Note that tuning these improperly can cause Consul to fail in unexpected ways**, it may potentially affect leadership stability and prevent timely heartbeat signals by increasing RPC IO duration. This option affects the txn endpoint too, but Consul 1.7.2 introduced `txn_max_req_len` which is the preferred way to set the limit for the txn endpoint. If both limits are set, the higher one takes precedence.
- `txn_max_req_len` - **(Advanced)** Configures the maximum number of bytes for a transaction request body to the [`/v1/txn`](/api-docs/txn) endpoint. This limit defaults to [raft's](https://github.com/hashicorp/raft) suggested max size (512KB). **Note that tuning these improperly can cause Consul to fail in unexpected ways**, it may potentially affect leadership stability and prevent timely heartbeat signals by increasing RPC IO duration.
- `node_meta` Available in Consul 0.7.3 and later, This object allows associating arbitrary metadata key/value pairs with the local node, which can then be used for filtering results from certain catalog endpoints. See the [`-node-meta` command-line flag](#_node_meta) for more information.
- `performance` Available in Consul 0.7 and later, this is a nested object that allows tuning the performance of different subsystems in Consul. See the [Server Performance](/docs/install/performance) documentation for more details. The following parameters are available:
- `leave_drain_time` - A duration that a server will dwell during a graceful leave in order to allow requests to be retried against other Consul servers. Under normal circumstances, this can prevent clients from experiencing "no leader" errors when performing a rolling update of the Consul servers. This was added in Consul 1.0. Must be a duration value such as 10s. Defaults to 5s.
- `raft_multiplier` - An integer multiplier used by Consul servers to scale key Raft timing parameters. Omitting this value or setting it to 0 uses default timing described below. Lower values are used to tighten timing and increase sensitivity while higher values relax timings and reduce sensitivity. Tuning this affects the time it takes Consul to detect leader failures and to perform leader elections, at the expense of requiring more network and CPU resources for better performance.
- `reap` This controls Consul's automatic reaping of child processes,
which is useful if Consul is running as PID 1 in a Docker container. If this isn't
specified, then Consul will automatically reap child processes if it detects it
is running as PID 1. If this is set to true or false, then it controls reaping
regardless of Consul's PID (forces reaping on or off, respectively). This option
was removed in Consul 0.7.1. For later versions of Consul, you will need to reap
processes using a wrapper, please see the [Consul Docker image entry point script](https://github.com/hashicorp/docker-consul/blob/master/0.X/docker-entrypoint.sh)
for an example. If you are using Docker 1.13.0 or later, you can use the new `--init`
option of the `docker run` command and docker will enable an init process with
PID 1 that reaps child processes for the container. More info on [Docker docs](https://docs.docker.com/engine/reference/commandline/run/#options).
- `reconnect_timeout` This controls how long it
takes for a failed node to be completely removed from the cluster. This defaults
to 72 hours and it is recommended that this is set to at least double the maximum
expected recoverable outage time for a node or network partition. WARNING: Setting
this time too low could cause Consul servers to be removed from quorum during an
extended node failure or partition, which could complicate recovery of the cluster.
The value is a time with a unit suffix, which can be "s", "m", "h" for seconds,
minutes, or hours. The value must be >= 8 hours.
- `reconnect_timeout_wan` This is the WAN equivalent
of the [`reconnect_timeout`](#reconnect_timeout) parameter, which controls
how long it takes for a failed server to be completely removed from the WAN pool.
This also defaults to 72 hours, and must be >= 8 hours.
- `recursors` This flag provides addresses of upstream DNS
servers that are used to recursively resolve queries if they are not inside the
service domain for Consul. For example, a node can use Consul directly as a DNS
server, and if the record is outside of the "consul." domain, the query will be
resolved upstream. As of Consul 1.0.1 recursors can be provided as IP addresses
or as go-sockaddr templates. IP addresses are resolved in order, and duplicates
are ignored.
- `rejoin_after_leave` Equivalent to the [`-rejoin` command-line flag](#_rejoin).
- `retry_join` - Equivalent to the [`-retry-join`](#retry-join) command-line flag.
- `retry_interval` Equivalent to the [`-retry-interval` command-line flag](#_retry_interval).
- `retry_join_wan` Equivalent to the [`-retry-join-wan` command-line flag](#_retry_join_wan). Takes a list of addresses to attempt joining to WAN every [`retry_interval_wan`](#_retry_interval_wan) until at least one join works.
- `retry_interval_wan` Equivalent to the [`-retry-interval-wan` command-line flag](#_retry_interval_wan).
- `rpc` configuration for Consul servers.
- `enable_streaming` ((#rpc_enable_streaming)) defaults to true. If set to false it will disable
the gRPC subscribe endpoint on a Consul Server. All
servers in all federated datacenters must have this enabled before any client can use
- `circonus_submission_interval` ((#telemetry-circonus_submission_interval)) The interval at which metrics are submitted to Circonus. By default, this is set to "10s" (ten seconds).
- `circonus_check_force_metric_activation` ((#telemetry-circonus_check_force_metric_activation)) Force activation of metrics which already exist and are not currently active.
- `circonus_check_instance_id` ((#telemetry-circonus_check_instance_id)) Uniquely identifies the metrics coming from this **instance**. It can be used to
- `circonus_check_display_name` ((#telemetry-circonus_check_display_name)) Specifies a name to give a check when it is created. This name is displayed in
This allows users to disable metrics deprecated in 1.9 so they are no longer emitted, saving on performance and storage in large deployments. Defaults to false.
A leading "**+**" will enable any metrics with the given prefix, and a leading "**-**" will block them. If there is overlap between two rules, the more specific rule will take precedence. Blocking will take priority if the same prefix is listed multiple times.
- `prometheus_retention_time` ((#telemetry-prometheus_retention_time)) If the value is greater than `0s` (the default), this enables [Prometheus](https://prometheus.io/)
- These can be important in certain outage situations so being able to control
them without a restart provides a recovery path that doesn't involve
downtime. They generally shouldn't be changed otherwise.
- [RPC rate limiting](#limits)
- [HTTP Maximum Connections per Client](#http_max_conns_per_client)
- Services
- TLS Configuration
- Please be aware that this is currently limited to reload a configuration that is already TLS enabled. You cannot enable or disable TLS only with reloading.
