Pirate Prentice

Posted on Jul 2

n8n RabbitMQ Node: Publish, Consume, and Route Messages in Your Workflows (Free JSON)

RabbitMQ is the most widely deployed open-source message broker. If your stack uses AMQP — whether for task queues, async job processing, or service-to-service decoupling — the n8n RabbitMQ node lets you publish and consume messages directly inside your workflows.

This guide covers credentials, exchanges vs. queues, publishing messages, consuming with triggers, routing keys, durable queues, and real-world patterns.

What the n8n RabbitMQ Node Does

n8n provides two RabbitMQ nodes:

Node	Direction	Use case
RabbitMQ	n8n → RabbitMQ	Publish messages to a queue or exchange
RabbitMQ Trigger	RabbitMQ → n8n	Subscribe to a queue; fires on each message

The standard RabbitMQ node publishes. The Trigger node consumes. You'll often use both in the same workflow system — one workflow publishes jobs, another consumes and processes them.

Prerequisites

A running RabbitMQ broker (local Docker, CloudAMQP, Amazon MQ, or self-hosted)
A queue or exchange already created (or you'll create one below)
AMQP connection URL or host/port/credentials

Step 1: Configure RabbitMQ Credentials

In n8n, go to Credentials → New → RabbitMQ.

Fields

Field	Description
Hostname	Your broker hostname, e.g. `rabbitmq.example.com`
Port	Default `5672` (AMQP) or `5671` (AMQPS/TLS)
Username / Password	RabbitMQ user credentials
Vhost	Virtual host (default `/`)
SSL	Toggle on for TLS; paste CA cert and client certs if needed

CloudAMQP Example

If you're using CloudAMQP (free tier available), your connection URL looks like:

amqps://user:password@rat.rmq2.cloudamqp.com/vhost

Extract each field from the URL and fill in the credential form.

Local Docker

docker run -d --name rabbitmq \
  -p 5672:5672 -p 15672:15672 \
  rabbitmq:3-management

Default credentials: guest / guest, vhost /.

Step 2: Publish a Message (RabbitMQ Node)

Add a RabbitMQ node to your workflow.

Configuration

Field	Value
Mode	Queue (direct to queue) or Exchange (routed via exchange)
Queue / Exchange	Name of target queue or exchange
Routing Key	Required for exchange mode; matches binding keys on queues
Message	The message body (string, JSON, or expression)
Options → Headers	Key-value pairs added as AMQP message headers

Queue Mode (Simplest)

Set Mode to Queue, enter the queue name (e.g. jobs), and set your message:

{{ $json.toJsonString() }}

Every item from the previous node becomes one message in the queue.

Exchange Mode (Routing)

Set Mode to Exchange, enter your exchange name (e.g. orders), and set the routing key (e.g. order.created).

RabbitMQ routes the message to every queue bound to that exchange with a matching binding key.

Step 3: Consume Messages (RabbitMQ Trigger)

Add a RabbitMQ Trigger node as the first node in a workflow.

Configuration

Field	Value
Queue	Name of queue to subscribe to
Acknowledge	`Automatically` (ACK on receive) or `Manually` (ACK after processing)
Options → Content is Binary	Toggle on for binary payloads
Options → JSON Parse Body	Parse JSON body automatically

Acknowledge Mode

Automatically: n8n ACKs the message as soon as it's received. Simpler but if your workflow crashes mid-run, the message is lost.
Manually: Use a second RabbitMQ node at the end of the workflow with operation Acknowledge to ACK only after successful processing. This guarantees at-least-once delivery.

Step 4: Exchanges and Routing Keys

RabbitMQ supports four exchange types:

Type	Behavior
Direct	Routes to queues where binding key == routing key
Fanout	Broadcasts to all bound queues (ignores routing key)
Topic	Pattern matching: `order.*` matches `order.created`, `order.shipped`
Headers	Routes based on message header values

Topic Exchange Example

Exchange: events (type: topic)

Bindings:

Queue orders-service bound with order.*
Queue notifications-service bound with # (matches everything)

When you publish with routing key order.refunded:

orders-service receives it (matches order.*)
notifications-service receives it (matches #)

Step 5: Durable Queues and Persistent Messages

By default, queues and messages may be lost on broker restart. For production:

Durable Queue

Create the queue with durable: true (set in RabbitMQ management UI or via API). n8n's credential connection inherits the queue's durability settings — you don't set durability per-message in n8n, but the queue must be declared durable before n8n uses it.

Persistent Messages

In the RabbitMQ node Options, set Delivery Mode to 2 (persistent). RabbitMQ writes persistent messages to disk before ACKing.

Delivery Mode: 2

Without this, messages are in-memory only and lost on broker restart.

Real-World Patterns

Pattern 1: Async Job Queue

[Webhook] → [RabbitMQ: Publish to "jobs" queue]

[RabbitMQ Trigger: Subscribe "jobs"] → [HTTP Request: Process job] → [RabbitMQ: ACK]

The webhook immediately returns 200 while jobs are processed asynchronously. Workers auto-scale by running multiple n8n instances consuming the same queue (RabbitMQ round-robins messages).

Pattern 2: Event Fan-Out

[Schedule Trigger] → [HTTP Request: Fetch orders] → [RabbitMQ: Publish to "events" fanout exchange]

  ↳ [RabbitMQ Trigger: "billing-queue"] → [Process billing]
  ↳ [RabbitMQ Trigger: "fulfillment-queue"] → [Process fulfillment]
  ↳ [RabbitMQ Trigger: "analytics-queue"] → [Log to data warehouse]

One publish event reaches all three downstream workflows.

Pattern 3: Priority Queue

RabbitMQ supports queue priorities (0–255). Declare the queue with x-max-priority: 10 in management UI. In n8n, set Options → Priority on the publish node to route urgent messages ahead of normal ones.

Pattern 4: Dead Letter Queue (DLQ)

Configure a queue with a dead-letter exchange:

In RabbitMQ management: set x-dead-letter-exchange on the main queue
Messages that are rejected or expire get routed to the DLQ

In n8n: use a separate RabbitMQ Trigger on the DLQ queue to alert on failed messages or retry them.

Common Errors and Fixes

`Connection refused` / `ECONNREFUSED`

Broker isn't running or hostname is wrong
Check port: 5672 for AMQP, 5671 for AMQPS
If using Docker, ensure the container is healthy: docker ps

`ACCESS_REFUSED — Login was refused`

Wrong username/password or vhost
Default credentials (guest/guest) only work from localhost by default in RabbitMQ — create a dedicated user for remote connections

`CHANNEL_ERROR — no queue 'xyz' in vhost '/'`

Queue doesn't exist yet. Create it in the management UI (port 15672) or via the RabbitMQ HTTP API before n8n connects.

`Message is not JSON parseable`

Toggle off JSON Parse Body in the trigger node options, or ensure the publisher sends valid JSON

`ACK timeout`

You're using Manual acknowledge mode but never ACK'd the message
Ensure the workflow ends with a RabbitMQ node set to Acknowledge mode, pointing to the same queue

Free Workflow JSON

Here's a complete async job queue workflow — webhook receives a job, publishes to RabbitMQ, and a separate trigger processes it:

{
  "name": "n8n RabbitMQ Async Job Queue",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "submit-job",
        "responseMode": "lastNode",
        "options": {}
      },
      "name": "Webhook",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 1,
      "position": [240, 300]
    },
    {
      "parameters": {
        "mode": "queue",
        "queue": "jobs",
        "content": "={{ JSON.stringify($json) }}",
        "options": {
          "deliveryMode": 2
        }
      },
      "name": "Publish to RabbitMQ",
      "type": "n8n-nodes-base.rabbitmq",
      "typeVersion": 1,
      "position": [460, 300],
      "credentials": {
        "rabbitmq": {
          "id": "1",
          "name": "RabbitMQ account"
        }
      }
    },
    {
      "parameters": {
        "queue": "jobs",
        "options": {
          "jsonParseBody": true,
          "onlyContent": true,
          "acknowledge": "executionFinishes"
        }
      },
      "name": "RabbitMQ Trigger",
      "type": "n8n-nodes-base.rabbitmqTrigger",
      "typeVersion": 1,
      "position": [240, 520],
      "credentials": {
        "rabbitmq": {
          "id": "1",
          "name": "RabbitMQ account"
        }
      }
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://your-api.example.com/process",
        "sendBody": true,
        "bodyParameters": {
          "parameters": [
            {
              "name": "job",
              "value": "={{ $json }}"
            }
          ]
        },
        "options": {}
      },
      "name": "Process Job",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [460, 520]
    }
  ],
  "connections": {
    "Webhook": {
      "main": [[{"node": "Publish to RabbitMQ", "type": "main", "index": 0}]]
    },
    "RabbitMQ Trigger": {
      "main": [[{"node": "Process Job", "type": "main", "index": 0}]]
    }
  }
}

