Agent Config Version 3 - ngrok documentation

The ngrok agent supports an optional, YAML configuration file which enables you to configure advanced settings and run multiple endpoints simultaneously. The agent configuration file location depends on your system. You can check the location of your configuration file by running ngrok config check or edit the file in your terminal by running ngrok config edit.

YAML is whitespace-sensitive. Use spaces only (tabs are not valid in YAML) and keep keys at the same level aligned to the same column.✅ Valid:

endpoints:
  - name: example
    upstream:
      url: 80

❌ Invalid—upstream is indented inconsistently and will fail to parse:

endpoints:
  - name: example
     upstream:
      url: 80

Breaking changes

There are important differences between the v3 ngrok Agent Configuration file and v2:

Agent configuration options are no longer top-level. They’re now nested under the agent field.
Endpoints are now configured through the endpoints field.
Deprecated the tunnels field in favor of endpoints.
Changed server_addr agent configuration field to connect_url.
Changed root_cas agent configuration field to connect_cas.
Labeled tunnels are no longer supported in v3. Use endpoints instead.

Migrating from v2

Migrating from v2 to v3 requires you to update to the latest agent, nest your agent configuration options under the agent field, change the version field to 3, and modify any agent configuration fields that have changed. Here’s an example v2 configuration file:

version: 2
authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p
api_key: 24yRd5U3DestCQapJrrVHLOqiAC_7RviwRqpd3wc9dKLujQZN

tunnels:
  basic:
    proto: http
    addr: 80

For v3, you need to update the version, introduce the agent field, and convert from tunnels to endpoints:

version: 3

agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p
  api_key: 24yRd5U3DestCQapJrrVHLOqiAC_7RviwRqpd3wc9dKLujQZN

endpoints:
  - name: http
    url: http://demo.ngrok.app
    upstream:
      url: 80

You also need to adjust the following fields if you’re using them:

Change root_cas to connect_cas
Change server_addr to connect_url

Supported fields

The ngrok Agent Configuration file supports the following top-level configuration fields:

Configuration File Version Field - version (required)
Agent Configuration Field - agent (required)
Endpoint Definitions - endpoints
Tunnel Definitions - tunnels (deprecated)

Version

The top-level version field is required. Value must be 3.

Example

version: 3

Agent configuration

The top-level agent field is required. The agent field allows you to modify both general and advanced agent configuration options, everything from your authtoken to whether the agent should check for updates.

Agent configuration options

Name	Description
`api_key`	The API key to be used when making requests through the `ngrok api` command.
`authtoken`	The authentication token used to authenticate this agent when it connects to the ngrok service.
`connect_cas`	The root certificate authorities used to validate the TLS connection to the ngrok server.
`connect_interface`	Set the specific network interface for ngrok to use. This is only supported on Linux platforms.
`connect_timeout`	How long to wait when establishing an agent session connection to the ngrok service. The default is 10s.
`connect_url`	This is the URL of the ngrok server to connect to. You should only set this if you’re using a custom ingress URL.
`console_ui`	Enable/disable the console UI
`console_ui_color`	Set the background color of the console UI
`crl_noverify`	Disables verifying Certificate Revocation List
`crl_url`	Override the URL the agent fetches the Certificate Revocation List from.
`dns_resolver_ips`	Consult these DNS servers for tunnel session DNS resolution.
`heartbeat_interval`	How often the ngrok agent should heartbeat to the ngrok servers defined as a duration. Default is 10s.
`heartbeat_tolerance`	Reconnect the agent tunnel session if the server doesn’t respond to a heartbeat within this tolerance defined as a duration. Default is 15s.
`inspect_db_size`	The size in bytes of the upper limit on memory to allocate to save requests over HTTP tunnels for inspection and replay.
`log_level`	Logging level of detail. In increasing order of verbosity, possible values are: `crit`, `warn`, `error`, `info`, and `debug`.
`log_format`	Format of written log records.
`log`	Write logs to this target destination.
`metadata`	Opaque, user-supplied string that’s returned as part of the ngrok API response to the list online sessions resource for all endpoints started by this agent.
`proxy_url`	URL of an HTTP or SOCKS5 proxy to use for establishing the tunnel connection.
`remote_management`	Set this to `true` to allow the ngrok agent to be remotely managed (stop, restart, update). Defaults to `true`.
`update_channel`	The update channel determines the stability of released builds to update to. Use `stable` for all production deployments.
`update_check`	This tells the ngrok agent if it should check for updates. Defaults to `true`.
`web_addr`	Network address to bind on for serving the local web interface and API.
`web_allow_hosts`	`Host` headers to allow access for on the local web interface and API, can be a combination of IPs, CIDR ranges, and/or hostname suffixes.

