Lessons from first flow to production — building flows, agents and tools, RAG, serving over API, MCP and A2A, custom components and operations — plus the full API reference: concepts, CLI and LFX, REST endpoints, components, SDKs and configuration.
Topics
129
Sections
14
Learning module
LangFlow learning module
Langflow is an open-source, Python-based tool for building and deploying AI-powered agents and workflows through a visual, low-code interface, where every flow can also be served as an API or exposed as an MCP server.
A flow is a graph of Python components connected by typed ports (Message, JSON, Table), saved as JSON.
Every flow is an API: POST /api/v1/run/{flow_id} with an x-api-key header.
Global variables keep secrets out of exported flows.
Projects can publish flows as tools on an MCP server.
Slow iteration on AI pipelines locked inside code: Without Langflow, every experiment with a different splitter, embedding model, retriever setting or agent prompt means editing code, rerunning scripts and wiring a test UI, and product or domain experts cannot take part. Langflow makes the pipeline a visible graph that anyone on the team can rewire and test in the Playground in seconds, then serves the exact flow that was tested as an API, removing the rewrite between prototype and integration.
Getting started
Langflow overview
Build agents and AI workflows visually, then serve the same flow as an API, MCP tool or A2A agent.
A flow is a graph of components drawn on a canvas and stored as JSON.
The flow tested in the Playground is the flow the API serves.
Visual building speeds iteration but does not remove the need to review what the flow does.
From whiteboard to working API: A product team sketches a support assistant on the canvas, tests it in the Playground the same afternoon, and the web app calls it through the run endpoint the next day.
QWhat is Langflow, and where does it sit relative to LangChain and LangGraph?
Langflow is an open-source, Python-based visual builder and runtime for AI flows. Many of its components wrap LangChain integrations, but you assemble them on a canvas instead of in code, and the server runs and serves the result as an API, MCP server or A2A agent. LangGraph is a code-first orchestration library for durable, stateful agents. Langflow trades some low-level control for speed of iteration and collaboration.
Installation options
Choose Langflow Desktop, the Python package or the Docker image depending on who runs it and where.
Langflow Desktop is the quickest single-user install on Windows and macOS.
The langflow Python package needs Python 3.10–3.14 and is installed with uv pip install langflow.
Official Docker images disable auto-login, so they need a superuser password.
Matching the install to the job: A data scientist uses Desktop to prototype, the platform team runs the Docker image on Kubernetes for the shared instance, and CI uses the Python package with LFX to run flows headlessly.
QWhy do official Docker images set LANGFLOW_AUTO_LOGIN=false, and what must you configure as a result?
Auto-login signs every visitor in as the superuser, which is acceptable on a laptop but dangerous on a network. Containers are usually reachable by others, so the images require login. You must set LANGFLOW_SUPERUSER and a strong LANGFLOW_SUPERUSER_PASSWORD, and then create API keys for programmatic access.
Your first flow: Basic Prompting
Connect Chat Input, a Prompt Template, a Language Model and Chat Output, then test it in the Playground.
Chat Input turns the user's text into a Message; Chat Output returns the reply.
The Prompt Template's {variables} become input ports you wire upstream outputs into.
Templates such as Basic Prompting and Simple Agent are starting points you copy and modify.
A tone-of-voice rewriter: A marketing team builds a flow whose prompt rewrites any text into the brand voice, tests ten examples in the Playground, and shares the flow's API snippet with the CMS developer.
QWhich components does every chat flow need, and why?
Chat Input and Chat Output. Chat Input creates the Message (with session ID and files) that starts a chat run, and it is required by the Playground, the embedded chat widget and the Responses API. Chat Output is what /run returns, what the Playground displays and what an MCP tool call receives. Everything between them is the flow's logic.
Projects and flow organization
Group related flows into projects, which are also the unit exported as a ZIP and served as one MCP server.
A project's enabled flows become the tools of that project's MCP server.
A whole project can be downloaded as a ZIP and imported into another instance.
Grouping by purpose keeps MCP tool lists small and relevant for clients.
One project per consuming team: A company keeps a 'Support tools' project and a 'Finance tools' project, so the support team's MCP client sees only lookup and refund-policy flows and never the finance ones.
QHow would you structure projects for an organization with several teams?
Use projects as the boundary of ownership and exposure: one per team or product area, so each project's MCP server exposes only the tools that audience needs. Keep shared utility flows in their own project and call them with Run Flow. Export projects regularly into version control, and give flows clear names and descriptions, because those become MCP tool names and descriptions.
Flow JSON, export and templates
A flow is saved as JSON containing its nodes, edges and field values, which makes it portable and versionable.
Export one flow as JSON or a whole project as a ZIP.
The JSON contains every saved field value, so check it for secrets before sharing.
An endpoint_name alias can replace the flow's UUID in API URLs.
Promoting a flow from staging to production: An engineer exports the reviewed flow JSON, commits it, and the deployment pipeline imports it into the production instance with the same endpoint name, so client code never changes.
QWhat is the benefit of setting an endpoint_name on a flow?
Clients call /api/v1/run/<endpoint_name> instead of a UUID. When the flow is re-imported or replaced, its UUID can change, but the alias can stay the same, so applications, webhooks and documentation keep working. It also makes logs and URLs readable.
Building flows
Typed data: Message, JSON and Table
Ports carry typed data, and an output connects only to an input that accepts the same type.
Message carries chat text plus sender, session ID and files.
JSON (named Data before 1.9) is a structured record; Table (named DataFrame before 1.9) holds rows.
Parser and type-conversion components bridge types when a flow mixes them.
Turning search results into an answer: Web Search returns a Table of results; a Parser formats the rows into text, which feeds a Prompt Template whose output becomes the Message the model answers.
QWhy does Langflow type its ports, and how do you connect two components whose types differ?
Typing catches wiring mistakes in the editor rather than at run time: an output can only connect to inputs of a compatible type, shown by port colour. When types differ, insert a converter: Parser turns JSON or Table into text with a template, and type-conversion components change between Message, JSON and Table. Choosing the right shape early, for example keeping records as a Table until the last step, keeps flows simpler.
Prompt design in flows
Use Prompt Template variables to inject context, history and instructions explicitly rather than concatenating text.
Each {variable} becomes an input port; double-bracket mode allows Mustache {{variable}} syntax.
Literal braces in single-bracket mode are read as variables, so escape them or switch mode.
Keep instructions in the template and data in variables so prompts stay reviewable.
Grounded answers with citations: A template has {context} filled by retrieved chunks and {question} from Chat Input, with an instruction to answer only from the context and cite the document titles.
QHow do you keep prompts maintainable as a flow grows?
Treat the Prompt Template as the single place for instructions, with every dynamic part a named variable wired from upstream components. Avoid building prompts by text concatenation in custom code. Use tweaks to try prompt variants without editing the saved flow, and version the flow JSON so prompt changes are diffable and reviewable.
Chat memory and sessions
Langflow stores chat messages per session_id, so each conversation keeps its own history.
The Agent component includes built-in chat memory per session.
Message History reads or stores messages by session from Langflow storage or external memory.
Without a stable session ID from the app, separate users can end up sharing context.
Per-customer support conversations: The web app passes the ticket ID as session_id on every call, so the agent remembers earlier turns of that ticket and never mixes customers.
QWhat goes wrong if a client calls a chat flow without a consistent session_id?
Either every call starts a new conversation, so the assistant forgets earlier turns, or several users share one default session and see each other's context. The client should derive a stable ID per conversation (for example a user ID plus thread ID) and pass it on every request. History should also be bounded, through the number of history messages read, so long sessions do not overflow the context window.
Branching: If-Else and Smart Router
Route a run down different paths by exact comparison (If-Else) or by LLM classification (Smart Router).
If-Else compares text and sends the message to its True or False output.
Smart Router asks an LLM to pick one of the routes defined in a table, with an optional Else.
Deterministic checks are cheaper and more predictable; use the LLM router for fuzzy intent.
Intent-based triage: A support flow uses Smart Router to send billing questions to a billing sub-flow, outages to an incident flow, and everything else to a general agent, with If-Else first catching the literal command 'human'.
QWhen would you use If-Else rather than Smart Router?
Use If-Else whenever the decision can be expressed as a deterministic comparison (an exact keyword, a status value, a regex-like match), because it is free, instant and fully predictable. Use Smart Router when the categories describe intent in natural language and inputs vary too much for rules. A common pattern is rules first for the obvious cases, then the router for the rest.
Loops and batch processing
Process lists item by item with Loop, or run a model over every row of a Table with Batch Run.
Loop sends each item out of Item, receives it back through Looping, and emits the aggregate from Done.
Batch Run adds the model's response for each row as a new Table column.
Large batches multiply model calls, so test on a sample and watch cost.
Classifying a backlog of feedback: An analyst loads 2,000 survey responses as a Table and uses Batch Run with a classification prompt, producing a new 'theme' column ready to chart.
QHow do Loop and Batch Run differ, and how would you control cost in either?
Loop is general iteration: each item can pass through any chain of components before returning, which suits multi-step processing per item. Batch Run is specialised: one model call per row, results appended as a column, which is simpler and faster to build. Control cost by sampling first, using a cheaper model for classification, keeping prompts short, and caching or deduplicating repeated inputs.
Sub-flows with Run Flow
Call another flow as a step, or give it to an agent as a tool, to reuse logic across flows.
Run Flow generates inputs for the target flow and accepts optional tweaks.
In Tool Mode it lets an agent call a whole flow as one tool.
Shared sub-flows mean one fix reaches every flow that uses them.
A shared 'look up customer' flow: Three different assistants call one customer-lookup flow through Run Flow, so when the CRM API changes only that flow is updated.
QWhat are the trade-offs of composing flows with Run Flow?
It brings reuse and separation of concerns: each flow is smaller, testable on its own and owned by one team. The costs are extra latency per call, harder end-to-end debugging across flows, and coupling to the sub-flow's inputs and outputs, which become an interface. Keep those interfaces stable, name them clearly, and use traces to follow a run across flows.
Structured extraction
Use Structured Output to have an LLM return fields that match a schema table instead of free text.
The Output Schema table defines field names, types and descriptions.
The result is JSON or a Table, ready for downstream components or APIs.
Validate business rules after extraction; a schema guarantees shape, not truth.
Invoices into the accounting system: Uploaded invoices are converted to text, Structured Output extracts vendor, total, currency and due date, and a custom component posts the record to the finance API.
QWhy prefer Structured Output over asking the model to 'reply in JSON'?
A schema gives the component explicit field names, types and descriptions to enforce, so the output parses reliably and downstream components receive typed JSON or Table data. Free-text JSON instructions break on extra prose, missing fields or invalid syntax. Even so, the values can be wrong, so add validation and a fallback path for records that fail checks.
Agents & tools
How the Agent component works
The Agent runs a tool-calling loop: an LLM reasons over the input, calls connected tools and replies, with chat memory per session.
Agent Instructions set the system prompt; the Language Model input picks the model.
Tools connect to the Tools port from components in Tool Mode, MCP Tools or Run Flow.
The Playground shows each tool call, which is the first place to debug agent behaviour.
An IT helpdesk agent: An agent with tools for password-reset status, device inventory and the knowledge base answers employee questions and shows each tool call in the Playground for review.
QHow would you debug an Langflow agent that calls the wrong tool?
Open the run in the Playground or traces and read the tool calls and their inputs. Most causes are tool descriptions that overlap or are vague, too many tools connected, or agent instructions that do not say when to use each. Fix the descriptions and names first, reduce the toolset, add explicit guidance in the instructions, and test with a fixed set of questions before and after.
Designing tools with Tool Mode
Turn almost any component into a tool an Agent can call by switching it to Tool Mode.
A component in Tool Mode exposes a Toolset port to connect to the Agent.
You choose which of its actions are exposed and edit their names and descriptions.
Every exposed tool widens what the agent can do, so expose only what is needed.
Letting an agent fetch web pages: The URL component is switched to Tool Mode and connected to the agent, which can now read a page the user links before answering.
QWhat makes a good tool for an LLM agent?
A clear, distinct name and a description that says when to use it and what it returns; a small, typed set of inputs; deterministic, fast behaviour; and outputs that are concise enough for the context window. Dangerous actions should be separate tools that need approval, and read-only tools should be preferred where possible.
Connecting MCP servers
Use the MCP Tools component to give an agent the tools of any MCP server over stdio, HTTP or SSE.
MCP Tools can connect to external servers or to Langflow's own project MCP servers.
Server tools appear to the agent like any other connected tool.
Only connect servers you trust; their tools run with the access you give them.
Agents that work with GitHub and the filesystem: An engineering assistant connects GitHub and filesystem MCP servers, letting it read issues and repository files to draft release notes.
QWhat security considerations apply when connecting an agent to MCP servers?
An MCP server's tools execute with whatever credentials and access the server has, and tool outputs can contain prompt-injection text. Connect only trusted servers, scope their credentials to the minimum, avoid exposing destructive tools without an approval step, treat tool output as untrusted data, and log tool calls through traces for audit.
Human-in-the-loop with Human Input
Pause a flow at a checkpoint until a person chooses an action; each action becomes an output branch.
Each User Action defined on the component is its own output path.
Completed steps are not re-run when the flow resumes.
Use it before irreversible actions such as payments, emails or data changes.
Approving outbound customer emails: An agent drafts a reply, Human Input pauses with Approve and Edit actions, and only the Approve branch reaches the component that sends the email.
QWhere should human approval go in an AI workflow, and why does 'not re-running completed steps' matter?
Approval belongs immediately before any irreversible or high-impact action, with the draft and its supporting evidence shown to the reviewer. Because completed steps are not re-run on resume, expensive model calls and side effects that happened before the pause are not repeated, which keeps costs predictable and prevents duplicate actions.
Guardrails for input safety
Validate incoming text with an LLM check for PII, secrets, jailbreak attempts and harmful content before it reaches the agent.
Built-in checks cover PII, secrets, jailbreaks, offensive and malicious content, plus custom rules.
Place guardrails right after Chat Input so unsafe input never reaches tools.
LLM-based checks can miss or over-flag, so combine them with deterministic rules.
Keeping secrets out of a public chatbot: A public assistant routes input through Guardrails; messages containing API keys or card numbers are blocked with a polite explanation instead of being sent to the model and logged.
QAre LLM-based guardrails enough on their own? What else would you add?
No. They are probabilistic and can be bypassed or produce false positives. Add deterministic validation (regexes for card numbers and keys, length limits), least-privilege tools so a successful injection cannot do much, output checks before anything leaves the system, rate limiting, and monitoring of blocked and passed messages to tune the rules.
RAG & data
Ingestion pipeline
Load documents, split them into chunks, embed them and store them in a vector store or Knowledge Base.
Split Text sets chunk size, overlap and separator for each chunk.
The same embedding model must be used for ingestion and retrieval.
Run ingestion as its own flow so it can be scheduled or triggered separately.
Indexing a policy library: An ingestion flow loads 400 HR PDFs, splits them into 800-character chunks with overlap, embeds them and writes them to the Knowledge Base; it reruns whenever HR uploads a new version.
QHow do you choose chunk size and overlap?
Chunks should hold one coherent idea: too small loses context, too large dilutes relevance and wastes the context window. Start around a few hundred to a thousand characters, add 10–20% overlap so sentences that span a boundary survive, split on natural separators such as paragraphs, and then measure retrieval quality on real questions rather than guessing.
Retrieval flow
Embed the question, search the store for similar chunks, and pass them as context to the prompt.
Retrieval returns the top matching chunks, optionally filtered by metadata.
A Parser formats chunks, with their sources, into the prompt's context variable.
Tell the model to answer only from the context and to say when it is missing.
Product documentation assistant: A docs assistant retrieves the five most similar chunks filtered by product version, and the answer cites the page titles it used.
QThe RAG assistant gives confident wrong answers. How do you investigate?
Separate retrieval from generation. Inspect what was retrieved for the failing questions: if the right chunk is missing, fix ingestion (chunking, stale documents, metadata filters) or the embedding model; if the right chunk is present, fix the prompt so it insists on grounding and allows 'I don't know'. Build a small set of question-and-expected-source pairs and check retrieval hit rate as you change things.
Knowledge Base vs an external vector store
Use the built-in Knowledge Base for local, self-contained retrieval, and an external vector database for scale and sharing.
The Knowledge Base stores embeddings locally and supports similarity search with metadata filters.
External stores such as Astra DB, pgvector or Chroma suit large or shared corpora.
Choose by data size, who else needs the index, and operational ownership.
Start local, move out later: A team prototypes with the Knowledge Base, then moves to a managed vector database when three applications need the same index and the corpus passes a million chunks.
QWhen would you move from the built-in Knowledge Base to an external vector database?
When the corpus or query volume outgrows a local store, when several applications or services must share the same index, when you need managed backups, replication and access control, or when the data must live in an existing platform. The flows change little because only the store components are swapped, as long as the embedding model stays the same.
Web data: URL and Web Search
Fetch and crawl pages with URL, or search the web, news and RSS with Web Search, to bring fresh information into a flow.
URL can crawl recursively and return text, Markdown or HTML.
Web Search returns results as a Table for parsing or batch processing.
Treat fetched content as untrusted input: it can contain prompt injection.
Competitive news digest: A scheduled flow searches news for competitor names, fetches the top articles with URL, summarizes each and posts a daily digest.
QWhat risks come with feeding web content into an LLM flow?
Web pages can contain instructions aimed at the model (indirect prompt injection), misinformation, or huge payloads that overflow the context. Mitigate by limiting crawl depth and size, stripping to readable text, instructing the model to treat the content as data, keeping tools available to that flow minimal, and citing sources so users can verify.
Integrate & serve
Choosing the right endpoint
Pick between run, advanced run, webhook, the v2 Workflow API and the Responses API based on how your client calls the flow.
/api/v1/run/{flow_id} is the main synchronous (or streamed) call for applications.
/api/v1/webhook/{flow_id} starts a flow from any JSON payload and returns immediately.
/api/v1/responses lets existing OpenAI clients call a flow by using its ID as the model.
One flow, three callers: The web app calls /run with streaming, Stripe events hit the webhook endpoint, and an internal tool built on the OpenAI SDK calls the same flow through /responses.
QWhen would you use the webhook endpoint instead of /run?
Use the webhook when another system pushes events and does not need the flow's output in the response: payment events, form submissions, repository events. The run starts in the background and the call returns quickly, which suits senders with short timeouts and retries. Use /run when the caller needs the answer, and the v2 Workflow API (beta) when you need background jobs you can poll, stream or stop.
Streaming responses
Add ?stream=true to the run endpoint to receive tokens as they are generated instead of waiting for the full reply.
Streaming improves perceived latency for chat interfaces.
The v2 Workflow API can stream Langflow events or the AG-UI protocol over SSE.
Proxy the stream through your own server so the API key never reaches the browser.
A responsive chat UI: A Next.js route handler forwards the streamed run to the browser, so users see the answer forming within half a second.
QWhy proxy Langflow streaming through your backend rather than calling it from the browser?
Calling from the browser would expose the Langflow API key and the server URL to anyone. A backend proxy keeps the key secret, can enforce authentication, rate limiting and input validation, can attach the session ID from the user's session, and can log or transform the stream before forwarding it.
Calling flows from TypeScript
Use the official @datastax/langflow-client (LangflowClient) to run or stream flows with tweaks and session IDs.
The client wraps the run endpoint with typed options.
Pass the base URL and API key from server-side environment variables.
Typed integration in a Node backend: An Express service uses LangflowClient to run the summarization flow with a per-request tweak for the target length.
QHow do tweaks help when integrating a flow into an application?
Tweaks override component parameters for a single request without changing the saved flow, keyed by component ID. An application can choose a model, temperature, prompt variant or file path per call, run A/B tests, or adapt behaviour per customer tier, while the flow in Langflow stays the single reviewed definition.
Embedding the chat widget
Paste the generated langflow-chat web component snippet into a site to chat with a flow.
The snippet is generated under the flow's sharing options.
It needs a host URL, flow ID and API key, so use a key scoped for public use.
For public sites, put rate limiting and abuse protection in front of the server.
A help widget on a documentation site: The docs team embeds the chat widget on every page so readers can ask questions answered by the documentation RAG flow.
QWhat are the risks of embedding a chat widget that talks to Langflow directly from public web pages?
The key and server are visible to anyone who views the page, so the key can be reused to run the flow at your expense or to probe other flows it can reach. Mitigate with a dedicated key and user with minimal access, a reverse proxy with rate limits and origin checks, a flow without dangerous tools, and monitoring of usage.
Serving flows as MCP tools
Each project is an MCP server: its enabled flows become tools served over streamable HTTP.
The project MCP URL is /api/v1/mcp/project/{project_id}/streamable.
Flow names and descriptions become the tool names and descriptions clients see.
MCP clients authenticate with a Langflow API key.
Company workflows in Claude: An operations team enables its 'incident summary' and 'on-call lookup' flows in a project and adds the project's MCP URL to Claude, which can then call them during incidents.
QWhat should you check before exposing a project's flows to MCP clients?
That only the flows meant to be tools are enabled; that each has a precise name and description, since the client's model chooses tools from them; that inputs are simple; that flows with side effects have approvals or limits; and that clients use dedicated API keys so access can be revoked and audited.
Serving flows as A2A agents
Expose a flow as an Agent2Agent agent that other agents discover through its agent card and call over JSON-RPC.
A2A support is a preview feature.
The agent card describes what the agent can do so other agents can discover it.
Calls go to /api/v1/a2a/{flow_id}/jsonrpc.
Cross-team agent collaboration: A planning agent built elsewhere delegates 'check inventory' tasks to a Langflow inventory agent exposed over A2A.
QHow do MCP and A2A differ in what they expose?
MCP exposes tools (and resources and prompts) for a model or agent to call as functions: the caller stays in control. A2A exposes whole agents that accept tasks, may work over multiple turns and return results: the callee has autonomy. Langflow can do both: project flows as MCP tools, and a single flow as an A2A agent.
Custom components
Writing a custom component
Subclass Component, declare inputs and outputs, and implement the method each output names.
Import from lfx since Langflow 1.7; langflow.custom still works.
Inputs come from lfx.io (such as MessageTextInput, DropdownInput); each Output binds to a method.
Output methods return Message, JSON, Table or primitives.
Example: components/orders/order_lookup.py
from lfx.custom import Component
from lfx.io import MessageTextInput, Output
from lfx.schema import Data
import httpx
class OrderLookup(Component):
display_name = "Order Lookup"
description = "Fetch an order from the internal order service."
icon = "package"
inputs = [MessageTextInput(name="order_id", display_name="Order ID", tool_mode=True)]
outputs = [Output(name="order", display_name="Order", method="lookup")]
def lookup(self) -> Data:
response = httpx.get(f"https://orders.internal/api/orders/{self.order_id}", timeout=10)
response.raise_for_status()
self.status = f"Fetched order {self.order_id}" # shown in the editor
return Data(data=response.json())
Wrapping an internal API: A team writes a component that calls the internal order service with the user's order ID and returns the order as JSON for the agent.
QWhen should you write a custom component instead of using built-ins?
When you need to call an internal system, apply domain logic or data processing that no built-in covers, or package a reusable step with a clean interface for other flow builders. Prefer built-ins when they suffice, because custom code is yours to test, secure and upgrade. Keep each custom component focused, typed and free of hard-coded secrets.
Dynamic fields with update_build_config
Change other fields' visibility or options in the editor when a field marked real_time_refresh changes.
The hook receives the build config, the changed field's value and its name.
Use it to show provider-specific fields or load dropdown options.
Keep it fast: it runs while the user edits the flow.
Provider-aware settings: Choosing 'Azure' in a provider dropdown reveals deployment-name and API-version fields, and hides them for other providers.
QWhat belongs in update_build_config, and what does not?
Editor-time configuration: showing or hiding fields, changing options, setting defaults based on another field. It should not perform the component's real work, make slow network calls on every keystroke, or depend on run-time data, because it executes during editing rather than during a flow run.
Loading and packaging components
Place custom component files in category folders under LANGFLOW_COMPONENTS_PATH so Langflow loads them beside the built-ins.
Each category folder needs an __init__.py; nesting depth is limited to two.
Dependencies a component imports must be installed in Langflow's environment.
Since 1.12.4, input names must not clash with methods such as run, index or log.
Shipping components in a Docker image: The platform team bakes the company's component folder and its Python dependencies into a custom image built from the official one, mounted at the components path.
QHow would you distribute custom components to every Langflow instance in an organization?
Keep them in a versioned repository with tests, build a custom Docker image that installs their dependencies and copies them to the components path (or mount them as a volume), and roll the image out like any other service. Pin Langflow's version in that image, because component APIs can change between releases.
Production & operations
Authentication hardening
Disable auto-login, set a strong superuser password and secret key, and require API keys for every programmatic call.
LANGFLOW_AUTO_LOGIN=false makes the editor require sign-in.
API keys are sent in the x-api-key header and can be revoked individually.
Set LANGFLOW_SECRET_KEY so stored credentials are encrypted with a key you control.
Securing a shared instance: Before opening Langflow to the whole company, the platform team disables auto-login, creates per-team users and API keys, and puts the server behind SSO-protected ingress.
QList the steps to harden a Langflow deployment before exposing it to a network.
Disable auto-login and set a strong superuser password; set a persistent secret key; create users and API keys per consumer; run behind TLS and a reverse proxy; restrict CORS and network access; use backend-only mode for API-only servers; keep secrets in global variables; pin and patch the Langflow version; and monitor logs and usage for abuse.
Secrets and global variables
Store credentials as global variables bound to component fields, never as literal values saved in flows.
Credential-type global variables keep secrets out of exported flow JSON.
Global variables can be populated from environment variables at startup.
X-LANGFLOW-GLOBAL-VAR-* request headers can pass a variable for a single run.
Per-tenant API keys: A multi-tenant app passes each tenant's own model key in an X-LANGFLOW-GLOBAL-VAR-OPENAI_API_KEY header, so usage is billed to the right account.
QWhy is a credential typed directly into a component field a problem?
The field value is saved inside the flow, so it travels with every export, backup, ZIP and Git commit, and anyone with access to the flow can read it. Rotating it means editing every flow that contains it. A credential global variable is stored once, encrypted, referenced by name and rotated in one place.
Database, scaling and deployment
Use PostgreSQL instead of the default SQLite, run multiple workers or replicas, and separate the API from the editor.
PostgreSQL lets state survive restarts and be shared across replicas.
--backend-only serves the API without the visual editor.
Size workers and timeouts for the slowest model calls in your flows.
Production on Kubernetes: An editor instance for builders runs separately from three backend-only API replicas behind a load balancer, all sharing one managed PostgreSQL database.
QWhy separate the editor from the API servers in production?
The editor is an administrative surface used by few people, while the API serves application traffic. Separating them reduces the attack surface of the public-facing servers, lets each scale independently, and allows strict network rules: only builders can reach the editor, while applications reach only the API.
Flow DevOps with LFX
Version flows as files and run or serve them headlessly with the LFX (Langflow Executor) commands.
lfx run executes a flow JSON once without a server, database or UI.
lfx serve exposes flow files over a lightweight FastAPI server.
lfx push and lfx pull sync versioned flows with a remote instance by stable ID.
Example: terminal.sh
# Run a flow once, headless, and print the result
uv run lfx run flows/support.json "Where is order 42?" --format json
# Serve flow files over HTTP (requires LANGFLOW_API_KEY)
uv run lfx serve flows/ --env-file .env
# Validate, then sync versioned flows with a remote Langflow instance
lfx validate flows/support.json
lfx status
lfx push
Testing flows in CI: Every pull request that changes a flow JSON runs lfx run against a set of sample inputs, and the merge is blocked if outputs fail checks.
QHow does LFX change the way you ship Langflow flows?
Flows become artifacts in version control that can be reviewed, tested in CI with lfx run, deployed to a lightweight runtime with lfx serve, or synced to a Langflow instance with lfx push. That brings normal software practice (code review, automated tests, reproducible deploys) to visually built flows, and removes the need for a full server where only execution is required.
Observability and tracing
Read native traces, monitor endpoints and logs, or connect LangSmith or Langfuse to see every component and model call.
Native traces record one trace per run with spans for each component and LLM call, including tokens and latency.
/api/v1/monitor/messages and /monitor/builds expose stored messages and component results.
External tracing sends prompts and outputs to a third party, which matters for sensitive data.
Explaining a cost spike: Traces show one flow's agent looping through a search tool twelve times per question; tightening the instructions halves token usage.
QWhat would you monitor for a Langflow deployment in production?
Per-flow request rate, error rate and latency; token usage and cost per flow; tool-call counts per run to catch loops; queue and worker saturation; database health from the health check; and quality signals such as user feedback or evaluator scores from a connected tracing platform. Alert on errors, latency and cost anomalies.
Upgrades and migrations
Pin the Langflow version, read release notes, and run database migrations deliberately when upgrading.
Component and data-type renames (such as Data to JSON in 1.9) can affect custom code.
Test exported flows on the new version in staging before upgrading production.
A safe minor upgrade: The team upgrades staging, runs migrations, replays its CI flow tests with LFX, fixes one custom component that used a renamed input, then upgrades production.
QWhy pin Langflow's version, and how do you upgrade safely?
Releases change components, data types and APIs, so an unpinned image can change flow behaviour without anyone deciding to. Upgrade by reading the release notes, backing up the database, applying the version in staging, running migrations, re-running flow tests and custom-component tests, and only then promoting the pinned new version to production.
API docs: Concepts
Flow
A flow is a Langflow application: a graph of components connected by typed ports, built in the visual editor, stored as JSON, and run from the Playground, the API, an MCP client or LFX.
Build flows in the visual editor; every node is a component and every connection carries one data type (Message, JSON, Table, Embeddings, LanguageModel...).
A flow ID is a UUID shown in the flow URL and in Share > API access; any endpoint_name alias works wherever the ID does.
Flows are exported and imported as JSON, alone or a whole project as a ZIP, so they can be versioned in Git.
Components & ports
Components are the nodes of a flow. Each one has typed input and output ports, and you connect an output to an input of the same type (port colour) to pass data between them.
Hover a port to see what it accepts; click it to search for compatible components.
Incompatible types need a converter such as the Type Convert component.
Some fields are hidden by default; select a component to edit every parameter in the inspection panel.
Tweaks
Tweaks are one-time, per-request overrides of component parameters. They change a run without changing the saved flow.
To add tweaks to the generated snippets, select a component, open Parameters, and click API on each field you want to expose (saved as api_editable).
Marking a field API only adds it to snippets; the server still accepts other tweaks unless LANGFLOW_TWEAKS_POLICY restricts them.
A refused tweak fails the run with 422 and code: TWEAKS_REFUSED; input_value and session_id are not tweaks and are always accepted.
Session ID
A session ID groups the messages of one conversation. Langflow stores chat messages by session_id, so separate sessions keep separate context within the same flow.
Set it in the API payload or in a component's advanced settings; the API value takes precedence.
A custom session ID set upstream is used by all downstream components that accept one.
Agent memory and the Message History component retrieve history per session_id.
Global variables
Global variables are named, reusable values (credentials or generic settings) stored in Langflow and bound to component fields, so secrets are not typed into flows.
Langflow auto-creates global variables for known provider keys found in the environment, such as OPENAI_API_KEY.
Add more with LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT=VAR1,VAR2 or a JSON list.
LANGFLOW_STORE_ENVIRONMENT_VARIABLES=False stops sourcing variables from the environment.
Tool Mode
Tool Mode turns a component into a tool an Agent can call. The component gets a Toolset port that you connect to the Agent's Tools port.
Any component can be a tool, including another Agent (multi-agent flows) and MCP Tools.
Tool descriptions matter: the agent chooses tools by name and description.
The Playground shows each tool call with its input and raw output, which helps debugging.
Playground
The Playground is the built-in chat and test surface for a flow. It runs the flow, shows messages per session, and exposes tool calls and component output for debugging.
Flows built only from the legacy Text Input/Output components can't chat in the Playground; use Chat Input and Chat Output.
Agent runs stream the input message, each tool call with input and result, tokens and the final answer.
The Shareable Playground publishes a flow's chat at a public URL (not available in Langflow Desktop).
Projects
Projects group flows. Each project can be served as an MCP server, exported as a ZIP and imported elsewhere.
New projects are added to the MCP server configuration automatically unless LANGFLOW_ADD_PROJECTS_TO_MCP_SERVERS=false.
Moving a flow into a project through the API moves it; it isn't copied.
Export a project with GET /api/v1/projects/download/{project_id} and import it with POST /api/v1/projects/upload/.
API docs: CLI & LFX
uv pip install langflow
Install the Langflow OSS Python package into a uv virtual environment. Langflow needs Python 3.10–3.14; Langflow Desktop and Docker are the other install options.
Minimum hardware: dual-core CPU and 2 GB RAM; recommended: multi-core and at least 4 GB RAM.
Default server address after start: http://127.0.0.1:7860 (or localhost:7860).
Langflow Desktop (macOS 13+, Windows) manages dependencies for you but lacks some features, such as the Shareable Playground and Voice Mode.
langflow run
Start the Langflow server (backend and visual editor). Options override the matching LANGFLOW_* environment variables and the .env file.
Boolean options have --option and --no-option forms, e.g. --no-remove-api-keys.
--remove-api-keys strips API keys and tokens from flows saved in the database.
--auto-saving (default on) and --auto-saving-interval 1000 control draft auto-save.
langflow superuser
Create a superuser account with the given username and password.
Controlled by LANGFLOW_ENABLE_SUPERUSER_CLI (default True); set it to False in production to disable this command.
Server-start superuser defaults come from LANGFLOW_SUPERUSER (default username langflow) and LANGFLOW_SUPERUSER_PASSWORD.
Those defaults don't apply to this command; both flags are always required.
langflow api-key
Create a Langflow API key from the command line. Required when the server runs with --backend-only and has no Settings UI.
You must be a superuser; keys created with the CLI therefore have superuser privileges.
An API key adopts the privileges of the user who created it.
Pass the key in an x-api-key header or ?x-api-key= query parameter.
langflow migration
Manage database schema changes with Alembic. The default test mode previews migrations; --fix applies them.
Always run langflow migration first and review the preview before --fix.
Back up the database (SQLite file or PostgreSQL) before applying.
LANGFLOW_ALEMBIC_LOG_TO_STDOUT=True logs Alembic output to stdout instead of a file.
langflow copy-db
Copy langflow.db (and langflow-pre.db if present) from the cache directory into the current Langflow installation directory.
Find the target directory with which langflow.
Only copies files that exist in the cache directory.
For external databases, use LANGFLOW_DATABASE_URL instead.
docker run langflowai/langflow
Run Langflow from the official Docker image. Official images set LANGFLOW_AUTO_LOGIN=false, so a superuser password is required.
For a persistent PostgreSQL setup, use docker compose up in the repository's docker_example directory.
Package flows into an image and load them with LANGFLOW_LOAD_FLOWS_PATH (requires auto-login).
Install Node.js in a custom image if MCP servers use npx.
lfx run
LFX (Langflow Executor) runs a flow JSON or Python script once, statelessly, and streams the result to stdout — no Langflow server, database or UI. No API key is required.
LFX uses a no-op database (NoopSession): nothing is persisted, so stateful features don't work.
Install the bundles that provide the flow's components; missing ones report component-not-found with a hint.
lfx requirements FLOW.json lists extra Python packages the flow needs.
lfx serve
Start a lightweight FastAPI server that exposes one or more flow JSON files at POST /flows/{flow_id}/run. A LANGFLOW_API_KEY is required.
Generate the key locally, e.g. python -c "import secrets; print(secrets.token_urlsafe(32))".
Send {"input_value": "..."} to /flows/{flow_id}/run with the x-api-key header or query parameter.
Stateless: same NoopSession limits as lfx run.
lfx push
Part of the LFX Flow DevOps commands: version flows as files and sync them with a remote Langflow instance by stable ID.
lfx init scaffolds a versioned flow project with CI templates.
lfx login validates credentials against a remote Langflow instance.
Combine with code review: normalise with lfx export so diffs show only real changes.
API docs: REST API
POST /api/v1/run/{flow_id}
Run a flow by ID or endpoint name and get its outputs. This is the main endpoint for using flows in applications; add ?stream=true for token streaming.
Extract the text at outputs[0].outputs[0].results.message.text; responses are verbose.
Optional X-LANGFLOW-GLOBAL-VAR-* headers pass request-scoped global variables.
Missing variables fail the run unless LANGFLOW_FALLBACK_TO_ENV_VAR=True.
POST /api/v1/run/advanced/{flow_id}
Advanced run with explicit inputs, outputs and tweaks lists, plus an optional session_id, for flows with several inputs or outputs.
Use the simple /run endpoint for single-input chat flows.
Refused tweaks return 422 TWEAKS_REFUSED, as on /run.
Requires an API key.
POST /api/v1/webhook/{flow_id}
Start a flow that contains a Webhook component by POSTing any JSON payload. The run starts in the background and the response only confirms it started.
API key required by default (LANGFLOW_WEBHOOK_AUTH_ENABLE=True); when disabled, requests run as the flow owner.
Get a ready-made request from Share > API access > Webhook curl.
Pair Webhook with Parser and reference keys in the template, e.g. {id}, {email}.
POST /api/v2/workflows
Workflow API (Beta): execute a flow in sync, stream or background mode. Stream mode emits Langflow EventManager events or the AG-UI protocol over SSE.
Requires LANGFLOW_DEVELOPER_API_ENABLED=true; otherwise these endpoints return 404.
output.reason is single, multiple, none, non_string or failed; output.text is set only for single.
EventManager events include vertices_sorted, add_message, token, end_vertex, output, end, error and cancelled.
GET /api/v2/workflows
Poll the status and result of a Workflow API job by job_id.
Status values: queued, in_progress, suspended (waiting for human input), completed, failed, cancelled, timed_out.
Prefer re-attaching to /events for live output instead of tight polling.
Beta: the response format may change.
GET /api/v2/workflows/{job_id}/events
Re-attach to a background run's Server-Sent Events: replay buffered events and tail the stream until the job finishes.
Each frame has a monotonic id: line and a data: JSON line.
Use curl -N so the client doesn't buffer.
Also returned as links.events on the job object.
POST /api/v2/workflows/stop
Stop a running Workflow API job by job_id.
Also returned as links.stop on the job object.
Completed steps are not rolled back.
POST /api/v1/responses
OpenAI Responses API–compatible endpoint. Use existing OpenAI client libraries by setting model to a flow ID and authenticating with x-api-key.
The flow must contain a Chat Input component.
The tools parameter isn't supported and returns an error.
OpenAI clients send Authorization: Bearer; set default_headers={'x-api-key': ...} and any placeholder api_key.
POST /api/v1/build/{flow_id}/flow
Internal endpoint used by the visual editor to build and execute a flow, returning a job_id whose events stream from /build/{job_id}/events. Use /run in applications.
Meant for contributors to the Langflow codebase.
Tweaks policy applies here too.
Cancel with POST /api/v1/build/{job_id}/cancel.
POST /api/v1/flows/
Create a flow from a JSON definition. Related endpoints read, update, delete and batch-create flows.
POST /api/v1/flows/batch/ takes {"flows": [...]} and returns an array.
DELETE /api/v1/flows/ deletes several flows by ID.
GET /api/v1/flows/basic_examples/ lists sample flows.
GET /api/v1/flows/
List flows with pagination and filters, optionally scoped to one project.
Read one flow with GET /api/v1/flows/{flow_id}.
Public flows are readable at /api/v1/flows/public_flow/{flow_id}.
PATCH /api/v1/flows/{flow_id}
Update a flow's name, description, data, project, endpoint name or lock state.
Only fields you send are changed.
Delete with DELETE /api/v1/flows/{flow_id}.
POST /api/v1/flows/upload/
Import flows by uploading a Langflow JSON file, optionally into a specific project folder.
List project IDs with GET /api/v1/projects/.
Pair with POST /api/v1/flows/download/ to move flows between servers.
POST /api/v1/flows/download/
Export the listed flows as a ZIP of Langflow JSON files.
Exported JSON can be committed to Git and imported elsewhere.
Set --remove-api-keys on the server to keep keys out of saved flows.
POST /api/v1/projects/
Create a project, optionally moving existing flows and components into it. Read, update and delete use /projects/{project_id}.
PATCH /api/v1/projects/{id} updates only fields you send.
DELETE /api/v1/projects/{id} deletes a project.
GET /api/v1/starter-projects/ lists templates.
GET /api/v1/projects/download/{project_id}
Download all flows in a project as a ZIP; re-import with POST /api/v1/projects/upload/.
Import creates the project and its flows on the target server.
Use for moving a whole project between environments.
POST /api/v1/files/upload/{flow_id}
Upload a file (including images) to a flow with the v1 Files API, then pass the returned file_path to components through tweaks.
v1 files are attached to a flow; list, download and delete with /v1/files/list|download|delete/{flow_id}/....
Images must use v1 — /v2/files doesn't support images.
Send the path to Chat Input with a files tweak, e.g. {"ChatInput-b67sL": {"files": "<file_path>"}}.
POST /api/v2/files
Upload a file owned by the current user (v2). Files are tracked in the database and reusable across flows; supports bulk download and delete.
v2 files are organised by user_id, not flow_id.
v2 doesn't support image files; use the v1 upload for images.
You can only access your own files, even as a superuser.
GET /api/v1/monitor/messages
Read stored chat messages, filtered by flow, session, sender and order. Related endpoints update, delete and re-key messages and sessions.
DELETE /api/v1/monitor/messages deletes by a list of IDs.
PUT /api/v1/monitor/messages/{id} edits message text.
PATCH .../messages/session/{old}?new_session_id= renames a session; DELETE .../messages/session/{id} clears it.
GET /api/v1/monitor/builds
Get (or delete) vertex builds for a flow — the per-component results recorded by Playground and editor runs. Transactions are listed at /monitor/transactions.
Retention: LANGFLOW_MAX_VERTEX_BUILDS_TO_KEEP (3000) and LANGFLOW_MAX_VERTEX_BUILDS_PER_VERTEX (2).
Read native execution traces: one trace per flow run with spans for each component and for LangChain chains, tools, retrievers and LLM calls, including latency and token usage.
Stored in the trace and span tables; shown in Flow Activity and Trace Details pages.
Enabled by default; LANGFLOW_NATIVE_TRACING=false turns it off for an external provider.
Human-in-the-Loop decisions appear as approved/rejected spans in the same trace.
GET /logs-stream
Stream server logs over Server-Sent Events, or fetch a window of logs from GET /logs. Requires a superuser and log retrieval enabled.
Enable with LANGFLOW_ENABLE_LOG_RETRIEVAL=True, LANGFLOW_LOG_RETRIEVER_BUFFER_SIZE=10000, LANGFLOW_LOG_LEVEL=DEBUG.
Note these paths are not under /api/v1.
The TypeScript client exposes client.logs.stream().
POST /api/v1/users/
Create a user account. With authentication enabled, superusers manage accounts through the Users API.
Public self-registration is controlled by LANGFLOW_ENABLE_SIGNUP (default True) and always off with auto-login.
New accounts stay inactive until activated unless LANGFLOW_NEW_USER_IS_ACTIVE=True.
You cannot delete your own account.
GET /api/v1/users/whoami
Return the user that the current API key or session belongs to.
Handy to verify which account a key acts as.
Keys inherit their creator's privileges.
POST /api/v1/api_key/
Create an API key for the current user. GET lists keys and DELETE /api/v1/api_key/{api_key_id} revokes one.
Usage is tracked in total_uses and last_used_at; disable with LANGFLOW_DISABLE_TRACK_APIKEY_USAGE=True under high concurrency.
With LANGFLOW_API_KEY_SOURCE=env, keys are checked against LANGFLOW_API_KEY instead.
A key can't access resources outside its own Langflow server.
GET /health_check
Health check that validates database and chat-service connectivity; returns 500 if a service is unavailable. Also see GET /api/v1/version and /api/v1/config.
GET /health is served by uvicorn before Langflow finishes starting, so it isn't a reliable readiness probe.
/api/v1/config requires an API key.
GET /api/v1/all
Return a dictionary of every available component type. Custom-component endpoints sit alongside it.
Requires an API key.
POST /api/v1/validate/code checks custom component Python before you save it.
/api/v1/mcp/project/{project_id}/streamable
Each Langflow project is an MCP server: its enabled flows become MCP tools, served over streamable HTTP (SSE as fallback) at this URL.
Flows need a Chat Output component to be usable as tools.
Give tools clear names and descriptions in Projects > MCP Server > Edit Tools — the default name is the flow ID.
Tool timeout defaults to 180 s; raise with LANGFLOW_MCP_TOOL_EXECUTION_TIMEOUT or per component.
POST /api/v1/a2a/{flow_id}/jsonrpc
Serve a flow as an Agent2Agent (A2A) agent. Clients discover it through its agent card and call it over JSON-RPC.
Off by default since 1.11: set LANGFLOW_A2A_ENABLED=true.
The flow needs a Chat Input (or Human Input) and a Chat Output.
Publish from the editor's Agent pane: toggle Serve as an A2A agent, then Save (status Live).
API docs: Components
Chat Input
Entry point for chat flows. Builds a Message from the user's text (and files) and passes it on; required for the Playground, embedded chat and the Responses API.
API runs fill input_value from the request.
Send files by uploading them and tweaking files with the returned path.
Text Input/Output are legacy and don't support chat context.
Chat Output
Displays and returns the flow's reply as a Message. Its output is what /run returns and what MCP tools and the Playground show.
A flow needs Chat Output to be served as an MCP tool.
Use output_component in /run to pick between several outputs.
Agent
The core agent component: an LLM that reasons over the input, calls connected tools and replies. Includes built-in chat memory per session.
Configure providers in Settings > Model Providers; one key per provider.
Structured Response makes a separate LLM call and doesn't write chat history.
Use Message History only for external memory such as Mem0 or extra filtering.
Language Model
Call an LLM from any configured provider. Outputs a Message reply, or a LanguageModel instance for components that need a model.
Switch the output type to Language Model to feed Structured Output, Smart Router or Batch Run.
Provider-specific model components live in bundles.
Embedding Model
Produce vector embeddings with a configured provider for vector stores and the Knowledge Base.
Connect to a vector store's Embedding port.
The same model must be used for ingest and query.
Prompt Template
Build a prompt from a template. Each {variable} becomes an input port; enable double brackets for Mustache {{variable}} syntax.
Each placeholder adds a field you can fill or connect.
Use Mustache mode when the prompt includes JSON examples.
Message History
Retrieve or store chat messages by session from Langflow storage or external memory.
Agents have built-in memory; this component is needed for external memory or extra control.
Session ID defaults to the current run's session.
Structured Output
Use an LLM to extract structured data that matches an Output Schema table.
Choose the output type next to the output port.
Pairs well with Loop to process many records.
Parser
Format JSON or Table data into text with a template, or stringify it.
The usual partner of Webhook.
Stringify mode is the quickest way to see raw payloads.
Split Text
Split text into overlapping chunks by a separator, ready for embedding.
Accepts Message, JSON or Table input.
Overlap preserves context across chunk boundaries.
Loop
Iterate over a list of JSON or Table items: each item goes out of the Item port, comes back through Looping, and the aggregate leaves from Done.
The last component in the item chain must connect back to Looping.
If-Else isn't compatible with Loop; filter data before looping instead.
If-Else
Route a message to a True or False branch by comparing text.
Case sensitivity doesn't apply to regex.
Use Smart Router for LLM-based categorisation.
Smart Router
Let an LLM classify input into routes defined in a table; each route is an output, with an optional Else.
The LLM returns the exact route name.
Override Output replaces the message on any route.
Run Flow
Run another flow as a sub-flow, with generated inputs and optional tweaks; also usable as an agent tool.
Internal sub-flow calls aren't restricted by LANGFLOW_TWEAKS_POLICY=off.
Enable Tool Mode to let an agent call the sub-flow.
URL
Fetch and recursively crawl web pages and return their content as text, Markdown or HTML.
Common agent tool.
SSRF protection settings (LANGFLOW_SSRF_*) govern private hosts.
Web Search
Search the web (DuckDuckGo), news (Google News) or RSS feeds and return results as a Table.
Enable Tool Mode to give agents live search.
Lower max_content_length to save tokens.
Python Interpreter
Execute Python code in a flow, with an allowlist of importable modules. Can run in an isolated microVM.
Set LANGFLOW_SANDBOX_BACKEND=exec-sandbox to run each execution in a QEMU microVM (requires langflow[sandbox]).
Sandbox limits: LANGFLOW_SANDBOX_TIMEOUT_SECONDS (30), LANGFLOW_SANDBOX_MEMORY_MB (192), network off by default.
LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true blocks code-execution components for untrusted users.
MCP Tools
Connect a flow to an MCP server (stdio, HTTP or SSE) so an Agent can use its tools; can also connect to Langflow's own project MCP servers.
Register servers first; since 1.9 MCP Tools isn't a draggable palette component.
uvx ships with Langflow; npx servers need Node.js (install it in Docker images).
Header values can reference global variables; incoming x-api-key can be propagated to nested servers.
Webhook
Start a flow from an external HTTP POST. Outputs the received payload as JSON.
Usually followed by Parser.
Responses only confirm the run started.
Knowledge Base
Ingest data into a local knowledge base with embeddings, or retrieve from it by semantic similarity and metadata filters.
The embedding model is chosen when the knowledge base is created.
allow_duplicates is off by default.
Guardrails
Validate input text with an LLM against security guardrails (PII, secrets, jailbreak, offensive or malicious content) and custom rules.
Place it before the agent or model.
Custom guardrails are described in plain language.
Batch Run
Run a language model over every row of a Table and add the responses as a new column.
Requires a LanguageModel input.
Good alternative to Loop for one-call-per-row jobs.
Human Input
Pause a flow at a checkpoint and wait for a human decision; each User Action becomes an output branch. Completed steps aren't re-run on resume.
Agents can instead mark individual tools as requiring approval.
Decisions are recorded as spans in traces.
langflow-chat
Embeddable chat widget web component. Paste the generated snippet into a site to chat with a flow.
Get it from Share > Embed into site.
The flow needs Chat Input and Chat Output.
Angular needs CUSTOM_ELEMENTS_SCHEMA; React needs a JSX declaration.
API docs: Python & TypeScript
Component
Base class for custom Python components. Subclass it, declare inputs and outputs, and implement the output methods.
Import from lfx since 1.7; langflow.custom still works.
Place files in a category folder with __init__.py under LANGFLOW_COMPONENTS_PATH; max depth 2.
Hooks: _pre_run_setup() and overriding _run.
Output
Declares an output port on a custom component and the method that produces it.
Annotate methods (-> Message, -> Data, -> DataFrame) for colour-coding and connection validation.
Use group_outputs=True for branch-like components (True/False).
update_build_config
Hook called when a field with real_time_refresh=True changes; adjust other fields' visibility or options in the editor.
Mark dependent inputs dynamic=True and show=False initially.
Keep it fast — it runs on every change.
Message
Chat message data type: extends JSON with text, sender, session_id, files and content blocks.
Most chat components accept any Message-compatible input.
Errors from the LLM appear in content_blocks.
JSON
Structured data type (named Data before Langflow 1.9): a .data dict plus a text_key naming the primary text field.
Old flows using Data load unchanged.
Connects only to JSON (Data) inputs.
Table
Tabular data type (named DataFrame before 1.9): a pandas DataFrame subclass with Langflow helpers.
Full pandas API.
Keeps text_key/default_value for JSON compatibility.
LangflowClient
Official TypeScript client for the Langflow API: run or stream flows, pass tweaks and session IDs, and stream logs.
Install with npm install @datastax/langflow-client.
chatOutputText() returns just the Chat Output text.
Number of server worker processes. Multiple workers need a shared job queue.
Set LANGFLOW_JOB_QUEUE_TYPE=redis for more than one worker.
LANGFLOW_WORKER_TIMEOUT defaults to 300 seconds.
Running several workers without a shared queue requires LANGFLOW_DANGEROUSLY_ALLOW_MULTI_WORKER_WITHOUT_SHARED_QUEUE and breaks the UI and MCP over SSE.
LANGFLOW_CONFIG_DIR
Directory where Langflow stores files, logs, monitor data and secret keys (and the database if LANGFLOW_SAVE_DB_IN_CONFIG_DIR=True).
Mount it as a volume in containers so data survives restarts.
Logs go to LANGFLOW_LOG_FILE when set.
LANGFLOW_TWEAKS_POLICY
Limits which component fields API callers may change through tweaks.
permissive: almost any field (code and privileged fields stay blocked).
declared: only fields marked API on the flow; a flow with none behaves as permissive.
off: no tweaks; input_value and session_id still work.
LANGFLOW_WEBHOOK_AUTH_ENABLE
Whether webhook endpoints require an API key and check that the caller owns the flow.
With False, requests are treated as sent by the flow owner — use only in trusted networks.
Pass the key as an x-api-key header or query parameter.
LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT
Extra environment variable names to import as global variables at startup.
Lists only names; values come from the environment.
Known provider keys like OPENAI_API_KEY are imported automatically.
LANGFLOW_CACHE_TYPE
Backend for Langflow's internal cache: async, redis or memory.
With redis, set LANGFLOW_REDIS_HOST, _PORT (6379), _DB, _PASSWORD and _CACHE_EXPIRE (3600).
LANGFLOW_LANGCHAIN_CACHE picks InMemoryCache or SQLiteCache for LangChain.
LANGFLOW_LOAD_FLOWS_PATH
Directory of flow JSON files loaded on startup, typically baked into a Docker image.