--- title: Migrating off RabbitMQ | Developer Documentation description: Move a self-hosted LlamaCloud deployment from RabbitMQ to Temporal: what still uses AMQP, how to confirm your deployment is ready, the Helm profile that turns it off, and how to verify and roll back. --- ## Self-Hosting Documentation Access This section requires a password to access. Interested in self-hosting? [Contact sales](https://www.llamaindex.ai/contact) 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](/llamaparse/self_hosting/configuration/index-v2-configuration/index.md), 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](/llamaparse/self_hosting/configuration/db_and_queues/overview#store-less-deployments-minimal-profile/index.md), 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: Terminal window ``` 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](/llamaparse/self_hosting/configuration/index-v2-configuration/index.md) 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: Terminal window ``` 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: Terminal window ``` # 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: Terminal window ``` 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: Terminal window ``` 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.