Flowise

Provides a React-based canvas UI where users drag LLM components (models, chains, tools, memory) onto a graph and connect them via edges. The system uses a node registry (NodesPool) that loads pre-built component definitions, validates connections via TypeScript schema validation, and serializes the graph structure to JSON for persistence. Execution traverses the DAG at runtime, resolving variable dependencies and streaming outputs back to the UI via WebSocket.

Implements a model registry that abstracts over OpenAI, Anthropic, Ollama, HuggingFace, and other LLM providers through a unified interface. Credentials are encrypted and stored per-user in the database; at runtime, the system instantiates the correct provider client based on node configuration and routes API calls through a credential resolver that injects secrets without exposing them in flow definitions. Supports both chat and embedding models with provider-specific parameter mapping.

Implements a queue-based execution model where flows are submitted as jobs to a message queue (Redis, Bull, etc.) and processed by a pool of worker processes. This decouples flow submission from execution, enabling asynchronous processing and horizontal scaling. The system tracks job status (pending, running, completed, failed), stores results in the database, and provides webhooks for job completion notifications. Workers are stateless and can be scaled up/down based on queue depth.

Implements multi-tenancy at the database and credential level, where each user has isolated flows, credentials, and chat history. Flows are scoped to users via foreign keys; credentials are encrypted per-user and never shared across tenants. The system enforces access control at the API level, preventing users from accessing other users' flows or credentials. Supports both single-tenant (self-hosted) and multi-tenant (SaaS) deployments with configurable isolation levels.

Provides document loader nodes that ingest data from multiple sources: local files (PDF, DOCX, TXT), web pages (via web scraper), databases (SQL queries), and APIs. Each loader parses the source format, extracts text, and outputs chunks ready for embedding. Loaders support metadata extraction (title, author, URL) and can be chained with text splitters for further processing. Web scrapers handle pagination and JavaScript-rendered content (via Playwright).

Implements streaming execution where LLM responses are sent to the client token-by-token as they are generated, rather than waiting for the complete response. The system uses Server-Sent Events (SSE) or WebSocket to push tokens to the client in real-time, providing a ChatGPT-like experience. Streaming is transparent to the flow definition; users don't need to configure anything—it's automatic for LLM nodes. Supports both text streaming and structured output streaming (JSON).

Implements a prompt templating system where users define prompts with variable placeholders (e.g., `{context}`, `{user_input}`) that are dynamically filled at execution time. Variables can come from upstream nodes, user input, or flow-level context. The system supports conditional prompts (if-else logic) and prompt chaining (output of one prompt feeds into another). Supports both simple string interpolation and complex template languages (Handlebars, Jinja2).

Manages chat history and context through a memory abstraction layer that supports multiple backends (buffer memory, summary memory, entity memory). The system persists conversation history to the database, retrieves relevant context based on message count or summarization, and injects it into the LLM prompt at execution time. Supports both stateless (per-request context) and stateful (session-based) memory modes, with configurable window sizes and summarization strategies.

Implements a tool registry where users define tools (API calls, database queries, custom functions) as nodes with JSON schema specifications. At runtime, the LLM generates tool calls based on the schema, the system routes calls to the correct tool handler, executes the function (with optional sandboxing for custom code), and returns results back to the LLM for further reasoning. Supports both LangChain tool bindings and custom function nodes with parameter validation.

Provides nodes for document loading, chunking, embedding, and vector store operations (Pinecone, Weaviate, Supabase, Milvus, etc.). Users compose RAG flows by connecting a document loader → text splitter → embedding model → vector store node. At runtime, documents are chunked, embedded using the configured embedding model, and stored in the vector database. Retrieval nodes query the vector store with semantic similarity, returning top-k results that are injected into the LLM prompt. Supports both in-memory and persistent vector stores.

Implements agentic execution patterns (ReAct, Plan-and-Execute) where the LLM reasons about available tools, decides which to call, executes them, and iterates until a final answer is reached. The system manages the agent loop by maintaining state across iterations, tracking tool calls and results, and enforcing max-step limits to prevent infinite loops. Supports both synchronous agents (single-turn reasoning) and multi-turn agents (conversation-based reasoning). Execution is observable via step-by-step logs showing LLM thoughts, tool calls, and results.

Allows users to define custom logic nodes that execute arbitrary JavaScript or Python code in a sandboxed environment. The sandbox restricts access to dangerous libraries (file system, network) while allowing data transformation, calculation, and conditional logic. Code nodes receive inputs from upstream nodes, execute the user-defined function, and pass outputs to downstream nodes. Execution is isolated per-invocation, preventing state leakage between runs.

Enables users to export flows as JSON files that capture the complete graph structure, node configurations, and connections. Exported flows can be imported by other users, restoring the graph and all node settings. The system includes a marketplace where users can publish flows as templates, making them discoverable and reusable by the community. Import validates flow schema, handles version compatibility, and allows users to override credentials before importing.

Generates a standalone JavaScript widget (iframe or embedded component) that can be embedded on external websites to expose a chatflow as a user-facing chatbot. The widget communicates with the Flowise backend via REST API or WebSocket, sends user messages, and displays streamed responses. Supports customization (colors, fonts, branding) via configuration parameters. The widget handles session management, message history, and typing indicators without requiring backend changes.

Automatically generates REST API endpoints for each chatflow, allowing external applications to invoke flows programmatically. Each endpoint accepts POST requests with input variables, executes the flow, and returns the result as JSON. The system generates OpenAPI/Swagger documentation for all endpoints, enabling API discovery and client generation. Endpoints support authentication (API keys), rate limiting, and request/response logging.