To use this:

Import into n8n (Settings → Import Workflow)
Add your RabbitMQ credentials
Create the jobs queue in your RabbitMQ management UI (mark as durable)
Activate both workflows
POST to the webhook URL to publish a test job

Key Takeaways

RabbitMQ node publishes; RabbitMQ Trigger consumes — you need both for a full pipeline
Use exchange mode with routing keys for fan-out and topic-based routing
Set Delivery Mode 2 + durable queues for production (survives broker restart)
Use Manual ACK for at-least-once processing guarantees
Dead-letter queues + n8n triggers give you a built-in retry/alert layer

Want the n8n Workflow Starter Pack? It includes 10 production-ready workflow JSONs — Stripe webhooks, lead capture, scheduled reports, AI pipelines, and more:

👉 n8n Workflow Starter Pack ($29)

Drop a comment: are you using RabbitMQ for task queues, event streaming, or service decoupling?

Top comments (1)

Pirate Prentice • Jul 2

Thanks for reading! A couple of common questions I see around RabbitMQ + n8n:

Q: What's the difference between using the Kafka node vs. RabbitMQ node in n8n?
Kafka is built for high-throughput log streaming and replay — great for event sourcing. RabbitMQ excels at job queues, routing, and task dispatch with fine-grained ack control. Choose RabbitMQ when you need routing keys, per-message TTL, or priority queues.

