94e8bf1e2b* feat: Add support for running flows by endpoint name
This commit modifies the `simplified_run_flow` endpoint in `endpoints.py` to allow running flows using the endpoint name instead of the flow ID. It introduces a new route parameter `flow_id_or_name` which can accept either a UUID or a string representing the endpoint name. The code first attempts to parse the parameter as a UUID, and if that fails, it queries the database to find a flow with the matching endpoint name. This change improves the usability of the API by providing an alternative way to identify flows for execution.
* feat: Add endpoint_name field to FlowType
This commit adds the `endpoint_name` field to the `FlowType` interface in the `index.ts` file. The `endpoint_name` field is an optional string that represents the name of the endpoint associated with the flow. This change allows for more flexibility in identifying flows by endpoint name instead of just the flow ID. It improves the usability of the codebase by providing an alternative way to reference flows.
* 🐛 (endpoints.py): change type of flow_id_or_name parameter from Union[str, UUID] to str to simplify the API and improve readability
* feat: Add migration utility functions for table, column, foreign key, and constraint existence checks
This commit adds utility functions to the `migration.py` module in the `langflow.utils` package. These functions provide convenient ways to check the existence of tables, columns, foreign keys, and constraints in a database using SQLAlchemy. The functions `table_exists`, `column_exists`, `foreign_key_exists`, and `constraint_exists` take the table name, column name, foreign key name, and constraint name respectively, along with the SQLAlchemy engine or connection object. They use the `Inspector` class from `sqlalchemy.engine.reflection` to retrieve the necessary information and return a boolean value indicating whether the specified element exists in the database. These utility functions improve the readability and maintainability of the codebase by encapsulating the common existence checks in a reusable and modular way.
* feat: Add unique constraints for per-user folders and flows
This commit adds unique constraints for per-user folders and flows in the database. It introduces the `unique_folder_name` constraint for the `folder` table, ensuring that each user can have only one folder with a specific name. Similarly, it adds the `unique_flow_endpoint_name` and `unique_flow_name` constraints for the `flow` table, enforcing uniqueness of endpoint names and flow names per user. These constraints improve data integrity and prevent duplicate entries in the database, providing a more robust and reliable system.
* feat: Add poetry installation and caching steps to GitHub Actions workflow
This commit updates the GitHub Actions workflow file `action.yml` to include additional steps for installing poetry and caching its dependencies. The `run` step now installs poetry using the specified version and ensures that the poetry binary is available in the PATH. Additionally, the workflow now includes a step to restore pip and poetry cached dependencies using the `actions/cache` action. These changes improve the workflow by providing a more efficient and reliable way to manage poetry dependencies and caching.
* refactor: Improve error handling in update_flow function
This commit improves the error handling in the `update_flow` function in `flows.py`. It adds a new `elif` condition to check if the exception is an instance of `HTTPException` and re-raises it. This ensures that any `HTTPException` raised during the update process is properly handled and returned as a response. Additionally, it removes the unnecessary `else` block and simplifies the code logic. This refactor enhances the reliability and maintainability of the `update_flow` function.
|
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| .vscode | ||
| deploy | ||
| docker | ||
| docker_example | ||
| docs | ||
| scripts | ||
| src | ||
| tests | ||
| .env.example | ||
| .eslintrc.json | ||
| .gitattributes | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| eslint.config.js | ||
| LICENSE | ||
| Makefile | ||
| poetry.lock | ||
| pyproject.toml | ||
| README.md | ||
| render.yaml | ||
A visual framework for building Gen-AI and RAG apps with LangChain
Open-source, Python-powered, fully customizable, LLM and vector store agnostic
Docs - Join our Discord - Follow us on X - Live demo
📝 Content
📦 Get Started
You can install Langflow with pip:
# Make sure you have Python 3.10 or greater installed on your system.
# Install the pre-release version (recommended for the latest updates)
python -m pip install langflow --pre --force-reinstall
# or stable version
python -m pip install langflow -U
Then, run Langflow with:
python -m langflow run
You can also preview Langflow in HuggingFace Spaces. Clone the space using this link to create your own Langflow workspace in minutes.
🎨 Create Flows
Creating flows with Langflow is easy. Simply drag components from the sidebar onto the canvas and connect them to start building your application.
Explore by editing prompt parameters, grouping components into a single high-level component, and building your own Custom Components.
Once you’re done, you can export your flow as a JSON file.
Load the flow with:
from langflow.load import run_flow_from_json
results = run_flow_from_json("path/to/flow.json", input_value="Hello, World!")
Deploy
Deploy Langflow on Google Cloud Platform
Follow our step-by-step guide to deploy Langflow on Google Cloud Platform (GCP) using Google Cloud Shell. The guide is available in the Langflow in Google Cloud Platform document.
Alternatively, click the "Open in Cloud Shell" button below to launch Google Cloud Shell, clone the Langflow repository, and start an interactive tutorial that will guide you through the process of setting up the necessary resources and deploying Langflow on your GCP project.
Deploy on Railway
Use this template to deploy Langflow 1.0 Preview on Railway:
Or this one to deploy Langflow 0.6.x:
Deploy on Render
🖥️ Command Line Interface (CLI)
Langflow provides a command-line interface (CLI) for easy management and configuration.
Usage
You can run the Langflow using the following command:
langflow run [OPTIONS]
Each option is detailed below:
--help: Displays all available options.--host: Defines the host to bind the server to. Can be set using theLANGFLOW_HOSTenvironment variable. The default is127.0.0.1.--workers: Sets the number of worker processes. Can be set using theLANGFLOW_WORKERSenvironment variable. The default is1.--timeout: Sets the worker timeout in seconds. The default is60.--port: Sets the port to listen on. Can be set using theLANGFLOW_PORTenvironment variable. The default is7860.--env-file: Specifies the path to the .env file containing environment variables. The default is.env.--log-level: Defines the logging level. Can be set using theLANGFLOW_LOG_LEVELenvironment variable. The default iscritical.--components-path: Specifies the path to the directory containing custom components. Can be set using theLANGFLOW_COMPONENTS_PATHenvironment variable. The default islangflow/components.--log-file: Specifies the path to the log file. Can be set using theLANGFLOW_LOG_FILEenvironment variable. The default islogs/langflow.log.--cache: Selects the type of cache to use. Options areInMemoryCacheandSQLiteCache. Can be set using theLANGFLOW_LANGCHAIN_CACHEenvironment variable. The default isSQLiteCache.--dev/--no-dev: Toggles the development mode. The default isno-dev.--path: Specifies the path to the frontend directory containing build files. This option is for development purposes only. Can be set using theLANGFLOW_FRONTEND_PATHenvironment variable.--open-browser/--no-open-browser: Toggles the option to open the browser after starting the server. Can be set using theLANGFLOW_OPEN_BROWSERenvironment variable. The default isopen-browser.--remove-api-keys/--no-remove-api-keys: Toggles the option to remove API keys from the projects saved in the database. Can be set using theLANGFLOW_REMOVE_API_KEYSenvironment variable. The default isno-remove-api-keys.--install-completion [bash|zsh|fish|powershell|pwsh]: Installs completion for the specified shell.--show-completion [bash|zsh|fish|powershell|pwsh]: Shows completion for the specified shell, allowing you to copy it or customize the installation.--backend-only: This parameter, with a default value ofFalse, allows running only the backend server without the frontend. It can also be set using theLANGFLOW_BACKEND_ONLYenvironment variable.--store: This parameter, with a default value ofTrue, enables the store features, use--no-storeto deactivate it. It can be configured using theLANGFLOW_STOREenvironment variable.
These parameters are important for users who need to customize the behavior of Langflow, especially in development or specialized deployment scenarios.
Environment Variables
You can configure many of the CLI options using environment variables. These can be exported in your operating system or added to a .env file and loaded using the --env-file option.
A sample .env file named .env.example is included with the project. Copy this file to a new file named .env and replace the example values with your actual settings. If you're setting values in both your OS and the .env file, the .env settings will take precedence.
👋 Contribute
We welcome contributions from developers of all levels to our open-source project on GitHub. If you'd like to contribute, please check our contributing guidelines and help make Langflow more accessible.
🌟 Contributors
📄 License
Langflow is released under the MIT License. See the LICENSE file for details.