---
layout: docs
page_title: Agents - CLI Reference
description: >-
  Add flags to the `consul agent` command to configure agent properties and actions from the CLI. Learn about configurable options and how to format them with examples.
---

# Agents Command-line Reference ((#commandline_options))

-> **Note:** Some CLI arguments may be different from HCL keys. See [Configuration Key Reference](/consul/docs/agent/config/config-files#config_key_reference) for equivalent HCL Keys.

This topic describes the available command-line options for the Consul agent.

## Usage

See [Agent Overview](/consul/docs/agent#starting-the-consul-agent) for examples of how to use flags with the `consul agent` CLI.

## Environment Variables

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](/consul/commands#environment-variables) for more
information.

## General

- `-auto-reload-config` ((#\_auto_reload_config)) - This option directs Consul to automatically reload the [reloadable configuration options](/consul/docs/agent/config#reloadable-configuration) when configuration files change.
  Consul also watches the certificate and key files specified with the `cert_file` and `key_file` parameters and reloads the configuration if the files are updated.

- `-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`](/consul/docs/agent/config/config-files#discard_check_output).

- `-client` ((#\_client)) - The address to which Consul will bind client
  interfaces, including the HTTP 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">

  ```shell
  $ consul agent -dev -client '{{ GetPrivateInterfaces | exclude "type" "ipv6" | join "address" " " }}'
  ```

  </CodeBlockConfig>

  <CodeBlockConfig hideClipboard heading="Bind consul client interfaces to private IP addresses and loopback">

  ```shell
  $ consul agent -dev -client '{{ GetPrivateInterfaces | join "address" " " }} {{ GetAllInterfaces | include "flags" "loopback" | join "address" " " }}'
  ```

  </CodeBlockConfig>

  <CodeBlockConfig hideClipboard heading="Exclude private interfaces that start with 'br-'">

  ```shell
  $ consul agent -dev -client '{{ GetPrivateInterfaces | exclude "name" "br.*" | join "address" " " }}'
  ```

  </CodeBlockConfig>

- `-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, [service mesh is enabled](/consul/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-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.

- `-enable-script-checks` ((#\_enable_script_checks)) This controls whether
  [health checks that execute scripts](/consul/docs/services/usage/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)
  for more details.

- `-enable-local-script-checks` ((#\_enable_local_script_checks))
  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`](/consul/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](/consul/docs/agent/config#ports-used) 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](/consul/docs/agent/config#ports-used) documentation for more detail.

- `-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.

- `-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](/consul/docs/upgrading). You can view the protocol versions supported by Consul by running `consul version`.

- `-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`](/consul/docs/agent/config/config-files#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/consul/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for more details.

- `-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](/consul/docs/enterprise/network-segments/create-network-segment#configure-clients-to-join-segments).
  Review the [Network Segments documentation](/consul/docs/enterprise/network-segments/create-network-segment)
  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`](/consul/docs/agent/config/config-files#partition-1) option.

## Advertise Address Options

- `-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`](/consul/docs/agent/config/config-files#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`](/consul/docs/agent/config/config-files#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.

## Address Bind Options

- `-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](#_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](#_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.

## Bootstrap Options

- `-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.

## Configuration File Options

- `-config-file` ((#\_config_file)) - A configuration file to load. For
  more information on the format of this file, read the [Configuration Files](/consul/docs/agent/config/config-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 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](/consul/docs/agent/config/config-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.

## DNS and Domain Options

- `-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.

- `-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](/consul/docs/agent/config/config-files#recursors).

- `-join` ((#\_join)) - **Deprecated in Consul 1.15. This flag will be removed in a future version of Consul. Use the `-retry-join` flag instead.**
  This is an alias of [`-retry-join`](#_retry_join).

- `-retry-join` ((#\_retry_join)) - Address of another agent to join upon starting up. Joining is
  retried until success. Once the agent joins successfully as a member, it will not attempt to join
  again. After joining, the agent solely maintains its membership via gossip. This option can be
  specified multiple times to specify multiple agents to join. By default, the agent won't join any
  nodes when it starts up. The value can contain IPv4, IPv6, or DNS addresses. Literal IPv6
  addresses must be enclosed in square brackets. If multiple values are given, they are tried and
  retried in the order listed until the first succeeds.

  This supports [Cloud Auto-Joining](#cloud-auto-joining).

  This can be dynamically defined with a [go-sockaddr] template that is resolved at runtime.

  If Consul is running on a non-default Serf LAN port, you must specify the port number in the address when using the `-retry-join` flag. Alternatively, you can specify the custom port number as the default in the agent's [`ports.serf_lan`](/consul/docs/agent/config/config-files#serf_lan_port) configuration or with the [`-serf-lan-port`](#_serf_lan_port) command line flag when starting the agent.

  If your network contains network segments, refer to the [network segments documentation](/consul/docs/enterprise/network-segments/create-network-segment) for additional information.

  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">

  ```shell-session
  $ consul agent -retry-join "192.0.2.10:8304"
  ```

  </CodeBlockConfig>

  <CodeBlockConfig heading="Using IPv6">

  ```shell-session
  $ consul agent -retry-join "[::1]:8301"
  ```

  </CodeBlockConfig>

  <CodeBlockConfig heading="Using multiple addresses">

  ```shell-session
  $ consul agent -retry-join "consul.domain.internal" -retry-join "10.0.4.67"
  ```

  </CodeBlockConfig>

  ### Cloud Auto-Joining

  The `-retry-join` option accepts a unified interface using the
  [go-discover](https://github.com/hashicorp/go-discover) library for doing
  automatic cluster joining using cloud metadata. For more information, see
  the [Cloud Auto-join page](/consul/docs/install/cloud-auto-join).

  <CodeBlockConfig heading="Using Cloud Auto-Joining">

  ```shell-session
  $ 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 attempts if using
  [`-retry-join`](#_retry_join) before exiting with return code 1. By default, this is set
  to 0 which is interpreted as infinite retries.

- `-join-wan` ((#\_join_wan)) - **Deprecated in Consul 1.15. This flag will be removed in a future version of Consul. Use the `-retry-join-wan` flag instead.**
  This is an alias of [`-retry-join-wan`](#_retry_join_wan)

- `-retry-join-wan` ((#\_retry_join_wan)) - Address of another WAN agent to join upon starting up.
  WAN joining is retried until success. This can be specified multiple times to specify multiple WAN
  agents to join. If multiple values are given, they are tried and retried in the order listed
  until the first succeeds. By default, the agent won't WAN join any nodes when it starts up.

  This supports [Cloud Auto-Joining](#cloud-auto-joining).

  This can be dynamically defined with a [go-sockaddr] template that is resolved at runtime.

- `-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.

- `-retry-interval-wan` ((#\_retry_interval_wan)) - Time to wait between
  [`-retry-join-wan`](#_retry_join_wan) attempts. Defaults to 30s.

- `-retry-max-wan` ((#\_retry_max_wan)) - The maximum number of [`-retry-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.

- `-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.

## Log Options

- `-log-file` ((#\_log_file)) - writes all the Consul agent log messages
  to a file at the path indicated by this flag. The filename defaults to `consul.log`.
  When the log file rotates, this value is used as a prefix for the path to the log and 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.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. After rotation, the path and filename take the following form: 
  `/var/log/consul-{timestamp}.log`

- `-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.

- `-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 "error". You can always connect to an agent
  via [`consul monitor`](/consul/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.

- `-syslog` ((#\_syslog)) - This flag enables logging to syslog. This is
  only supported on Linux and macOS. It will result in an error if provided on Windows.

## Node Options

- `-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.
  The node name cannot contain whitespace or quotation marks. To query the node from DNS, the name must only contain alphanumeric characters and hyphens (`-`).

- `-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).

- `-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/), 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.

## Serf Options

- `-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 Options

- `-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
  RPC 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.

## UI Options

- `-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.

<!-- list of reference-style links -->

[go-sockaddr]: https://godoc.org/github.com/hashicorp/go-sockaddr/template