Component Registry

Relevant source files

• src/backend/base/langflow/api/v1/api_key.py
• src/backend/base/langflow/api/v1/chat.py
• src/backend/base/langflow/api/v1/endpoints.py
• src/backend/base/langflow/api/v1/flows.py
• src/backend/base/langflow/api/v1/folders.py
• src/backend/base/langflow/api/v1/login.py
• src/backend/base/langflow/api/v1/schemas.py
• src/backend/base/langflow/api/v1/store.py
• src/backend/base/langflow/custom/custom_component/component.py
• src/backend/base/langflow/custom/custom_component/custom_component.py
• src/backend/base/langflow/custom/utils.py
• src/backend/base/langflow/helpers/folders.py
• src/backend/base/langflow/initial_setup/starter_projects/Basic Prompt Chaining.json
• src/backend/base/langflow/initial_setup/starter_projects/Basic Prompting.json
• src/backend/base/langflow/initial_setup/starter_projects/Blog Writer.json
• src/backend/base/langflow/initial_setup/starter_projects/Document Q&A.json
• src/backend/base/langflow/initial_setup/starter_projects/Financial Report Parser.json
• src/backend/base/langflow/initial_setup/starter_projects/Hybrid Search RAG.json
• src/backend/base/langflow/initial_setup/starter_projects/Image Sentiment Analysis.json
• src/backend/base/langflow/initial_setup/starter_projects/Memory Chatbot.json
• src/backend/base/langflow/initial_setup/starter_projects/Nvidia Remix.json
• src/backend/base/langflow/initial_setup/starter_projects/Portfolio Website Code Generator.json
• src/backend/base/langflow/initial_setup/starter_projects/SEO Keyword Generator.json
• src/backend/base/langflow/initial_setup/starter_projects/Text Sentiment Analysis.json
• src/backend/base/langflow/initial_setup/starter_projects/Twitter Thread Generator.json
• src/backend/base/langflow/initial_setup/starter_projects/Vector Store RAG.json
• src/backend/base/langflow/interface/initialize/loading.py
• src/backend/base/langflow/schema/schema.py
• src/backend/base/langflow/serialization/serialization.py
• src/backend/base/langflow/services/auth/utils.py
• src/backend/base/langflow/services/database/models/api_key/crud.py
• src/backend/base/langflow/services/tracing/service.py
• src/backend/base/langflow/template/field/base.py
• src/backend/tests/performance/check_key_benchmark.py
• src/backend/tests/unit/api/v1/test_api_key.py
• src/backend/tests/unit/api/v1/test_folders.py
• src/backend/tests/unit/components/files_and_knowledge/test_file_component.py
• src/backend/tests/unit/components/processing/test_save_file_component.py
• src/backend/tests/unit/test_api_key_source.py
• src/backend/tests/unit/test_get_api_key.py
• src/lfx/src/lfx/_assets/component_index.json
• src/lfx/src/lfx/_assets/stable_hash_history.json
• src/lfx/src/lfx/base/data/base_file.py
• src/lfx/src/lfx/components/files_and_knowledge/file.py
• src/lfx/src/lfx/components/files_and_knowledge/save_file.py
• src/lfx/src/lfx/components/twelvelabs/video_file.py
• src/lfx/tests/unit/base/data/test_base_file.py

This page documents the static registry artifacts, versioning mechanism, and API surface that make component metadata available to the Langflow frontend. It covers the pre-built index file, the hash-based versioning system, and how the backend serves the full component type catalog. For the runtime mechanics of how components are instantiated and executed, see Component Lifecycle. For how built-in and user-supplied components are loaded into the backend type system at startup, see Component Loading.

---

Overview

Langflow maintains a pre-built snapshot of all bundled component metadata in a JSON index file shipped with the lfx package. At runtime, the backend reads this index, merges any user-supplied custom components, caches the result, and serves it through a single REST endpoint. The frontend uses this data to populate the component palette and validate node connections.

Registry pipeline:

Sources: src/lfx/src/lfx/_assets/component_index.json1-10 src/backend/base/langflow/api/v1/endpoints.py97-111