`authtoken`

The authentication token used to authenticate this agent when it connects to the ngrok service. You can obtain your default authtoken through the ngrok dashboard.

Deploying on multiple devices

Your default authtoken works on multiple machines or devices. However, if you want more control and security across many devices, you can generate a unique authtoken for each device in the ngrok dashboard or via the ngrok api credentials command.

Example

agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p

`api_key`

This option is only required when you want to make requests using the ngrok api command and shouldn’t be confused with the authtoken option.

The API key to be used when making requests through the ngrok api command. You can obtain and manage your API keys through the ngrok dashboard.

Example

agent:
  api_key: 24yRd5U3DestCQapJrrVHLOqiAC_7RviwRqpd3wc9dKLujQZN

`connect_cas`

These are the root certificate authorities used to validate the TLS connection to the ngrok server.

Parameter	Default	Description
`trusted`	default	use only the trusted certificate root for the ngrok.com tunnel service
`host`		use the root certificates trusted by the host’s operating system. This is helpful for working with machine-in-the-middle (MITM) proxies doing deep packet inspection (DPI).
other values		path to a certificate PEM file on disk with certificate authorities to trust

`connect_interface`

Sets the specific network interface that the ngrok agent should use. This is only supported on Linux platforms.

`connect_timeout`

How long to wait when establishing an agent session connection to the ngrok service. This is specified as a duration, with the default being 10s.

`connect_url`

This is the URL of the ngrok server to connect to. You should set this if you’re using a custom Connect URL. See the Connect URL docs for more information.

`console_ui`

This option allows you to enable or disable the console UI that appears in your terminal window after you start ngrok.

Parameter	Default	Description
`true`		Enable the console UI
`false`		Disable the console UI
`iftty`	default	Enable the UI only if standard out is a TTY (not a file or pipe)

`console_ui_color`

The command sets the background color when displaying the console UI in the terminal. To choose a color other than black, set the value to transparent and change the background of your terminal window.

Parameter	Default	Description
`transparent`		Don’t set a background color when displaying the console UI
`black`	default	Set the console UI’s background to black

`crl_noverify`

This option skips verifying with the Certificate Revocation List if set to true. This defaults to false.

`crl_url`

The URL the ngrok agent fetches the Certificate Revocation List (CRL) from. The default is http://crl.ngrok-agent.com/ngrok.crl. The URL must use the http or https scheme. Set this option if your network blocks outbound connections on port 80. For example, https://crl.ngrok-agent.com/ngrok.crl fetches the same CRL over HTTPS on port 443. The agent verifies the CRL’s signature, so you can also serve a mirrored copy from your own host. This option has no effect when crl_noverify is true. Available in ngrok agent version 3.39.7 and later.

agent:
  crl_url: https://crl.ngrok-agent.com/ngrok.crl

`dns_resolver_ips`

Consult these DNS servers for tunnel session DNS resolution. By default, the ngrok agent uses the local system DNS servers to resolve.

`heartbeat_interval`

How often the ngrok agent should heartbeat to the ngrok servers defined as a duration. The default is 10s.

`heartbeat_tolerance`

Reconnect the agent tunnel session if the server doesn’t respond to a heartbeat within this tolerance defined as a duration. The default is 15s.

`inspect_db_size`

This is the upper limit in bytes on memory to allocate when saving requests over HTTP endpoints for inspection and replay. The default is 0, which means 50MB.

Parameter	Default	Description
positive integers		size in bytes of the upper limit on memory to allocate to save requests over HTTP endpoints for inspection and replay.
`0`	default	use the default allocation limit, 50MB
`-1`		disable the inspection database; this has the effective behavior of disabling inspection for all tunnels

`log_level`

This is the logging level of detail. In increasing order of verbosity, possible values are: crit, warn, error, info, and debug.

`log_format`

This is the format of written log records.

Parameter	Default	Description
`logfmt`		human and machine friendly key/value pairs
`json`		newline-separated JSON objects
`term`	default	custom colored human format if standard out is a TTY, otherwise same as `logfmt`

