# Connectors (/connectors)



A **connector** is a built-in, server-side **protocol gateway** in kubemq-server that
bridges an external protocol to KubeMQ messaging — no KubeMQ SDK is required on the
client. Point a standard HTTP, JSON-RPC, or CloudEvents client at the server and it
speaks to the message broker for you.

## What is a connector [#what-is-a-connector]

KubeMQ ships connectors in **two classes**, all built into the server.

**Shared-HTTP gateway** — runs on the shared HTTP server (port 9090):

* **CloudEvents** — a native CNCF CloudEvents-over-HTTP interface for all five
  messaging patterns — Events, Events Store, Queues, Commands, and Queries — with CESQL
  routing and SSE.

KubeMQ's two AI-facing HTTP gateways — **AI Agents (A2A)** and **MCP** — also fit this
connector definition: they are built-in, server-side HTTP gateways that run on the same
shared HTTP server. They are now documented under [Aiway](/aiway), KubeMQ's AI
Agents Fabric, where the agent-to-agent story is told as a whole.

**Wire-protocol connectors** — six connectors that speak a standard messaging
protocol on their **own dedicated ports**, so an existing client connects by changing
only its connection string, broker address, or endpoint URL:

* **AMQP 1.0** — native AMQP 1.0 clients, all five patterns (ports 5672 / 5671).
* **RabbitMQ (AMQP 0-9-1)** — RabbitMQ clients over the AMQP 0-9-1 wire dialect (5672 / 5671).
* **AWS (SQS & SNS)** — unmodified AWS SDKs over the real SQS/SNS HTTP protocols (port 4566).
* **MQTT** — MQTT 3.1.1 / 5.0 clients (ports 1883 / 8883 / 8083).
* **STOMP** — native STOMP 1.0/1.1/1.2 clients (ports 61613 / 61614).
* **Google Cloud Pub/Sub** — unmodified Pub/Sub clients via `PUBSUB_EMULATOR_HOST` over the real Pub/Sub v1 gRPC protocol (port 8085).

A connector is distinct from the other ways you reach KubeMQ. A **native SDK client**
links a KubeMQ library into your application and speaks the gRPC API. A **framework
adapter** (NestJS, Spring Boot, Celery, KEDA, and the others under
[Integrations](/integrations)) wires KubeMQ into a specific framework's
programming model. A connector, by contrast, runs **inside the server** and accepts a
standard wire protocol directly — nothing KubeMQ-specific is installed on the caller.

The **HTTP gateways** listen on the **shared HTTP server (port 9090)** and are
**enabled by default** — start kubemq-server and CloudEvents (along with the Aiway
gateways, A2A and MCP) is live. The **wire-protocol connectors** listen on their own
dedicated ports and are **all opt-in (disabled by default)** — each opens a new network
listener, so you enable only the ones you need.

<Mermaid
  chart="`