---

component_index.json

Location: src/lfx/src/lfx/_assets/component_index.json

This file is a static, pre-generated artifact committed to the lfx package. It stores the full template and metadata for every bundled component, allowing the backend to serve component descriptions without importing and executing component source files on every startup.

Top-Level Structure

The file contains a single entries array. Each element is a two-item array: a bundle/category name (string) and an object mapping component class names to their full metadata.

{
  "entries": [
    ["FAISS",   { "FaissVectorStoreComponent": { ... } }],
    ["Notion",  { "AddContentToPage": { ... }, "NotionDatabaseProperties": { ... }, ... }],
    ...
  ]
}

Sources: src/lfx/src/lfx/_assets/component_index.json1-10

Component Entry Structure

Each component entry contains the following fields:

Field	Type	Description
base_classes	string[]	Output types the component can produce (e.g., ["Data", "DataFrame"])
display_name	string	Human-readable label shown in the UI
description	string	Short description shown under the component name
icon	string	Icon identifier used by the frontend
beta	bool	Whether the component is marked as beta
legacy	bool	Whether the component is deprecated
frozen	bool	Whether the component's output is cached/frozen
edited	bool	Whether the component code differs from the released hash
field_order	string[]	Ordered list of input field names for display
outputs	object[]	Output port definitions (name, types, method, tool_mode, etc.)
template	object	Map of field names → input field definitions (see below)
metadata.code_hash	string	12-character hex hash of the component source
metadata.module	string	Full Python import path to the component class
metadata.dependencies	object	Package dependencies with names and pinned versions
minimized	bool	Whether the node renders in minimized form by default
pinned	bool	Whether the node is pinned on the canvas

Sources: src/lfx/src/lfx/_assets/component_index.json4-276

Template Field Definitions

The template object drives all frontend input rendering. Each key is a field name; the value is a field definition object. Fields produced by StrInput, BoolInput, IntInput, HandleInput, etc., are serialized here.

Common field properties:

Property	Description
_input_type	Python input class name (e.g., "StrInput", "BoolInput", "HandleInput")
type	Frontend type string ("str", "bool", "int", "other", "code", etc.)
display_name	Label shown in the UI
value	Default value
required	Whether the field must be filled
advanced	Whether the field is hidden in the collapsed view
show	Whether the field is visible at all
dynamic	Whether the field is dynamically updated
list	Whether the field accepts multiple values
input_types	For HandleInput: accepted upstream output types
load_from_db	Whether to load the value from the global variables store
tool_mode	Whether the field is exposed when in tool mode
trace_as_input	Whether to include in tracing as an input

The special code field is always present in template and carries the full Python source of the component class.

Sources: src/lfx/src/lfx/_assets/component_index.json81-273

Output Port Definitions

Each entry in outputs describes a port on the right side of a node:

Property	Description
name	Internal port identifier
display_name	Label in the UI
method	Name of the Python method on the component class that produces the output
types	List of output type strings (e.g., ["Data"], ["Tool"])
selected	Default selected output type
cache	Whether the output is cached between calls
tool_mode	Whether the port is exposed in tool mode
allows_loop	Whether this port can form a loop

Sources: src/lfx/src/lfx/_assets/component_index.json50-79

Example: FAISS component entry (abbreviated)

"FAISS" bundle:
  class: FaissVectorStoreComponent
  module: lfx.components.FAISS.faiss.FaissVectorStoreComponent
  code_hash: 2bd7a064d724
  base_classes: ["Data", "DataFrame"]
  outputs:
    - search_results  (method: search_documents, types: ["Data"])
    - dataframe       (method: as_dataframe, types: ["DataFrame"])
  template fields:
    - index_name      (StrInput, default: "langflow_index")
    - persist_directory (StrInput)
    - ingest_data     (HandleInput, input_types: ["Data", "DataFrame"], list: true)
    - embedding       (HandleInput, input_types: ["Embeddings"])
    - number_of_results (IntInput, advanced: true, default: 4)
    - search_query    (QueryInput, input_types: ["Message"])
    - should_cache_vector_store (BoolInput, advanced: true)
    - allow_dangerous_deserialization (BoolInput, advanced: true)

