Configuration
How the KubeMQ AMQP 1.0 connector's opt-in enable flag and DefaultPattern bare-address fallback shape its server-side configuration.
The AMQP 1.0 connector is configured server-side through 14 settings under the
Connectors.Amqp10.* namespace of the KubeMQ server config. The connector is opt-in
(disabled by default) — you must explicitly enable it, even though port 5672 is already
bound on a stock server by the RabbitMQ (AMQP 0-9-1) connector. It ships with sensible production
defaults, so most deployments only override a value when they need a larger frame size, a
higher connection cap, or a different RPC timeout.
The only thing clients configure is the broker endpoint via the KUBEMQ_AMQP_URL
environment variable (default amqp://localhost:5672). Everything below is broker-side
server configuration. These settings are not hot-reloadable — changing any of them
requires a server restart.
Enable / disable
Enable the connector with its enable variable:
docker run -d \ --pull always \ --platform linux/amd64 \ --name kubemq \ --hostname kubemq \ -p 127.0.0.1:5672:5672 \ -p 127.0.0.1:5671:5671 \ -p 127.0.0.1:50000:50000 \ -e STORE_ENGINE=next \ -e STORE_NEXT_ACK_POLICY=strict \ -e STORE_STORE_PATH=/kubemq/store \ -e API_BIND_ADDRESS=0.0.0.0 \ -e CONNECTORS_AMQP10_ENABLE=true \ -v kubemq-data:/kubemq/store \ europe-docker.pkg.dev/kubemq/images/kubemq-next:latestTo turn it off again:
docker run -d --pull always --platform linux/amd64 --name kubemq --hostname kubemq -p 127.0.0.1:50000:50000 -e STORE_ENGINE=next -e STORE_NEXT_ACK_POLICY=strict -e STORE_STORE_PATH=/kubemq/store -e API_BIND_ADDRESS=0.0.0.0 -e CONNECTORS_AMQP10_ENABLE=false -v kubemq-data:/kubemq/store europe-docker.pkg.dev/kubemq/images/kubemq-next:latestThe enable variable is CONNECTORS_AMQP10_ENABLE — the literal 10 stays attached to
AMQP with no underscore. The config key Connectors.Amqp10.Enable snake-cases by
stripping the dots and upper-casing, so Amqp10 becomes AMQP10. Variants like
CONNECTORS_AMQP_1_0_ENABLE or CONNECTORS_AMQP10ENABLE do not bind to the field and
are silently ignored. When Enable is false, all other AMQP 1.0 validation is skipped
and no AMQP 1.0 engine is attached to the shared listener — port 5672 stays open for
AMQP 0-9-1 (on by default), and an AMQP 1.0 client connects at the TCP level but is closed
during protocol negotiation.
DefaultPattern and the bare-address fallback
DefaultPattern only matters for bare addresses — a node address with no recognized
<pattern>/ prefix and no JMS node-capability hint (queue → queues, topic →
events). Because best practice is to always emit the explicit prefix
(queues/orders, events/telemetry), DefaultPattern rarely affects real traffic. Treat
bare addressing as a migration convenience only — it is non-deterministic by design. See
Addressing.
TLS
TLS for the AMQP 1.0 connector is driven entirely by the server-global Security
block (the same one the gRPC and AMQP 0-9-1 listeners use), not by an AMQP-1.0-specific
field. When Security is configured, the shared amqpmux TLS listener binds on TlsPort
with a minimum of TLS 1.2; mTLS adds the client CA pool and requires a verified client
certificate (mapped to SASL EXTERNAL). See
TLS and mTLS and
Auth & security.
For the full field list, validation rules, and TOML/environment/Docker configuration examples, see Configuration reference.
Related
Getting Started
Connect, send, and receive a message end-to-end through the AMQP 1.0 connector.
Architecture
The amqpmux front door, port sharing with AMQP 0-9-1, and the connection/session/link model.
Authentication
SASL PLAIN with a KubeMQ JWT, and SASL EXTERNAL over mTLS.
TLS and mTLS
Enabling TLS on 5671 via the server-global Security block and client-cert mapping.
Was this page helpful?
Commands
Native AMQP 1.0 request/reply over KubeMQ Commands — dynamic reply nodes, anonymous responders, correlation-id matching, and an executed/error signal.
Events
Fire-and-forget pub/sub over AMQP 1.0 — pre-settled at-most-once fan-out, standing credit, and x-opt-kubemq-group consumer groups on the KubeMQ Events pattern.