Feature Request: Ability to Disable Specific Components and Component Creation via Admin Settings or Startup Config

[flefevre]

Description:

Hi Langflow team,

Thank you for the amazing work on Langflow — it's an incredibly powerful and flexible tool!

I’d like to suggest a feature that would improve security and control in managed environments, especially in enterprise or educational contexts.

Feature Request:
Add the ability for administrators to:

1. Disable specific components (e.g., certain LLMs, tools, or integrations) via:

• An admin UI panel, or
• A startup configuration file/environment variable

1. Restrict the creation of new custom components in the IDE:

• Users would be limited to using only pre-approved or pre-installed components.
• This ensures basic users cannot create arbitrary or unverified components, maintaining consistency and governance over workflows.

Use Case:
In environments with non-technical users or strict compliance requirements, it's important to:

• Prevent usage of certain tools (e.g., external APIs, custom code, or specific models).
• Maintain a curated and approved set of components to avoid unexpected behavior or security risks.
• Simplify the user experience for less advanced users by guiding them toward specific workflows.

Possible Implementation Ideas:
Add an optional config like:

{
  "disabled_components": ["OpenAIAgent", "PythonCode"],
  "allow_component_creation": false
}

Or, expose these controls in an admin-only section of the Langflow UI.

Let me know if this feature would align with your roadmap !

Thanks again!

[sefzig]

I would like to see this, too. In my project, my users make use of a (rather small) set of Custom Components I provide them with through Docker, plus Chat Input and Chat Output. This works well, but new users are confused by all the (wonderful but for us: useless) native components. I would like to switch them off, as well as the Bundles. For us, whitelisting would be more suitable than blacklisting (as proposed in the original request). Rather uncommon use case I guess, but wanted to share the perspective to support this change request.