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

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, 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) 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.

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 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.

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):

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 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

Already running RabbitMQ, ActiveMQ, JMS, AMQP 1.0, AWS SQS/SNS, STOMP, GCP Pub/Sub, or MQTT? The Migration hub 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.