Overview

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

LlamaCloud uses a few external dependencies — Postgres, Redis, and Temporal are always required; MongoDB and RabbitMQ are required for the full feature surface but can be omitted with the store-less minimal profile (see below).

Requirements

We officially support the following versions of the dependencies:

• Postgres
  • Minimum Version >=15.x
  • Admin Access to the database. LlamaCloud will read/write and apply migrations.
  • We recommend 1 - 2 vCPUs and 1 - 2 GBi RAM as a starting point for the database. As your usage grows, you can scale the database accordingly.
  • When Postgres is also the Index vector-store target (the minimal profile’s default), the server must have the pgvector extension installed — LlamaCloud runs CREATE EXTENSION IF NOT EXISTS vector on first index export. See Index Configuration.
  • Recommended Managed Services:
    • Amazon RDS
    • Azure Database for PostgreSQL
    • Google Cloud SQL
• MongoDB — optional (see minimal profile)
  • Minimum Version >=7.x
  • We recommend 1 - 2 vCPUs and 1 - 2 GBi RAM as a starting point for the database. As your usage grows, you can scale the database accordingly.
  • Recommended Managed Services:
    • Amazon DocumentDB
    • Azure Cosmos DB
    • Google Cloud
• RabbitMQ — optional (see minimal profile)
  • Minimum Version >=3.11.x
  • We recommend 200 - 500m vCPUs and 500Mi - 2GBi RAM as a starting point for the database. As your usage grows, you can scale the database accordingly.
  • Recommended Managed Services:
    • Amazon MQ
    • Azure Service Bus — see setup: Azure Service Bus as Job Queue
    • Google Cloud Marketplace
• Redis
  • Minimum Version >=7.x
  • We recommend 200 - 500m vCPUs and 500Mi - 2GBi RAM as a starting point for the database. As your usage grows, you can scale the database accordingly.
  • Recommended Managed Services:
    • Amazon ElastiCache
    • Azure Cache for Redis
    • Google Cloud Memorystore
• Temporal

Store-less deployments (minimal profile)

MongoDB and RabbitMQ can be omitted entirely by setting mongodb.enabled: false and rabbitmq.enabled: false in your Helm values — the chart then injects MONGO_DISABLED / AMQP_DISABLED, renders no store secrets, and skips the AMQP jobs-worker Deployment. The chart ships a preset overlay for this shape:

helm install llamacloud . -f my-values.yaml -f examples/profiles/minimal.yaml

Feature surface under the minimal profile:

• Works end to end (Temporal + PostgreSQL + Redis): Parse, Extract, and Index — directory sync, export, retrieval, and chat against the postgres (pgvector) index target.
• Returns cause-coded 4xx errors instead of accepting work it cannot run: v1 parse, pipelines (the legacy pipeline API surface), retrieval over pipeline documents, and the mongodb index export destination.

The minimal preset pins the default index destination to postgres; the vector-store connection inherits your inline postgresql.* values automatically (see Index Configuration for details and the pgvector requirement).

External Dependency Configuration

To connect your LlamaCloud deployment to an external dependency, configure the necessary sections in your values.yaml file.

With Temporal Subchart (Recommended)

postgresql:
  host: "postgresql"
  port: "5432"
  database: "llamacloud"
  username: "llamacloud"
  password: "llamacloud"

mongodb:
  host: "mongodb"
  port: "27017"
  username: "root"
  password: "password"

rabbitmq:
  scheme: "amqp"
  host: "rabbitmq"
  port: "5672"
  username: "guest"
  password: "guest"

redis:
  scheme: "redis"
  host: "redis-master"
  port: "6379"
  db: 0

# Deploy Temporal as a subchart (host/port auto-configured)
temporal:
  deploy: true