Sources: src/lfx/src/lfx/_assets/component_index.json2-276

---

stable_hash_history.json

Location: src/lfx/src/lfx/_assets/stable_hash_history.json

This file records, for each component class name, the code_hash value that was in effect for each released version of the lfx package.

Format

The hash for a given component in component_index.json (metadata.code_hash) must match the entry for the current package version in stable_hash_history.json. If it does not, the component is considered modified and its edited flag will be set.

Purpose

Use case	Mechanism
Detect code changes between releases	Compare code_hash in index vs. history
Identify user-modified bundled components	Set edited: true on the component entry
Nightly build validation	CI workflow reads and merges updated hashes (see Nightly Builds)

Hash-to-version cross-reference:

Sources: src/lfx/src/lfx/_assets/stable_hash_history.json1-10 src/lfx/src/lfx/_assets/component_index.json31-33

---

Component Discovery

Bundled Components

Bundled components are those shipped in the lfx package under src/lfx/src/lfx/components/. Their metadata is pre-baked into component_index.json. No file-system scanning occurs at runtime for these components; the backend reads the index file directly.

The metadata.module field in each entry provides the canonical import path for the class (e.g., lfx.components.FAISS.faiss.FaissVectorStoreComponent). This is used when instantiating the component for execution.

Custom Components

Custom components loaded from COMPONENTS_PATH (the environment variable, see Environment Variables) are discovered at runtime by scanning the specified directories for Python files. They are merged with the bundled index before being served. Custom component loading is detailed in Component Loading.

Directory Organization

Bundled components are organized into sub-packages within lfx.components:

lfx/components/
  FAISS/
    faiss.py          → FaissVectorStoreComponent
  Notion/
    add_content_to_page.py    → AddContentToPage
    list_database_properties.py → NotionDatabaseProperties
    list_pages.py             → NotionListPages
    ...
  input_output/
    chat.py           → ChatInput, ChatOutput
  models_and_agents/
    prompt.py         → PromptComponent
  files_and_knowledge/
    file.py           → File
  ...

The category/bundle name in component_index.json corresponds to the sub-package name (e.g., "FAISS", "Notion").

Sources: src/lfx/src/lfx/_assets/component_index.json2-5 src/lfx/src/lfx/components/files_and_knowledge/file.py1-5

---

API Endpoint: GET /api/v1/all

Handler: get_all() in src/backend/base/langflow/api/v1/endpoints.py97-111

This endpoint returns the merged, cached component type dictionary. It requires an authenticated user.

GET /api/v1/all
Authorization: Bearer <token>

Response: 200 OK
Content-Encoding: gzip (or br)
Content-Type: application/json

{
  "CategoryName": {
    "ComponentClassName": { ...component metadata... }
  },
  ...
}

Internally, get_all() delegates to get_and_cache_all_types_dict() from langflow.interface.components, passing the current SettingsService. The result is returned through compress_response() for bandwidth efficiency.

Call chain:

Sources: src/backend/base/langflow/api/v1/endpoints.py97-111

---

Frontend Consumption

The frontend calls GET /api/v1/all during initialization and stores the response in typesStore (see State Management). This store provides:

• The component palette (sidebar) with categories and component cards
• Type compatibility data used when validating edge connections (see Connection Validation)
• The full field template used to render input widgets inside GenericNode (see GenericNode Component)

The template object from each component entry in the registry maps directly to the input field widgets rendered in the node UI. Fields with show: false are hidden, fields with advanced: true appear only in the expanded view, and fields with dynamic: true can be updated server-side in response to user interaction.

Sources: src/lfx/src/lfx/_assets/component_index.json81-273 src/backend/base/langflow/api/v1/endpoints.py97-111

---

Data Flow Summary

Sources: src/lfx/src/lfx/_assets/component_index.json1-10 src/lfx/src/lfx/_assets/stable_hash_history.json1-10 src/backend/base/langflow/api/v1/endpoints.py97-111 src/backend/base/langflow/interface/initialize/loading.py25-51