`log`

This is the destination where ngrok should write the logs.

Parameter	Default	Description
`stdout`		write to standard out
`stderr`		write to standard error
`false`	default	disable logging
`<path>`		write log records to file path on disk

agent:
  log: /var/log/ngrok.log

`metadata`

This is a user-supplied custom string that’s returned as part of the ngrok API response to the list online sessions resource for all endpoints started by this agent. This is a useful mechanism to identify endpoints by your own device or customer identifier. Maximum 4096 characters.

agent:
  metadata: bad8c1c0-8fce-11e4-b4a9-0800200c9a66

`proxy_url`

This is the URL of an HTTP or SOCKS5 proxy to use for establishing the tunnel connection. Many HTTP proxies have connection size and duration limits that cause ngrok to fail. Like many other networking tools, ngrok also respects the environment variable http_proxy and http_proxy_env if it’s set.

`remote_management`

Set this to true to allow the ngrok agent to be remotely managed (stop, restart, update) via the ngrok API or the ngrok dashboard. Defaults to true.

`update_channel`

The update channel determines the stability of released builds to update to. Use ‘stable’ for all production deployments.

Parameter	Default	Description
`stable`	default	These are builds that are ready to be used in production.
`unstable`		update to new nightly builds when available which could be broken. Don’t use this in production.
`beta`		update to new beta builds when available which could be broken. Don’t use this in production.

`update_check`

This tells the ngrok agent if it should check for updates. Defaults to true.

`web_addr`

This is the network address to bind on for serving the local agent web interface and API.

Network address		Bind to this network address
`127.0.0.1:4040`	default	default network address
`false`		disable the web UI

`web_allow_hosts`

This is a list of specifiers for which Host headers can make requests against the local agent web interface and API. The agent strips any port off the Host header before matching.

Allow string		Example `Host` headers that would match
	default	requests to localhost-bound web interface or API endpoints are checked to have a localhost-like `Host` such as localhost, 127.0.0.1, or ::1
`8.8.8.8`		an IP matches `Host` header (`8.8.8.8`)
`1:2:3:4:5:6:7:8`		an IPv6 matches `Host` header (`1:2:3:4:5:6:7:8`)
`10.0.0.0/8`		a CIDR range matches a `Host` header that is an IP address in that range (`10.0.0.1 or 10.1.2.3`)
`1:2:3:4:5:6:7:8/16`		a CIDR range matches a `Host` header that is an IPv6 address in that range (`1:2:3:4:5:6:7:0`)
`example.com`		a hostname without preceding period matches `Host` header exactly (`example.com`)
`.example.com`		a hostname with a preceding period `Host` header suffix (`sub.example.com` or `foo.example.com`)

Example

Allow an IP address and a domain as Host headers:

agent:
  web_allow_hosts:
    - 8.8.8.8
    - example.com

Working with machine-in-the-middle (MITM) proxies

If you’re working with machine-in-the-middle (MITM) proxies, you may need to specify a custom CA certificate to trust the ngrok server. This may require you to use the ngrok root CA certificate that the agent uses to connect to the ngrok edge. Use the following command to extract the ngrok agent self-signed root CA certificate: strings `which ngrok` | grep 'BEGIN CERTIFICATE' -A 22 This outputs the root CA certificate in PEM format.

Endpoint definitions

The endpoints field enables you to define and configure multiple endpoints. Defining multiple endpoints this way enables you to start pre-configured endpoints by name without having to memorize the right arguments every time through the ngrok start command. You can also use this field to start multiple endpoints at the same time from a single agent using the ngrok start --all flag. The endpoints field accepts a list of endpoint configurations. You can find the list of available endpoint configuration options here.

Example

The snippet below defines two HTTPS endpoints, one TCP endpoint, and one TLS endpoint, named ‘httpbin’, ‘demo’, ‘ssh’, and ‘demo-2’, respectively:

endpoints:
  - name: httpbin
    url: https://alan-httpbin.ngrok.app
    upstream:
      url: 8080
  - name: demo
    url: https://demo.inconshreveable.com
    upstream:
      url: 8181
  - name: ssh
    url: tcp://1.tcp.ngrok.io:12345
    upstream:
      url: 22
  - name: demo-2
    url: tls://myexample.ngrok.app
    upstream:
      url: 443