# Temporal subchart configuration.
# The Temporal store password comes from your postgresql.password —
# the chart generates the temporal-postgresql-secret automatically.
temporal-subchart:
  server:
    config:
      persistence:
        defaultStore: default
        visibilityStore: visibility
        datastores:
          default:
            sql:
              connectAddr: "<postgresql-host>:5432"
              databaseName: temporal
              user: <username>
          visibility:
            sql:
              connectAddr: "<postgresql-host>:5432"
              databaseName: temporal_visibility
              user: <username>

External Temporal

postgresql:
  host: "postgresql"
  port: "5432"
  database: "llamacloud"
  username: "llamacloud"
  password: "llamacloud"

mongodb:
  host: "mongodb"
  port: "27017"
  username: "root"
  password: "password"

rabbitmq:
  scheme: "amqp"
  host: "rabbitmq"
  port: "5672"
  username: "guest"
  password: "guest"

redis:
  scheme: "redis"
  host: "redis-master"
  port: "6379"
  db: 0

# Use an existing external Temporal deployment
temporal:
  deploy: false
  host: temporal-frontend
  port: 7233

Note

Temporal store password (Kubernetes Secret). The subchart datastores.*.sql blocks above deliberately omit password. The LlamaCloud chart’s default temporal-subchart values point both stores at a Kubernetes Secret — existingSecret: temporal-postgresql-secret, secretKey: password. When temporal.deploy: true, the chart auto-generates that temporal-postgresql-secret from your postgresql.password as a pre-install/pre-upgrade hook (so it exists before the Temporal schema job mounts it), so you do not create it by hand. To use a different credential, change postgresql.password, or override temporal-subchart.server.config.persistence.datastores.<store>.sql.existingSecret / secretKey to reference a Secret you manage yourself.

The examples below install each store with the Bitnami Helm charts.

Caution

Install every backing store into the same namespace as your LlamaCloud release by adding --namespace <your-namespace> to each helm upgrade --install command below. The LlamaCloud values reference bare in-cluster hostnames (postgresql, mongodb, rabbitmq, redis-master), which only resolve when the stores live in the same namespace.

Each chart also requests a PersistentVolumeClaim with no explicit StorageClass. If your cluster has no default StorageClass — Amazon EKS does not create one by default — the claims stay Pending and the pods never schedule. Either mark a StorageClass as default, or add a global.storageClass: <name> block to each values file below.

Example Postgresql Configuration

Example Postgresql installation:

helm upgrade --install postgresql \
    oci://registry-1.docker.io/bitnamicharts/postgresql \
    -f postgresql.yaml --wait --timeout 10m

postgresql.yaml

image:
  registry: docker.io
  repository: bitnamilegacy/postgresql

auth:
  enabled: true
  database: llamacloud
  username: llamacloud
  password: llamacloud

## Ref: https://github.com/bitnami/charts/blob/main/bitnami/postgresql/values.yaml#L481
primary:
  resources:
    requests:
      cpu: 250m
      memory: 128Mi
    limits:
      cpu: 250m
      memory: 256Mi

global:
  security:
    allowInsecureImages: true

resourcesPreset: micro

Example MongoDB Configuration

Example MongoDB installation:

helm upgrade --install \
  mongodb oci://registry-1.docker.io/bitnamicharts/mongodb \
  -f mongodb.yaml --wait --timeout 10m

mongodb.yaml

image:
  registry: ghcr.io
  repository: xavidop/mongodb
  tag: '7.0'

auth:
  enabled: true
  rootUser: root
  rootPassword: password

global:
  security:
    allowInsecureImages: true

resourcesPreset: micro

Example Redis Configuration

Example Redis installation:

helm upgrade --install redis \
  oci://registry-1.docker.io/bitnamicharts/redis \
  -f redis.yaml --wait --timeout 10m

redis.yaml

image:
  registry: docker.io
  repository: bitnamilegacy/redis

auth:
  enabled: false
  #password: "password"

tls:
  enabled: false

architecture: standalone

global:
  security:
    allowInsecureImages: true

resourcesPreset: micro

Example RabbitMQ Configuration

Example RabbitMQ installation:

helm upgrade --install rabbitmq \
  oci://registry-1.docker.io/bitnamicharts/rabbitmq \
  -f rabbitmq.yaml --wait --timeout 10m

rabbimq.yaml

image:
  registry: docker.io
  repository: bitnamilegacy/rabbitmq
  digest: sha256:8a36cf44a55be2ae25cafa0376b89041412c50bbcab9fa0109713d60b2ec06fb

global:
  security:
    allowInsecureImages: true

auth:
  username: guest
  password: guest
  erlangCookie: secretcookie

resourcesPreset: micro

Example Temporal Configuration

LlamaCloud supports two approaches for deploying Temporal:

Option 1: Deploy Temporal as a Subchart (Recommended)

The simplest way to deploy Temporal is as a subchart within LlamaCloud. This approach automatically configures the Temporal host and port for LlamaCloud services.

In your values.yaml, set temporal.deploy: true and configure the temporal-subchart section:

# Deploy Temporal as a subchart
temporal:
  deploy: true

# Temporal subchart configuration
temporal-subchart:
  serviceAccount:
    create: true
    name: temporal-server

  web:
    additionalEnv:
      - name: TEMPORAL_CSRF_COOKIE_INSECURE
        value: "true"
    service:
      port: 80

  server:
    config:
      persistence:
        defaultStore: default
        visibilityStore: visibility
        datastores:
          default:
            sql:
              driverName: postgres12
              pluginName: postgres12
              connectAddr: "<postgresql-host>:5432"
              connectProtocol: tcp
              databaseName: temporal
              user: <username>
              maxConns: 20
              maxIdleConns: 20
              maxConnLifetime: "1h"

          visibility:
            sql:
              driverName: postgres12
              pluginName: postgres12
              connectAddr: "<postgresql-host>:5432"
              connectProtocol: tcp
              databaseName: temporal_visibility
              user: <username>
              # createDatabase/manageSchema default to true in the LlamaCloud chart,
              # so the schema job provisions the databases and schema automatically.
              maxConns: 20
              maxIdleConns: 20
              maxConnLifetime: "1h"

Note

As in the subchart example above, the datastore password is not set inline. The chart references a Kubernetes Secret (existingSecret: temporal-postgresql-secret, key password) and, under temporal.deploy: true, auto-generates that Secret from your postgresql.password. See the Temporal store password note above to supply your own.

Tip

When using temporal.deploy: true, you don’t need to specify temporal.host or temporal.port - these are automatically configured to point to the subchart’s frontend service.

Option 2: Use an External Temporal Deployment

If you already have a Temporal deployment or prefer to manage Temporal separately, you can connect LlamaCloud to an external Temporal instance.

First, install Temporal separately:

helm install --repo https://go.temporal.io/helm-charts \
  temporal temporal -f temporal.yaml

temporal.yaml

serviceAccount:
  create: true
  name: temporal-server

web:
  additionalEnv:
    - name: TEMPORAL_CSRF_COOKIE_INSECURE
      value: "true"
  service:
    port: 80

server:
  config:
    namespaces:
      create: true
    persistence:
      defaultStore: default
      visibilityStore: visibility
      datastores:
        default:
          sql:
            driverName: postgres12
            pluginName: postgres12
            connectAddr: "<hostname>:5432"
            connectProtocol: tcp
            databaseName: temporal
            user: <username>
            password: <password>
            # Have the chart's schema job create the database and manage the schema.
            createDatabase: true
            manageSchema: true
            maxConns: 20
            maxIdleConns: 20
            maxConnLifetime: "1h"

        visibility:
          sql:
            driverName: postgres12
            pluginName: postgres12
            connectAddr: "<hostname>:5432"
            connectProtocol: tcp
            databaseName: temporal_visibility
            user: <username>
            password: <password>
            createDatabase: true
            manageSchema: true
            maxConns: 20
            maxIdleConns: 20
            maxConnLifetime: "1h"

Caution

