This page describes the three Python packages that make up the Langflow backend, their dependency chain, the module namespaces each package owns, and the backwards-compatibility re-export pattern that bridges them. For a broader view of how all subsystems interact at runtime, see the System Architecture page. For build tooling and workspace configuration details, see Workspace Configuration.
The Langflow Python backend is split into three installable packages, each living in a separate directory within the monorepo. This layering keeps lightweight executor logic independent of the full server stack, allows the executor (lfx) to be used standalone, and lets langflow-base carry the heavy FastAPI/database machinery separately from the final distribution package (langflow).
Dependency chain:
lfx ──► langflow-base ──► langflow
Package Summary Table:
| PyPI Name | Version | Source Directory | Python Namespace | Role |
|---|---|---|---|---|
lfx | ~0.3.0 | src/lfx/ | lfx.* | Primitive types, component implementations, executor |
langflow-base | ~0.8.0 | src/backend/base/ | langflow.* | FastAPI app, services, DB, auth |
langflow | 1.8.0 | . / src/backend/langflow/ | langflow.* | CLI entrypoint, frontend serving |
Sources: pyproject.toml1-22 src/backend/base/pyproject.toml1-21
The following diagram maps each package to its source directory and version constraint, and shows which packages are workspace-local vs. external.
Package dependency and source mapping:
Sources: pyproject.toml19-21 src/backend/base/pyproject.toml20
lfx — Langflow ExecutorLocation: src/lfx/
Installed as: lfx
Python namespace: lfx.*
Version constraint in dependents: ~=0.3.0
lfx is the foundation layer. It has no dependency on FastAPI or the database. Its purpose is to define the building blocks that both component authors and the server rely on.
Key submodules and their roles:
| Module | Description |
|---|---|
lfx.inputs | All input type classes (StrInput, BoolInput, HandleInput, IntInput, SecretStrInput, etc.) |
lfx.schema | Core data schemas — Data, DataFrame, Message |
lfx.template | Template field and prompt utilities |
lfx.base | Abstract base classes: vector stores (LCVectorStoreComponent), LangChain utilities (LCToolComponent), I/O |
lfx.log.logger | Structured logger (configure, logger) used throughout the stack |
lfx.services.settings | Settings Pydantic model, SettingsService, settings constants |
lfx.services.deps | session_scope and other lightweight dependency helpers |
lfx.interface | get_and_cache_all_types_dict, setup_llm_caching — component discovery and loading |
lfx.components | All bundled component implementations organized by provider/category |
lfx.custom | Component, CustomComponent base classes; DirectoryReader, code parser, validation |
lfx.graph | Graph and vertex data structures for flow execution |
lfx.cli | serve_command, run — standalone executor CLI |
lfx._assets | component_index.json, stable_hash_history.json — pre-built component metadata |
The lfx._assets/component_index.json file is a cached snapshot of all component metadata. The stable_hash_history.json tracks per-component code hashes across lfx versions to support upgrade diffing.
Sources: src/lfx/src/lfx/_assets/component_index.json1-50 src/lfx/src/lfx/_assets/stable_hash_history.json1-30
langflow-base — Core ServerLocation: src/backend/base/
Installed as: langflow-base
Python namespace: langflow.* (build target: packages = ["langflow"])
Version constraint in dependents: ~=0.8.0
langflow-base owns the FastAPI application, service layer, database ORM, authentication, and API routers. It imports from lfx.* extensively.
Key submodules:
| Module | Description |
|---|---|
langflow.main | create_app(), get_lifespan(), middleware registration |
langflow.api | All REST routers (v1, v2, health check, log) |
langflow.services | Service layer: DatabaseService, auth, cache, tracing, monitor, settings |
langflow.services.database | SQLModel/SQLAlchemy ORM models, DatabaseService, Alembic config |
langflow.services.settings.base | Re-exports Settings from lfx.services.settings.base |
langflow.initial_setup | create_or_update_starter_projects(), starter project JSON files |
langflow.alembic | Database migration scripts |
langflow.__main__ | Typer CLI definition (run, superuser, migration), process management |
langflow.langflow_launcher | Entrypoint callable main() |
langflow-base also exposes the complete optional-dependency group, which pulls in all third-party integrations (vector stores, LLM providers, document loaders, etc.). This is what the langflow package installs via langflow-base[complete].
Sources: src/backend/base/pyproject.toml20-100 src/backend/base/langflow/main.py1-60 src/backend/base/langflow/__main__.py1-60
langflow — Distribution PackageLocation: src/backend/langflow/ (build target relative to repo root)
Installed as: langflow
Python namespace: langflow.*
Entry point: langflow = "langflow.langflow_launcher:main"
The langflow package is the end-user distribution artifact. Its sole declared runtime dependency is langflow-base[complete]~=0.8.0, meaning it adds no new Python logic of its own beyond wiring in the full langflow-base[complete] installation and providing the langflow CLI command.
The built frontend static files are copied into src/backend/base/langflow/frontend/ at build time and are served by langflow-base's FastAPI static file mount.
Sources: pyproject.toml1-21 pyproject.toml96-97 pyproject.toml155-156
Both langflow-base and langflow contribute to the langflow.* Python namespace. The following diagram shows which package owns which top-level module paths.
Python namespace ownership by package:
Sources: src/backend/base/langflow/main.py22-26 src/backend/base/langflow/services/settings/base.py1-16 src/backend/base/langflow/__main__.py21-23
When code previously lived in langflow.* but was moved to lfx.*, the original import path is preserved through a thin re-export module in langflow-base. The re-export module simply imports everything from the lfx counterpart and re-declares __all__.
Example — langflow.services.settings.base:
src/backend/base/langflow/services/settings/base.py1-16
This means both of the following imports resolve to the same class:
from lfx.services.settings.base import Settingsfrom langflow.services.settings.base import SettingsWhere this pattern appears:
langflow.* re-export module | Delegates to lfx.* module |
|---|---|
langflow.services.settings.base | lfx.services.settings.base |
| (others following same convention) | corresponding lfx.* module |
Direct lfx.* imports are preferred in new code; the re-export modules exist to keep existing callers working during the transition from a monolithic langflow package to the layered structure.
Sources: src/backend/base/langflow/services/settings/base.py1-16 src/backend/base/langflow/main.py22-26 src/backend/base/langflow/__main__.py21-23
The three packages are managed together as a uv workspace. The root pyproject.toml declares all workspace members and redirects all inter-package dependencies to local paths.
Workspace declaration (root pyproject.toml):
Effect: When running uv sync inside the monorepo, langflow's langflow-base dependency and langflow-base's lfx dependency resolve to the local workspace members rather than PyPI. The single uv.lock file at the repo root pins all transitive dependencies for all three packages together.
The uv.lock file records all three workspace members explicitly:
[manifest]
members = [
"langflow",
"langflow-base",
"lfx",
]
For building for release, each package is built separately. The Makefile provides build_langflow_base and build_langflow targets that invoke uv build in the appropriate directories.
Sources: pyproject.toml82-94 uv.lock21-26 Makefile337-349
The diagram below traces which modules are imported at application startup, bridging the three-package layer boundary.
Import flow from application entry to lfx primitives:
Sources: src/backend/base/langflow/main.py22-26 src/backend/base/langflow/main.py147-165
Refresh this wiki
This wiki was recently refreshed. Please wait 3 days to refresh again.