Start the endpoint named ‘httpbin’

ngrok start httpbin

Start all endpoints

ngrok start --all

Endpoint configuration options

Name	Required	Description
`agent_tls_termination`		Configuration for TLS termination at the ngrok agent. This is applicable only when the endpoint URL scheme is `tls://`.
`name`	Required	A unique name for this endpoint’s configuration.
`url`		The address you would like to use to forward traffic to your upstream service. Leave empty to use your account’s dev domain.
`bindings`		Allows you to configure the bindings for this endpoint. Currently, you can provide only one binding.
`metadata`		An arbitrary string of user-defined metadata for this endpoint.
`description`		An arbitrary user-defined description about this endpoint.
`traffic_policy`		Accepts a Traffic Policy configuration in YAML format.
`upstream`	Required	Upstream service configuration options.

`agent_tls_termination`

Object. Configuration for TLS termination at the ngrok agent. This is applicable only when the endpoint URL scheme is tls://.

`agent_tls_termination.mutual_tls_certificate_authorities`

String[]. Specifies one or more Root CA certificates (as paths or raw PEM data) to validate client certificates for mutual TLS authentication. Available only for tls:// URLs.

`agent_tls_termination.server_certificate`

String. The server certificate (provided as a file path or raw PEM data) used by the ngrok agent for TLS termination. Available only for tls:// URLs.

`agent_tls_termination.server_private_key`

String. The private key (provided as a file path or raw PEM data) corresponding to the server certificate, used for TLS termination by the ngrok agent. Available only for tls:// URLs.

`name`

Required. String. A unique name for this endpoint’s configuration. This is the value you use when running the ngrok start <name> command.

Example

# ...
endpoints:
  - name: example
# ...

`url`

String[]. The address you would like to use to forward traffic to your upstream service.

Accepted formats

Domain - example.org
- When using the domain format, you’re only defining the domain. The scheme and port are inferred.
Origin - https://example.ngrok.app or https://example.ngrok.app:443 or tcp://1.tcp.ngrok.io:12345 or tls://example.ngrok.app
- When using the origin format, you’re defining the protocol, domain, and port. HTTP endpoints accept ports 80 or 443 with respective protocol.
Scheme (shorthand) - https:// or tcp:// or tls:// or http://
- When using scheme, you’re defining the protocol. HTTP and HTTPS endpoints use your account’s dev domain, and TCP and TLS endpoints receive an ngrok-assigned address.
Empty - “
- When empty, your endpoint defaults to https and uses your account’s dev domain.

Example

# ...
endpoints:
  - name: example
    url: https://example.ngrok.app
# ...

`bindings`

String[]. Allows you to configure the bindings for this endpoint. Currently, you can provide only one binding. The allowed values are internal, public, and kubernetes, which allow you to create public, internal, and Kubernetes endpoints. This field is only necessary for creating Kubernetes endpoints, because the default for all endpoints is to have a public binding, and ngrok automatically infers an internal binding when the endpoint URL ends in .internal. To create a Kubernetes endpoint (which projects the endpoint into one or more Kubernetes clusters running the ngrok Operator as a Service resource), set the bindings field to ["kubernetes"].

Example

# ...
endpoints:
  - name: example
    url: https://example-service.example-namespace
    bindings:
    - kubernetes
# ...

`metadata`

String. An arbitrary string of user-defined metadata for this endpoint. This value appears on the endpoint object in the ngrok API.

Example

# ...
endpoints:
  - name: example
    url: https://example.ngrok.app
    metadata: '{ "id": "example-app" }'
# ...

`description`

String. An arbitrary user-defined description about this endpoint. This value appears on the endpoint object in the ngrok API.

Example

# ...
endpoints:
  - name: example
    url: https://example.ngrok.app
    metadata: '{ "id": "example-app" }'
    description: "our example application"
# ...

`traffic_policy`

Object. Accepts a Traffic Policy configuration in YAML format. Traffic Policy enables you to manage, route, and secure traffic through configuration. You can learn more about the individual parts of the Traffic Policy and the available actions here:

Example

# ...
endpoints:
  - name: example
    url: https://example.ngrok.app
    metadata: '{ "id": "example-app" }'
    description: "our example application"
    traffic_policy:
      on_http_request:
        - actions:
            - type: custom-response
              config:
                status_code: 200
                body: hello, Traffic Policy!
                headers:
                  content-type: text/plain
