Optional Feature Flags

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 exposes a small set of optional environment-variable flags that toggle UI or behavior in self-hosted deployments. These are in addition to the defaults already baked into the Helm chart.

All flags are set via extraEnvVariables on the relevant pod (typically frontend) in your values.yaml.

Frontend flags

Frontend flags are environment variables read by the LlamaCloud web app. Flags without a NEXT_PUBLIC_ prefix are resolved server-side at request time, so they respond to ConfigMap / extraEnvVariables changes without rebuilding the image. NEXT_PUBLIC_* flags are inlined into the client bundle at build time and cannot be changed at runtime.

Flag	Default (BYOC)	Purpose
IS_INDEX_V1_ENABLED	true	Show the Index entry in the sidebar and on the project home page. Set to false to hide.
NEXT_PUBLIC_IS_INDEX_PARSE_EDIT_DISABLED	false	Disable parse-config editing on an existing index (build-time inlined).

Overriding a frontend flag

To override a default, add it to frontend.extraEnvVariables in your values.yaml:

frontend:
  extraEnvVariables:
    - name: IS_INDEX_V1_ENABLED
      value: "false"

Values must be strings ("true" / "false").

Backend flags

Backend feature flags are read by the LlamaCloud API from the backend pod env. They follow the IS_*_ENABLED / IS_*_DISABLED naming convention.

Flag	Default	Purpose
IS_INDEX_PARSE_EDIT_DISABLED	false	Server-side counterpart to NEXT_PUBLIC_IS_INDEX_PARSE_EDIT_DISABLED.
IS_MANAGED_EMBEDDINGS_ENABLED	false	Enable managed embeddings as a default option for new indexes. Prefer the config.managedEmbeddings.enabled chart value (below), which sets this for both backend and frontend.
IS_TEMPORAL_EXTRACT_ENABLED	false	Route new extract jobs through Temporal.
IS_NEW_DATA_CONNECTION_SSRF_PROTECTION_ENABLED	false for self-hosted	Require data sink, data source, and embedding model config endpoints to resolve to public addresses when they are created or updated. Off by default on a self-hosted deployment, where you own the network these endpoints reach. See SSRF protection for data connections.

Overriding a backend flag

backend:
  extraEnvVariables:
    - name: IS_INDEX_PARSE_EDIT_DISABLED
      value: "true"

LlamaParse worker flags

Read by the LlamaParse worker from the llamaParse pod env.

Flag	Default (BYOC)	Purpose
PARSE_URL_BLOCK_INTERNAL_TARGETS	true	Refuse to fetch a parse input URL, or any redirect it follows, that addresses a non-public network target. Set to false to parse from URLs on your own private network.

llamaParse:
  extraEnvVariables:
    - name: PARSE_URL_BLOCK_INTERNAL_TARGETS
      value: "false"

Parsing from URLs on a private network

The worker flag alone is not enough. The API also validates submitted URLs and rejects non-public hosts with 400 Invalid source URL, so list the hostnames on the backend as well:

backend:
  extraEnvVariables:
    - name: SSRF_ALLOWED_HOSTS
      value: "docs.internal.example.com,files.internal.example.com"

Hostnames match exactly, ignoring case. No wildcards, ports, or schemes.

Both settings cover fetching the input URL. Sub-resources loaded while rendering HTML to PDF, such as images, stylesheets, and iframes, are always restricted to public hosts, so a page from a private host renders without the assets served there.

Neither setting replaces a network egress policy on the LlamaParse worker pod. If the pod can reach a metadata service or an internal control plane, restrict that at the network layer.

SSRF protection for data connections

Data sinks, data sources, and embedding model configs are all configured with connection endpoints you supply — a Qdrant url, a Postgres host, an Astra DB api_endpoint, a Confluence server_url, a MongoDB connection string, an OpenAI-compatible api_base, and so on. LlamaCloud dials those endpoints from inside your cluster, so an endpoint pointing at an internal service or a cloud metadata address is a Server-Side Request Forgery risk.

IS_NEW_DATA_CONNECTION_SSRF_PROTECTION_ENABLED defaults to false on a self-hosted deployment, because the endpoints you configure legitimately name hosts inside your own network. Set it to true to check those endpoints everywhere connection details are supplied:

• Creating, updating, or upserting through /api/v1/data-sinks, /api/v1/data-sources, or /api/v1/embedding-model-configs.
• Creating or updating a pipeline through /api/v1/pipelines with an inline data_sink or embedding_config rather than an id.
• Testing a connection through /api/v1/validate-data-sink-connection, /api/v1/validate-data-source-connection, or /api/v1/validate-embedding-connection.

The check runs before LlamaCloud validates the connection, so a rejected endpoint is never contacted. The fields checked are api_base (OpenAI-compatible and Gemini), azure_endpoint, the VertexAI token_uri, and the HuggingFace model_name when it holds a dedicated-endpoint URL rather than a model id. Every host named by the endpoint must resolve only to publicly routable addresses; private, loopback, link-local, reserved, and multicast addresses are rejected. Creating or updating a resource returns a 400; the validate-*-connection endpoints report the rejection as a failed validation result. mongodb+srv:// connection strings are resolved through their SRV records and every target is checked, and a connection string naming many hosts is rejected if it names more than 32.