Q: Can I use RabbitMQ as a rate limiter in n8n?
Yes — publish tasks to a queue and have a single consumer workflow process them one at a time. It's a simple way to serialize API calls that have strict rate limits.

Are you using RabbitMQ for async jobs, fan-out events, or something else? Drop your use case below 👇

What the n8n RabbitMQ Node Does

Prerequisites

Step 1: Configure RabbitMQ Credentials

Fields

CloudAMQP Example

Local Docker

Step 2: Publish a Message (RabbitMQ Node)

Configuration

Queue Mode (Simplest)

Exchange Mode (Routing)

Step 3: Consume Messages (RabbitMQ Trigger)

Configuration

Acknowledge Mode

Step 4: Exchanges and Routing Keys

Topic Exchange Example

Step 5: Durable Queues and Persistent Messages

Durable Queue

Persistent Messages

Real-World Patterns

Pattern 1: Async Job Queue

Pattern 2: Event Fan-Out

Pattern 3: Priority Queue

Pattern 4: Dead Letter Queue (DLQ)

Common Errors and Fixes

Connection refused / ECONNREFUSED

ACCESS_REFUSED — Login was refused

CHANNEL_ERROR — no queue 'xyz' in vhost '/'

Message is not JSON parseable

ACK timeout

Free Workflow JSON

Key Takeaways

`Connection refused` / `ECONNREFUSED`

`ACCESS_REFUSED — Login was refused`

`CHANNEL_ERROR — no queue 'xyz' in vhost '/'`

`Message is not JSON parseable`

`ACK timeout`