# ...

`upstream`

Object. Upstream service configuration options.

`upstream.url`

String. The local or remote address you’d like incoming traffic to be forwarded to.

Accepted formats

Origin - https://example.org or http://example.org:80 or tcp://127.0.0.1:80
- When using the origin format, you’re defining the protocol, domain, and port.
  - When no port is present and scheme is https or http, the port is inferred.
    - For https, the port is 443.
    - For http, the port is 80.
Domain - example.org
- This is only allowed for https and http endpoints.
  - For tcp and tls endpoints, host and port are required.
- When using the domain format, you’re only defining the host.
  - Scheme defaults to http.
  - Port defaults to 80.
Scheme (shorthand) - https://
- This only works for https and http.
  - For tcp and tls, host and port are required.
- When using scheme, you’re defining the protocol, and the port is inferred on the local host.
  - For https, the port is 443.
  - For http, the port is 80.
  - Host is localhost.
Port (shorthand) - 8080
- When using port, you’re defining the port on the local host that receives traffic.
  - Scheme defaults to http.
  - Host defaults to localhost.

Example

# ...
endpoints:
  - name: example
    url: https://example.ngrok.app
    metadata: '{ "id": "example-app" }'
    description: "our example application"
    traffic_policy:
      on_http_request:
        - actions:
            - type: custom-response
              config:
                status_code: 200
                body: hello, Traffic Policy!
                headers:
                  content-type: text/plain
    upstream:
      url: 8080
# ...

`upstream.protocol`

String. The application layer protocol the agent should use when talking to your upstream application for HTTP endpoints.

Accepted values

http1 (default)
http2

Example

# ...
endpoints:
  - name: example
    url: https://example.ngrok.app
    metadata: '{ "id": "example-app" }'
    description: "our example application"
    traffic_policy:
      on_http_request:
        - actions:
            - type: custom-response
              config:
                status_code: 200
                body: hello, Traffic Policy!
                headers:
                  content-type: text/plain
    upstream:
      url: 8080
      protocol: http1
# ...

`upstream.proxy_protocol`

String. The version of PROXY protocol to use with this endpoint, empty if not using. Possible values are 1 or 2.

Example

# ...
endpoints:
  - name: example
    url: https://example.ngrok.app
    metadata: '{ "id": "example-app" }'
    description: "our example application"
    traffic_policy:
      on_http_request:
        - actions:
            - type: custom-response
              config:
                status_code: 200
                body: hello, Traffic Policy!
                headers:
                  content-type: text/plain
    upstream:
      url: 8080
      protocol: http1
      proxy_protocol: 2
# ...

Tunnels (deprecated)

The tunnels configuration field is deprecated and will be removed by the end of 2025. Use the endpoints configuration field instead.

v3 still supports the tunnels configuration field. This is a key-value list of tunnel name to configurations. Here’s an example:

# Version of the ngrok Agent Configuration file. Required.
version: 3

# Agent Configuration
agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p

# Tunnel Configurations
tunnels:
  basic:
    proto: http
    addr: 80

Tunnel configuration options

You can find the configuration options for tunnels under the Agent Configuration v2 docs.

Example configuration files

The following agent configurations serve as examples for your ngrok.yml file.

Basic

Here’s a basic example configuration file. In this example, the agent authenticates using an authtoken, and the file defines a single HTTPS endpoint named basic with an endpoint URL basic.ngrok.app and an upstream URL of localhost:8080.

# Version of the ngrok Agent Configuration file. Required.
version: 3

# Agent Configuration
agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p

# Endpoint Definitions
endpoints:
  - name: basic
    url: basic.ngrok.app
    upstream:
      url: 8080

Starting the `basic` endpoint

Run the following command to start the basic endpoint. Make sure you update the authtoken in the example to your own before running the following command:

ngrok start basic

Multiple endpoints

# Version of the ngrok Agent Configuration file. Required.
version: 3

# Agent Configuration. Required.
agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p

# Endpoint Definitions
endpoints:
  - name: foo
    description: foo123
    metadata: foo123
    url: foo.ngrok.app
    upstream:
      url: 8080
      protocol: http1
  - name: bar
    url: bar.ngrok.app
    upstream:
      url: 8080

Endpoint with inline Traffic Policy

# Version of the ngrok Agent Configuration file. Required.
version: 3

