Block custom components

Custom components and the component code editor allow Langflow users to create and execute Python code in the Langflow runtime. While this freedom is a feature of Langflow, in some deployments you might want to block the creation of custom Langflow components to prevent arbitrary code execution.

To block custom component creation on a Langflow server, set the following environment variable:

LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false

When set to false, Langflow blocks creating custom components, changing code in the visual editor, and running registered built-in code-execution components.

When unset or true, Langflow allows custom code. Existing installations keep the default true behavior until you opt in to this restriction.

This environment variable is a beta feature, and should not be your only safeguard in production environments.

In the event that Langflow could execute untrusted or LLM-generated code, run Langflow in an isolated and containerized execution environment.

Restrict custom component creation to superusers{#restrict-custom-components-to-superusers}

To restrict custom component creation to superusers while keeping built-in components functional for users, set the following environment variable:

LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true

When set to true, non-superusers can still view and use custom components in flows, but they cannot create new custom components or edit custom component code.

Upgrading a server that blocks custom components{#upgrading-with-custom-components-blocked}

While LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, Langflow never runs the component code stored in a flow. It looks up its own copy of that component and runs that instead. The code saved in the flow is only used to identify which component the node is.

This matters when you upgrade. Langflow releases change built-in component code, so after an upgrade the code saved in your flows no longer matches the code the new version ships. By default, Langflow rebuilds those nodes with its own current copy of the component and the flows keep running. Each substitution is logged, and the flow itself is left untouched. The visual editor continues to mark the component as outdated until you update it, but that marker doesn't block editor or Playground runs.

Nothing new becomes runnable: the code that runs is always the server's own, chosen by component type. A node whose component type this server doesn't recognize is still refused. This is the same rule Langflow already applies by default to unauthenticated public flow builds.

A node is also refused, rather than rebuilt, when more than one component claims its type — for example a component in LANGFLOW_COMPONENTS_PATH installed under a name a built-in already uses. Langflow can't tell which of the two the node meant, so it declines to guess and asks you to update the component instead.

To require an exact match instead, so that any flow containing a component whose stored code has drifted is refused until you update that component, set:

LANGFLOW_SUBSTITUTE_OUTDATED_COMPONENT_CODE=false

With this set, an upgrade that changes a built-in component blocks every saved flow using it, with an error naming the components to update:

Flow build blocked: outdated components must be updated before running: <display_name> (<node_id>)

To update those components, open each flow in the visual editor and apply the component update, or update flow files with lfx upgrade <flow.json>. This setting has no effect while LANGFLOW_ALLOW_CUSTOM_COMPONENTS is true, since the flow's own code runs as authored.

Interaction with catalog governance

Catalog governance takes precedence over the custom-code settings on the custom-component create, update, and code-validation endpoints. A catalog block has no superuser bypass.

For POST /api/v1/validate/code, this policy runs before the source is parsed or imports are inspected. In a restricted custom-code mode, known templates are validated from the trusted server copy, while unknown source follows the same disabled or admin-only rule as the component editor. On custom-component create and update, known blocked template source is rejected before the component is built, and the resolved component type is checked again before request-supplied frontend updates are applied.

An active catalog policy fails closed with a temporary 503 response while server template identities are still initializing. An empty catalog policy preserves the default behavior and does not require template identity lookups.

Configure a custom component allow-list

LANGFLOW_ALLOW_CUSTOM_COMPONENTS works together with optional paths that define which component templates the server loads, and which code hashes are trusted.

Directories listed in the LANGFLOW_COMPONENTS_PATH environment variable are loaded as custom components and merged into the server’s template set. When LANGFLOW_ALLOW_CUSTOM_COMPONENTS is set to false, the components in the LANGFLOW_COMPONENTS_PATH directory remain allowed.

To allow some components while blocking others, include the allowed custom components directory in LANGFLOW_COMPONENTS_PATH and set LANGFLOW_ALLOW_CUSTOM_COMPONENTS to false.

LANGFLOW_COMPONENTS_INDEX_PATH points to a prebuilt component index JSON file at a local path or http:// / https:// URL. This environment variable replaces the default index bundled with the lfx package. It does not import Python modules from a directory on disk. To allow-list custom components, use the LANGFLOW_COMPONENTS_PATH environment variable.

If both environment variables are set, Langflow builds one combined set of components from the custom index and from LANGFLOW_COMPONENTS_PATH. If the same component category name exists in both, LANGFLOW_COMPONENTS_PATH replaces that whole category from the custom index.

Disable the allow-list bypass

The allow-list behavior above assumes the admin controls which env vars are set at startup. In deployments where that assumption doesn't hold, set:

LANGFLOW_ALLOW_COMPONENTS_PATHS_OVERRIDE=false

When this is false and LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, components contributed by LANGFLOW_COMPONENTS_PATH and LANGFLOW_COMPONENTS_INDEX_PATH are ignored and no longer bypass the block.

Default is true, which preserves existing behavior. The setting has no effect while LANGFLOW_ALLOW_CUSTOM_COMPONENTS=true, since nothing is being bypassed.

For more information, see:

• Environment variables
• Security