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. 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 \ --name kubemq \ -p 5672:5672 \ -p 5671:5671 \ -p 50000:50000 \ -e KUBEMQ_TOKEN=YOUR_LICENSE_KEY \ -e CONNECTORS_AMQP10_ENABLE=true \ europe-docker.pkg.dev/kubemq/images/kubemq:nextTo turn it off again:
docker run -d -p 50000:50000 -e KUBEMQ_TOKEN=YOUR_LICENSE_KEY -e CONNECTORS_AMQP10_ENABLE=false europe-docker.pkg.dev/kubemq/images/kubemq:nextThe 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 listener binds.
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.