Migrating off RabbitMQ

Self-Hosting Documentation Access

This section requires a password to access. Interested in self-hosting? Contact sales to learn more.

Password:

Access Documentation

Self-Hosting Documentation Access Granted Logout

RabbitMQ is being removed from LlamaCloud. Temporal is now the default job transport, and a future release will drop the AMQP code path entirely. This page walks through moving an existing deployment across ahead of that.

For most deployments the move is smaller than it looks. Parse, Extract, and Index all run on Temporal already, and on current releases they do so by default rather than because you configured it. The only feature still tied to RabbitMQ is the legacy Pipelines surface.

Note

On releases before this change, AMQP was the default transport for the v1 Parse API and Temporal was opt-in. That is now reversed: Temporal is the default and AMQP is the legacy path a deployment has to opt back into. If you never set the transport yourself, upgrading moves you onto Temporal with no action needed.

What still uses RabbitMQ

Temporal is enabled in every supported configuration, and is the default transport:

Feature	Transport	Needs RabbitMQ
Parse (v2)	Temporal	No
Parse (v1)	Temporal	No
Extract	Temporal	No
Index directory sync, export, retrieval, chat	Temporal	No
Legacy Pipelines	RabbitMQ	Yes

“Legacy Pipelines” means the older pipeline-centric ingestion API: creating and upserting pipelines, pipeline sync, pipeline data-source and file updates, metadata updates, and managed document ingestion. Its replacement is Index, which syncs a source directory to a vector store over Temporal.

Note

Parse v1 is dispatched as a Temporal workflow, not an AMQP publish. Staying on the v1 Parse API does not hold up this migration. It does still write job records to MongoDB, so keep MongoDB (see below).

Before you start

• MongoDB stays. This migration removes RabbitMQ only. Parse v1 and Extract still write job records to MongoDB, so removing it as well will break them. If you want to drop both stores, that is the separate minimal profile, which also gives up the v1 Parse API.
• Upgrade first. Two things landed together that this migration depends on: Temporal became the default transport, and the Parse v1 admission gate became aware of it. On older releases, switching RabbitMQ off refuses v1 Parse with a 410 even though the job would have run. Upgrade to the current release before applying the profile.
• Do not pin the transport back to AMQP. If you explicitly lowered the v1 Parse transport dial in your own values or environment, raise it back to 100 (or simply remove your override and take the default). Below 100 a share of jobs still take the AMQP branch, and on a Rabbit-less deployment those are refused at admission rather than stranded.
• Check what you actually use. The step below is the whole migration for most deployments.

Step 1: Confirm you are not using legacy Pipelines

Ask your API key’s organization for its pipelines:

curl -s "$HOST/api/v1/pipelines" \
  -H "Authorization: Bearer $LLAMA_CLOUD_API_KEY" | jq 'length'

If that returns 0, nothing in your deployment depends on RabbitMQ and you can go straight to step 2.

If it returns anything else, those pipelines must move to Index before you turn RabbitMQ off. Recreate each one as an Index against the same data source and vector store, re-sync it, and repoint your clients at the Index retrieval endpoints. See Index Configuration for the supported vector-store targets and their requirements.

Caution

Do not skip this check because your application only calls Parse. Some integrations create a pipeline implicitly. If step 1 returns a non-zero count, find out what created them before continuing, or those calls will start returning 410 after step 2.

Step 2: Apply the no-RabbitMQ profile

The chart ships a preset overlay. Layer it on top of your existing values:

helm upgrade --install llamacloud llamaindex/llamacloud \
  -f my-values.yaml \
  -f examples/profiles/no-rabbitmq.yaml \
  --namespace llamacloud

Or set the two values inline:

rabbitmq:
  enabled: false

# llamacloud-parse is the v1 AMQP parse worker. With no queue to consume it
# would idle, so scale it to zero. Parse runs on the Temporal worker instead.
llamaParse:
  replicas: 0

Remove your rabbitmq: connection block (host, port, username, password, scheme) at the same time. With enabled: false the chart renders no RabbitMQ secret and creates no AMQP jobs-worker Deployment, so those values are no longer read.

Step 3: Verify

Two workloads should change, and nothing else:

# The AMQP jobs-worker is gone; the Temporal one remains.
kubectl get deploy -n llamacloud | grep -E 'worker|parse'
#   llamacloud-parse            0/0     <- v1 AMQP parse worker, scaled to zero
#   llamacloud-temporal-parse   1/1     <- Parse runs here
#   temporal-jobs-worker        1/1     <- jobs run here
#   (llamacloud-worker is absent)

# The deployment knows AMQP is off, and Parse v1 is routed to Temporal.
kubectl get configmap common-config -n llamacloud \
  -o jsonpath='{.data.AMQP_DISABLED}{"\n"}{.data.V1_PARSE_VIA_TEMPORAL_PERCENTAGE}{"\n"}'
#   true
#   100

Both of those values are managed for you. AMQP_DISABLED comes from rabbitmq.enabled, and the transport percentage is 100 by default and is also pinned by the chart whenever Temporal is enabled. They are listed here so you can confirm the state you ended up in, not so you can set them by hand.

Helm also prints a deprecation notice after every install or upgrade while rabbitmq.enabled is still true, so you can tell at a glance whether a deployment has been migrated.

Then run a real job end to end. Submit a Parse job and wait for SUCCESS, and if you use Index, trigger a sync and confirm it completes.

Once you are satisfied, decommission the RabbitMQ instance itself.

Step 4: Remove RabbitMQ

Only after step 3 passes. If you installed it in-cluster with the Bitnami chart:

helm uninstall rabbitmq --namespace llamacloud

If you use a managed broker, delete it in your cloud provider’s console. Nothing in LlamaCloud reads it after step 2.

What returns an error afterwards

Requests to the legacy Pipelines surface return 410 Gone with a message naming the cause, rather than being accepted and hanging:

{
  "detail": "Pipelines is unavailable on this deployment: it requires RabbitMQ, which is disabled (AMQP_DISABLED=true). Use the v2 API instead."
}

This is deliberate. A fire-and-forget publish to a broker that is not there would otherwise return 202 and never complete.

Rolling back

The migration is reversible up until you delete the broker. Re-enable RabbitMQ, restore your rabbitmq: connection block, and upgrade:

helm upgrade llamacloud llamaindex/llamacloud -f my-values.yaml --namespace llamacloud

The AMQP jobs-worker comes back and the legacy Pipelines surface starts serving again. Jobs that returned 410 while it was off were never created, so there is nothing to reconcile; resubmit them.