24.1 beta 23.3 23.2 23.1

rpk -X

Use rpk -X flag to override any rpk-specific configuration option.

Every configuration flag for rpk is a key=value option following the -X flag. For example, rpk -X tls.enabled=true enables TLS for the Kafka API.

Every -X option can be translated into an environment variable by prefixing with RPK_ and replacing periods (.) with underscores (_). For example, the flag tls.enabled has the equivalent environment variable RPK_TLS_ENABLED.

  • Flags common across all rpk commands in previous versions (for example, --brokers, --tls-enabled) are deprecated.

  • Functionality of all deprecated flags are supported as -X options.

  • rpk supports command-line (tab) completion for -X flag keys.

  • Each rpk command’s -help text prints information specific to the command. To view a description of -X options, run rpk -X list to list supported options, or run rpk -X help to get details about supported options.

Options

The following options are available, with an example option=value for each.

brokers

A comma separated list of host:ports that rpk communicates with for the Kafka API. By default, this option is set to 127.0.0.1:9092.

Example: brokers=127.0.0.1:9092,localhost:9094

tls.enabled

A boolean that enables rpk to speak TLS to your broker’s Kafka API listeners.

You can use this if you have well known certificates set up on your Kafka API. If you use mTLS, specifying mTLS certificate filepaths automatically opts into tls.enabled.

Example: tls.enabled=true

tls.ca

A filepath to a PEM encoded CA certificate file to talk to your broker’s Kafka API listeners with mTLS.

You may need this option if your listeners are using a certificate by a well known authority that is not bundled with your operating system.

Example: tls.ca=/path/to/ca.pem

tls.cert

A filepath to a PEM encoded client certificate file to talk to your broker’s Kafka API listeners with mTLS.

Example: tls.cert=/path/to/cert.pem

tls.key

A filepath to a PEM encoded client key file to talk to your broker’s Kafka API listeners with mTLS.

Example: tls.key=/path/to/key.pem

sasl.mechanism

The SASL mechanism to use for authentication, either SCRAM-SHA-256 or SCRAM-SHA-512.

With Redpanda, the Admin API can be configured to require basic authentication with your Kafka API SASL credentials. This defaults to SCRAM-SHA-256 if no mechanism is specified.

Example: sasl.mechanism=SCRAM-SHA-256

user

The SASL username to use for authentication. It’s also used for the Admin API if you have configured it to require basic authentication.

Example: user=username

pass

The SASL password to use for authentication. It’s also used for the Admin API if you have configured it to require basic authentication.

Example: pass=password

admin.hosts

A comma separated list of host:ports that rpk communicates with for the Admin API. By default, this is set to 127.0.0.1:9644.

Example: admin.hosts=localhost:9644,rp.example.com:9644

admin.tls.enabled

A boolean that enables rpk to speak TLS to your broker’s Admin API listeners.

You can use this if you have well known certificates set up on your Admin API. If you use mTLS, specifying mTLS certificate filepaths automatically opts into admin.tls.enabled.

Example: admin.tls.enabled=false

admin.tls.ca

A filepath to a PEM encoded CA certificate file to talk to your broker’s Admin API listeners with mTLS. You may also need this if your listeners are using a certificate by a well known authority that is not yet bundled with your operating system.

Example: admin.tls.ca=/path/to/ca.pem

admin.tls.cert

A filepath to a PEM encoded client certificate file to talk to your broker’s Admin API listeners with mTLS.

Example: admin.tls.cert=/path/to/cert.pem

admin.tls.key

A filepath to a PEM encoded client key file to talk to your broker’s Admin API listeners with mTLS.

Example: admin.tls.key=/path/to/key.pem

cloud.client_id

An OAuth client ID to use for authenticating with the Redpanda Cloud API.

Example: cloud.client_id=somestring

cloud.client_secret

An OAuth client secret to use for authenticating with the Redpanda Cloud API.

Example: cloud.client_secret=somelongerstring

defaults.prompt

A format string to use for the default prompt. See rpk profile prompt for more information.

Example: defaults.prompt="%n"

defaults.no_default_cluster

A boolean that disables rpk from communicating to localhost:9092 if no other cluster is specified.

Example: defaults.no_default_cluster=false

defaults.dial_timeout

A duration that rpk will wait for a connection to be established before timing out.

Example: defaults.dial_timeout=3s

defaults.request_timeout_overhead

A duration that limits how long rpk waits for responses.

defaults.request_timeout_overhead applies in addition to any request-internal timeout.

For example, ListOffsets has no Timeout field, so rpk will wait request_timeout_overhead for a response. However, JoinGroup has a RebalanceTimeoutMillis field, so request_timeout_overhead is applied on top of the rebalance timeout.

Example: defaults.request_timeout_overhead=10s

defaults.retry_timeout

This timeout specifies how long rpk will retry Kafka API requests.

This timeout is evaluated before any backoff:

  • If a request fails, rpk first checks if the retry timeout has elapsed.

    • If the retry timeout has elapsed, rpk stops retrying.

    • Otherwise, rpk waits for the backoff and then retries.

Example: defaults.retry_timeout=30s

defaults.fetch_max_wait

This timeout specifies the maximum duration that brokers will wait before replying to a fetch request with available data.

Example: defaults.fetch_max_wait=5s

defaults.redpanda_client_id

This string value is the client ID that rpk uses when issuing Kafka protocol requests to Redpanda. This client ID shows up in Redpanda logs and metrics. Changing it can be useful if you want to have your own rpk client stand out from others that are also interacting with the cluster.

Example: defaults.redpanda_client_id=rpk