--- title: Optional Feature Flags | Developer Documentation description: Optional frontend, backend and LlamaParse worker environment-variable flags for self-hosted LlamaCloud that toggle UI elements and behavior such as Index V1 visibility, parse-config editing, managed embeddings, Temporal extract, parse input-URL network restrictions, and SSRF protection for data sink, data source and embedding model connections. --- ## 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 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](#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 `temporalWorkloads.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. | ``` temporalWorkloads: 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: Terminal window ``` kubectl logs -n 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](#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.