The Temporal Helm chart (v1.0.0+) removed the bundled cassandra, mysql, postgresql, prometheus, grafana, and elasticsearch sub-charts and the top-level schema: block, and replaced persistence.default / persistence.visibility with persistence.datastores.<name> + defaultStore / visibilityStore. Database creation and schema management now live on each datastore (createDatabase / manageSchema). The snippet above uses the current schema — the older shape hard-fails helm install with '...' is no longer supported.

Then configure LlamaCloud to connect to your external Temporal:

# LlamaCloud values.yaml
temporal:
  deploy: false
  host: temporal-frontend  # Your Temporal frontend service name
  port: 7233

Connecting to the Temporal datastore over TLS

If your SQL datastore requires TLS — common with managed databases such as Amazon RDS, Azure Database for PostgreSQL, or Cloud SQL — enable TLS on each Temporal datastore under persistence.datastores.<store>.sql.tls and mount the certificate files into the Temporal pods. The example below uses the bundled subchart (temporal.deploy: true); the same server / admintools structure applies to an external Temporal deployment.

1. Create a Secret with your certificates

Create a Kubernetes Secret in the release namespace holding at least the CA bundle (add a client cert/key only if your database requires mutual TLS):

kubectl create secret generic temporal-db-tls -n <namespace> \
  --from-file=ca.pem=./ca.pem
# For mutual TLS, also add:
#   --from-file=client.pem=./client.pem \
#   --from-file=client-key.pem=./client-key.pem

2. Enable TLS on both datastores and mount the certs

temporal:
  deploy: true

temporal-subchart:
  server:
    config:
      persistence:
        defaultStore: default
        visibilityStore: visibility
        datastores:
          default:
            sql:
              connectAddr: "postgresql:5432"
              databaseName: temporal
              user: <username>
              tls:
                enabled: true
                caFile: /etc/temporal/tls/ca.pem
                enableHostVerification: true
                serverName: <db-hostname-in-cert>   # must match the DB certificate SAN
                # For mutual TLS, also set:
                # certFile: /etc/temporal/tls/client.pem
                # keyFile: /etc/temporal/tls/client-key.pem
          visibility:
            sql:
              connectAddr: "postgresql:5432"
              databaseName: temporal_visibility
              user: <username>
              tls:
                enabled: true
                caFile: /etc/temporal/tls/ca.pem
                enableHostVerification: true
                serverName: <db-hostname-in-cert>

    # Mount the cert Secret into the running Temporal server pods
    additionalVolumes:
      - name: temporal-db-tls
        secret:
          secretName: temporal-db-tls
    additionalVolumeMounts:
      - name: temporal-db-tls
        mountPath: /etc/temporal/tls
        readOnly: true

  # Mount it into admintools as well — see the caution below.
  admintools:
    additionalVolumes:
      - name: temporal-db-tls
        secret:
          secretName: temporal-db-tls
    additionalVolumeMounts:
      - name: temporal-db-tls
        mountPath: /etc/temporal/tls
        readOnly: true

Caution

caFile / certFile / keyFile are paths inside the container, so they only exist where you mount the Secret — and you must mount it in both server and admintools. The running Temporal server pods read server.additionalVolumes, but the schema setup/update Job (which creates the databases and applies migrations) runs from the admin-tools image and reads admintools.additionalVolumes. Mounting only server is the most common failure: the schema Job can’t reach the database over TLS, so a fresh install hangs on helm --wait and never completes.

Set serverName to the hostname in your database’s server certificate (its SAN), and keep enableHostVerification: true for production — only disable host verification when testing against self-signed certificates.

Complete Configuration Reference

For the most up-to-date and comprehensive configuration options, refer directly to our Helm repository:

• Complete values.yaml reference - Full configuration options with detailed comments
• External dependencies example - Complete working example for external dependencies
• Helm chart documentation - Generated documentation with all configuration parameters

Tip

The Helm repository is the authoritative source for configuration. It’s always up-to-date with the latest chart version and includes working examples and tests.