# Configuration (/connectors/amqp/concepts/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.

<Callout type="info">
  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.
</Callout>

## Enable / disable [#enable--disable]

Enable the connector with its enable variable:

<RunKubeMQ ports="[5672, 5671, 50000]" env="{ CONNECTORS_AMQP10_ENABLE: 'true' }" />

To turn it **off** again:

<RunKubeMQ variant="disable" ports="[50000]" env="{ CONNECTORS_AMQP10_ENABLE: 'false' }" />

<Callout type="warn">
  **The 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.
</Callout>

### `DefaultPattern` and the bare-address fallback [#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](/connectors/amqp/concepts/addressing).

## TLS [#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](/connectors/amqp/how-to/tls-and-mtls) and
[Auth & security](/connectors/reference/auth-and-security).

For the full field list, validation rules, and TOML/environment/Docker configuration
examples, see [Configuration reference](../reference/configuration).

## Related [#related]

<Cards>
  <Card title="Getting Started" href="/connectors/amqp/tutorials/getting-started" description="Connect, send, and receive a message end-to-end through the AMQP 1.0 connector." />

  <Card title="Architecture" href="/connectors/amqp/concepts/architecture" description="The amqpmux front door, port sharing with AMQP 0-9-1, and the connection/session/link model." />

  <Card title="Authentication" href="/connectors/amqp/how-to/authentication" description="SASL PLAIN with a KubeMQ JWT, and SASL EXTERNAL over mTLS." />

  <Card title="TLS and mTLS" href="/connectors/amqp/how-to/tls-and-mtls" description="Enabling TLS on 5671 via the server-global Security block and client-cert mapping." />
</Cards>