graph TB
REST[&#x22;REST clients&#x22;]
HTTP[&#x22;Shared HTTP Server<br/>:9090&#x22;]
CE[&#x22;CloudEvents&#x22;]
AIWAY[&#x22;A2A & MCP<br/>(documented under Aiway)&#x22;]
ARR[&#x22;Array&#x22;]
BROKER[&#x22;Message Broker&#x22;]

REST --> HTTP
HTTP --> CE
HTTP -.-> AIWAY
CE --> ARR
ARR --> BROKER

class REST client
class AIWAY aiway
class HTTP,ARR,BROKER broker
class CE connector
`"
/>

*CloudEvents is the shared-HTTP gateway documented here; the AI gateways (A2A & MCP) run on the same port 9090 server but are documented under Aiway. The six wire-protocol connectors listen on their own ports. All front the same message broker.*

## The HTTP gateway [#the-http-gateway]

<Cards>
  <Card title="CloudEvents" href="/connectors/cloudevents" description="Publish and subscribe over the CNCF CloudEvents HTTP protocol with CESQL routing and SSE." />
</Cards>

<Callout title="Looking for AI agents or MCP?">
  AI agents (A2A) and MCP now live under &#x2A;*[Aiway](/aiway)** — KubeMQ's AI Agents
  Fabric. They are still built-in HTTP gateways on the shared HTTP server; their docs
  just moved to where the agent-to-agent story is told end to end.
</Callout>

## The wire-protocol connectors [#the-wire-protocol-connectors]

Speak a standard messaging protocol on a dedicated port — point an existing client at
KubeMQ by changing only its connection string, broker address, or endpoint URL.

<Cards>
  <Card title="AMQP 1.0" href="/connectors/amqp" description="Opt-in. Native AMQP 1.0 clients (Qpid-JMS and others) across all five messaging patterns. Ports 5672 / 5671." />

  <Card title="RabbitMQ (AMQP 0-9-1)" href="/connectors/rabbitmq" description="Opt-in. Point a RabbitMQ app at KubeMQ by changing only the connection string. Ports 5672 / 5671." />

  <Card title="AWS (SQS & SNS)" href="/connectors/aws" description="Opt-in. Unmodified AWS SDKs over the real SQS and SNS protocols. Port 4566." />

  <Card title="MQTT" href="/connectors/mqtt" description="Opt-in. MQTT 3.1.1 / 5.0 clients over events, queues, and request/reply. Ports 1883 / 8883 / 8083." />

  <Card title="STOMP" href="/connectors/stomp" description="Opt-in. Native STOMP 1.0/1.1/1.2 clients; the destination prefix selects the pattern. Ports 61613 / 61614." />

  <Card title="Google Cloud Pub/Sub" href="/connectors/gcp-pub-sub" description="Opt-in. Point an unmodified Pub/Sub app at KubeMQ by setting PUBSUB_EMULATOR_HOST. Pub/Sub v1 gRPC; port 8085." />
</Cards>

## Shared foundations [#shared-foundations]

Every **HTTP gateway** — CloudEvents here, plus the Aiway gateways (A2A and MCP) — runs
on **one HTTP server** and shares the same auth model, middleware chain, and metrics
surface. That shared story is told once here, and each gateway links back to it instead
of repeating it (the wire-protocol connectors document their own ports and auth in their
own pages):

<Cards>
  <Card title="Shared HTTP server" href="/connectors/concepts/shared-http-server" description="Port 9090, the middleware chain, the enable model, and reserved channel prefixes." />

  <Card title="Auth & security" href="/connectors/reference/auth-and-security" description="JWT Bearer auth, CORS, origin validation, and TLS/mTLS across every connector." />

  <Card title="Observability" href="/connectors/concepts/observability" description="Prometheus metrics, OpenTelemetry tracing, and the web AI dashboard." />
</Cards>

Every HTTP gateway also inherits the unified middleware pipeline — JWT auth, CORS, origin
validation, TLS/mTLS, a traffic gate, and OpenTelemetry tracing — and the reserved
`_AGENTS_.` channel prefix, which user channels may not use. Connector metrics roll up
into the cluster-wide observability view alongside the rest of the server.

To **disable** an HTTP gateway, set its enable env var to `false` — for example
`CONNECTORSCE_ENABLE=false` for CloudEvents. The HTTP gateways are on by default; you
never need to set `=true` for them. See [Shared HTTP server](/connectors/concepts/shared-http-server)
for their disable vars and why the names look the way they do. The **wire-protocol connectors are
all opt-in** — disabled by default. Enable each one explicitly with its enable env var:
`CONNECTORSMQTT_ENABLE=true`, `CONNECTORS_AMQP_ENABLE=true`, `CONNECTORS_AMQP10_ENABLE=true`,
`CONNECTORS_STOMP_ENABLE=true`, `CONNECTORS_AWS_ENABLE=true`, `CONNECTORS_GCP_ENABLE=true`.
Each wire-protocol connector documents its own ports, enable var, and auth in its own pages.

## Migrating from another broker [#migrating-from-another-broker]

Already running RabbitMQ, ActiveMQ, JMS, AMQP 1.0, AWS SQS/SNS, STOMP, GCP Pub/Sub, or
MQTT? The [Migration hub](/connectors/how-to/migration) maps each ecosystem to its KubeMQ
wire-protocol connector and walks through the cutover — endpoint changes, concept mapping,
a working client example, and what does not carry over — for all eight.