Diagnosing a rejected connection

The error names the field that was rejected but not the address it resolved to, so the check cannot be used to probe your internal network. The specifics — the blocked host, the project, and the user — go to the backend logs instead, and the two are tied together by a correlation id:

The data sink field 'url' must point to a publicly routable host.
Contact support with correlation id 4f9a2c18-....

That id is also on the X-Correlation-ID response header of every API response. To find the offending host, search the backend logs for it:

kubectl logs -n <namespace> deploy/backend | grep 4f9a2c18-

The matching line carries blocked_host, reason, field_name, component_type, project_id, and user_id.

Blocks are also counted, so you can see how many connections the check is rejecting without reading logs. Both counters are exported on the backend’s metrics endpoint:

Metric	Labels	Meaning
llamacloud_ssrf_data_connection_ssrf_blocked_total	connection_kind, scope, reason	Connection endpoints rejected by the check. reason is one of value_too_long, no_readable_host, too_many_hosts, host_not_publicly_routable.
llamacloud_ssrf_data_connection_ssrf_unregistered_total	component_type	A component type whose endpoints were not validated. Expected to stay at zero.

Watch the first counter after turning the check on: a jump means connections that used to work are now being rejected, and the hosts involved are in the logs.

Allowing internal hosts

If you turn the check on, a self-hosted deployment still needs to reach vector stores and Confluence instances on a private network. Allowlist those hosts rather than turning the check back off. There are two ways to do it, and they combine.

By exact hostname — SSRF_ALLOWED_HOSTS, a comma-separated list. This applies to every SSRF check in the backend, including outbound webhooks and Parse input URLs (see Parsing from URLs on a private network):

backend:
  extraEnvVariables:
    - name: SSRF_ALLOWED_HOSTS
      value: "qdrant.internal,postgres.svc.cluster.local"

By pattern — DATA_CONNECTION_SSRF_ALLOWED_HOST_PATTERNS, for host families too numerous to enumerate. Each entry is a regular expression matched against the whole hostname, and this list applies only to data sink, data source, and embedding model config checks, so it cannot inadvertently let a webhook post to an internal address:

backend:
  extraEnvVariables:
    - name: DATA_CONNECTION_SSRF_ALLOWED_HOST_PATTERNS
      value: ".+\\.svc\\.cluster\\.local;.+\\.internal;10\\.0\\.\\d{1,3}\\.\\d{1,3}"

Three things to know about the pattern list:

• Entries are separated by semicolons or newlines, not commas — a comma is part of a regex quantifier such as \d{1,3}.
• Patterns are anchored. A pattern must match the entire hostname, so internal allows the host internal but not internal.evil.com.
• An invalid pattern is ignored, with a warning logged. A typo therefore blocks rather than opens a hole — but it also means a mistyped pattern silently fails to allow the host you intended, so check the logs after changing it.

Prefer the narrowest expression that covers your hosts. A pattern like .* disables the check entirely.

Turning the check on

Enforcement is off by default on a self-hosted deployment. Turn it on if your endpoints should only ever reach the public internet, or if you want the allowlist above to be the explicit record of which internal hosts they may reach:

backend:
  extraEnvVariables:
    - name: IS_NEW_DATA_CONNECTION_SSRF_PROTECTION_ENABLED
      value: "true"

Connections saved while the check is off are not re-checked later unless you also enable the separate IS_EXISTING_DATA_CONNECTION_SSRF_PROTECTION_ENABLED flag (default false), which re-checks a stored data sink when it is health checked.

Neither flag replaces a network egress policy on the backend pod. A connection endpoint is only one way out of the cluster; restrict the rest at the network layer.

Connection failures report generically

When a connection cannot be reached, the response says so without quoting what the endpoint returned — a failing connection would otherwise describe whatever answered it. The underlying error is written to the backend logs with the same correlation id, so search for it there as described above. This applies whether or not the SSRF check is enabled.

Managed embeddings and managed Qdrant

Two index-creation options are enabled through chart values rather than raw env flags, and both are now honored by the frontend at request time — no image rebuild is required.

• Managed embeddings — set config.managedEmbeddings.enabled: true. This populates the shared feature-config ConfigMap with IS_MANAGED_EMBEDDINGS_ENABLED, which is consumed by both the backend and the frontend. It surfaces managed embeddings as a default option when creating an index. It also requires an embedding model (for example openai-text-embedding-3-small) registered in your LLM provider config.

  config:
    managedEmbeddings:
      enabled: true

• Managed Qdrant (“Fully Managed” data sink) — set qdrant.enabled: true. The chart then emits the server-only BYOC_HAS_MANAGED_QDRANT var to the frontend, which the web app reads at request time to show the fully-managed vector store option. (Previously this was gated on a build-time NEXT_PUBLIC_* var, so prebuilt BYOC images silently never rendered it regardless of runtime config.)

  qdrant:
    enabled: true

Notes

• These flags only control defaults for a self-hosted deployment. In managed LlamaCloud, the same feature flags are resolved via PostHog; in BYOC/self-hosted, the env-var value is authoritative.
• When a frontend flag has a backend counterpart (e.g. IS_* in the API), set both consistently to avoid UI/API drift.