KubeMQ
ConfigureReference

Configuration Reference

How to read the per-target tables — the legend and the cross-target gotchas.

The reference documents every KubeMQ server setting, grouped by domain. Each domain page renders its options as a single table with the same seven columns, so the same field reads identically whether you run KubeMQ with Docker or on Kubernetes via Helm. This page is the legend — read it once, then every table downstream is unambiguous.

How to read the tables

Every domain page uses one 7-column table:

ColumnWhat it tells you
SettingThe human-readable name of the option.
TypeThe value type — int, bool, string, size string, enum, etc.
DefaultThe value the server uses when the setting is omitted.
Valid valuesThe accepted range or enum, where one applies.
Docker (config.yaml key · env var)Both Docker forms: the config.yaml key and its environment variable.
Helm/CRD pathThe KubemqCluster spec.* path. The Helm value is that path with the leading spec. removed (spec.grpc.portgrpc.port).
NotesName divergences, validation rules, cross-field constraints, and version floors.

The Docker column always shows two forms of the same setting. The config.yaml key is viper-lowercased with no per-segment separators (for example store.maxretention); the environment variable is that key in UPPER_SNAKE (STORE_MAX_RETENTION).

The Helm/CRD column shows the CRD spec.* path. Because the chart renders values.yaml straight into the CR spec, a Helm value is just that path minus spec. — there is no separate Helm schema to learn.

The "—" convention

A dash () in the Helm/CRD path column means the setting is not available on that surface — it is a Docker / config.yaml-only knob with no Helm route. It does not mean "to be filled in later."

Whole domains are Docker-only by design: the message-broker engine (broker.*), runtime tuning (tuning.*), and standalone clustering (cluster.*) are advanced settings exposed through config.yaml/env only. On Kubernetes the operator owns those concerns. See the Advanced page.

The env-var acronym rule

Docker derives each environment variable from the config.yaml key with convertEnvFormat: snake-case the key, drop the dots, uppercase. The trap is in the connector prefixes — how CONNECTORS joins the next segment depends on whether that segment is a Title-case word or an all-caps acronym:

Connector segmentFormEnv-var prefix
Amqp (0.9.1)Title-case → keeps the underscoreCONNECTORS_AMQP_*
Amqp10 (1.0)Title-case → keeps the underscoreCONNECTORS_AMQP10_*
StompTitle-case → keeps the underscoreCONNECTORS_STOMP_*
AwsTitle-case → keeps the underscoreCONNECTORS_AWS_*
KafkaTitle-case → keeps the underscoreCONNECTORS_KAFKA_*
GcpTitle-case → keeps the underscoreCONNECTORS_GCP_*
MCPall-caps acronym → drops the underscoreCONNECTORSMCP_*
CE (CloudEvents)all-caps acronym → drops the underscoreCONNECTORSCE_*
MQTTall-caps acronym → drops the underscoreCONNECTORSMQTT_*
A2A (agents)splits to A2_ACONNECTORSA2_A_*

The wrong twin is silently ignored — except for CloudEvents. CloudEvents is the one connector that binds both forms: the collapsed CONNECTORSCE_* (primary) and the underscored CONNECTORS_CE_* (a compensating alias) resolve to the same setting — either CONNECTORSCE_ENABLE or CONNECTORS_CE_ENABLE works. MCP, A2A, and MQTT have no such alias. For those, only the collapsed form binds — CONNECTORSMCP_*, CONNECTORSA2_A_*, and CONNECTORSMQTT_*. The underscored twin (CONNECTORS_MCP_*, CONNECTORS_A2_A_*, CONNECTORS_MQTT_*) does not bind — the server starts, accepts the variable without error, and silently ignores it.

enabledisabled inversion

The enable model is not uniform — it splits into two families, and each family's default and CRD field name are different:

  • HTTP-family interfaces/connectors (gRPC, REST, API, MCP, A2A, CloudEvents) are opt-outon by default. Docker turns one off with enable: false — for example connectors.ce.enable: false (env CONNECTORSCE_ENABLE=false). Helm/CRD turns one off with spec.<x>.disabled: true; omit the key while the connector stays on.
  • Wire-protocol connectors (MQTT, AMQP 0.9.1, AMQP 1.0, STOMP, Kafka, AWS, GCP) are opt-inoff by default. Docker turns one on with enable: true. Helm/CRD turns one on with spec.<x>.enabled: true; omit the key and the connector stays off.

Docker always uses enable: true | false regardless of family — only the default and the Helm/CRD field name (disabled vs enabled) differ. Each domain page shows the form that applies on each target.

Configuration domains

Every server setting lives on one of the nine domain pages below.

Was this page helpful?

On this page