# Agent Configuration. Required.
agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p

# Endpoint Definitions
endpoints:
  - name: foo
    description: foo123
    metadata: foo123
    url: foo.ngrok.app
    # Traffic Policy that will be applied to this endpoint
    traffic_policy:
      on_http_request:
        - actions:
            - type: custom-response
              config:
                status_code: 200
                body: hello, Traffic Policy!
                headers:
                  content-type: text/plain
    upstream:
      url: 8080
      protocol: http1

Endpoint with Traffic Policy file

# Version of the ngrok Agent Configuration file. Required.
version: 3

# Agent Configuration. Required.
agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p

# Endpoint Definitions
endpoints:
  - name: bar
    url: bar.ngrok.app
    # Path to the Traffic Policy to be read and applied to this endpoint
    traffic_policy_file: /path/to/your/traffic-policy.yml
    upstream:
      url: 8080
      protocol: http2

Endpoint on your dev domain

Here’s an example configuration where ngrok puts your endpoint on your account’s dev domain:

# Version of the ngrok Agent Configuration file. Required.
version: 3

# Agent Configuration. Required.
agent:
  authtoken: 4nq9771bPxe8ctg7LKr_2ClH7Y15Zqe4bWLWF9p

# Endpoint Definitions
endpoints:
  # Endpoint with no endpoint URL defined to use your account's dev domain.
  - name: my_endpoint_name
    #url: http://  # uncomment this line if you want your endpoint to be HTTP, by default it's HTTPS
    upstream:
      url: 80

​Breaking changes

​Migrating from v2

​Supported fields

​Version

​Example

​Agent configuration

​Agent configuration options

​authtoken

Deploying on multiple devices

Example

​api_key

Example

​connect_cas

​connect_interface

​connect_timeout

​connect_url

​console_ui

​console_ui_color

​crl_noverify

​crl_url

​dns_resolver_ips

​heartbeat_interval

​heartbeat_tolerance

​inspect_db_size

​log_level

​log_format

​log

​metadata

​proxy_url

​remote_management

​update_channel

​update_check

​web_addr

​web_allow_hosts

Example

​Working with machine-in-the-middle (MITM) proxies

​Endpoint definitions

​Example

​Start the endpoint named ‘httpbin’

​Start all endpoints

​Endpoint configuration options

​agent_tls_termination

agent_tls_termination.mutual_tls_certificate_authorities

agent_tls_termination.server_certificate

agent_tls_termination.server_private_key

​name

Example

​url

Accepted formats

Example

​bindings

Example

​metadata

Example

​description

Example

​traffic_policy

Example

​upstream

upstream.url

Accepted formats

Example

upstream.protocol

Accepted values

Example

upstream.proxy_protocol

Example

​Tunnels (deprecated)

​Tunnel configuration options

​Example configuration files

​Basic

​Starting the basic endpoint

​Multiple endpoints

​Endpoint with inline Traffic Policy

​Endpoint with Traffic Policy file

​Endpoint on your dev domain

Breaking changes

Migrating from v2

Supported fields

Version

Example

Agent configuration

Agent configuration options

`authtoken`

`api_key`

`connect_cas`

`connect_interface`

`connect_timeout`

`connect_url`

`console_ui`

`console_ui_color`

`crl_noverify`

`crl_url`

`dns_resolver_ips`

`heartbeat_interval`

`heartbeat_tolerance`

`inspect_db_size`

`log_level`

`log_format`

`log`

`metadata`

`proxy_url`

`remote_management`

`update_channel`

`update_check`

`web_addr`

`web_allow_hosts`

Working with machine-in-the-middle (MITM) proxies

Endpoint definitions

Example

Start the endpoint named ‘httpbin’

Start all endpoints

Endpoint configuration options

`agent_tls_termination`

`agent_tls_termination.mutual_tls_certificate_authorities`

`agent_tls_termination.server_certificate`

`agent_tls_termination.server_private_key`

`name`

`url`

`bindings`

`metadata`

`description`

`traffic_policy`

`upstream`

`upstream.url`

`upstream.protocol`

`upstream.proxy_protocol`

Tunnels (deprecated)

Tunnel configuration options

Example configuration files

Basic

Starting the `basic` endpoint

Multiple endpoints

Endpoint with inline Traffic Policy

Endpoint with Traffic Policy file

Endpoint on your dev domain