This document describes the manual release workflow for publishing stable and pre-release versions of Langflow packages to PyPI and Docker registries. The release process is triggered manually via GitHub Actions and follows a strict dependency order to ensure package compatibility across the lfx, langflow-base, langflow-sdk, and langflow packages.
For automated nightly builds, see Nightly Builds. For the continuous integration pipeline that validates code changes, see CI Pipeline.
The release process is defined in .github/workflows/release.yml1-60 and orchestrates the build, test, and publication of four Python packages and their corresponding Docker images.
The following diagram illustrates the transition from manual trigger to final publication, mapping workflow jobs to their respective code entities.
Sources: .github/workflows/release.yml1-60 .github/workflows/ci.yml1-191 .github/workflows/docker-build.yml1-30
The release workflow is triggered manually via GitHub Actions with the following parameters:
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
release_tag | string | Yes | - | Git tag containing source code (e.g., v1.8.1) |
release_package_base | boolean | Yes | false | Build and publish langflow-base package |
release_package_main | boolean | Yes | false | Build and publish langflow package |
release_lfx | boolean | No | false | Build and publish lfx package |
release_sdk | boolean | No | false | Build and publish langflow-sdk package |
release_bundles | boolean | No | false | Release all src/bundles/* packages (required for main) |
build_docker_base | boolean | Yes | false | Build Docker images for langflow-base |
build_docker_main | boolean | Yes | false | Build Docker images for langflow |
pre_release | boolean | No | false | Mark as pre-release (e.g., 1.8.1rc1) |
create_release | boolean | No | false | Whether to create a GitHub release |
dry_run | boolean | No | true | Test mode - disables external publishing to PyPI/Docker |
Sources: .github/workflows/release.yml6-65
Before execution, the workflow performs critical validation steps:
release_tag exists as a git tag and is not a branch .github/workflows/release.yml95-108v prefix and follows semver format (e.g., v1.2.3). It also checks for duplicate tags without the v prefix .github/workflows/release.yml122-150langflow-base must be released if langflow is enabled, and langflow-sdk must be released if lfx is enabled. Additionally, release_bundles must be enabled if releasing the main package, as the main package pins exact bundle versions .github/workflows/release.yml158-176Sources: .github/workflows/release.yml152-178
Versions are dynamically extracted from the source tree at the specified release_tag.
uv tree output looking for langflow-base .github/workflows/docker-build.yml142uv tree | grep -E '^langflow(-nightly)?[[:space:]]' .github/workflows/docker-build.yml153uv tree in src/lfx .github/workflows/release_nightly.yml97-98src/sdk/pyproject.toml .github/workflows/release_nightly.yml82-83Sources: .github/workflows/docker-build.yml138-156 .github/workflows/release_nightly.yml79-109
Builds follow a strict sequence to allow local wheel installation for integration testing.
make sdk_build args="--wheel" .github/workflows/release_nightly.yml113uv build --wheel --out-dir dist in src/lfx. It validates that the local SDK wheel is used .github/workflows/release_nightly.yml117-128make build_langflow_base args="--wheel" .github/workflows/cross-platform-test.yml65-66make build_langflow args="--wheel". Frontend assets are bundled into the package during this step .github/workflows/cross-platform-test.yml80-81src/bundles/* is built as a wheel into a dedicated directory .github/workflows/cross-platform-test.yml82-99Sources: .github/workflows/release_nightly.yml111-144 .github/workflows/cross-platform-test.yml61-100
All release artifacts are validated on a matrix of OS and Python versions before publication using the cross-platform-test.yml workflow .github/workflows/cross-platform-test.yml1-37
| OS | Architecture | Python Versions |
|---|---|---|
| Linux | AMD64 | 3.10, 3.12 .github/workflows/cross-platform-test.yml150-157 |
| macOS | AMD64 | 3.10, 3.12 .github/workflows/cross-platform-test.yml159-166 |
| macOS | ARM64 | 3.10, 3.12 .github/workflows/cross-platform-test.yml168-175 |
| Windows | AMD64 | 3.10, 3.12 .github/workflows/cross-platform-test.yml177-184 |
The test procedure involves:
astral-sh/setup-uv .github/workflows/cross-platform-test.yml203-208uv pip install .github/workflows/cross-platform-test.yml230-260/health_check endpoint is reachable .github/workflows/cross-platform-test.yml270-290Sources: .github/workflows/cross-platform-test.yml141-210
Packages are published to PyPI using uv publish. This step is protected by the dry_run input in the release workflow. The workflow ensures that the package name and version match the expected nightly or stable tags before proceeding .github/workflows/release_nightly.yml188-202
Docker images are built and pushed using the docker-build.yml workflow .github/workflows/docker-build.yml1-30
langflowai/langflow tagged with the version and latest.main, main-ep, base, nightly-main, nightly-base, main-all, and nightly-main-all .github/workflows/docker-build.yml17Sources: .github/workflows/docker-build.yml1-162 .github/workflows/release_nightly.yml188-205
The nightly build process (.github/workflows/nightly_build.yml) runs daily at 00:00 UTC .github/workflows/nightly_build.yml37 It identifies the latest release-* branch .github/workflows/nightly_build.yml60-65 generates date-stamped tags, and performs a full build and test cycle.
The system uses specialized scripts to calculate next nightly versions:
scripts/ci/pypi_nightly_tag.py: Generates the next version for main/base .github/workflows/nightly_build.yml114-119scripts/ci/lfx_nightly_tag.py: Generates the next version for the LFX package .github/workflows/nightly_build.yml138-142scripts/ci/sdk_nightly_tag.py: Generates the next version for the SDK package .github/workflows/nightly_build.yml146-150The versions are updated in the workspace using scripts/ci/update_pyproject_combined.py and scripts/ci/update_sdk_version.py before committing and pushing the nightly tag .github/workflows/nightly_build.yml163-174
Sources: .github/workflows/nightly_build.yml1-186 .github/workflows/release_nightly.yml1-145
The release workflow utilizes several protected secrets to interact with external registries:
OPENAI_API_KEY, ANTHROPIC_API_KEY, STORE_API_KEY, TAVILY_API_KEY: Required for integration and frontend tests during the release cycle .github/workflows/typescript_test.yml5-13 .github/workflows/ci.yml71-74CODECOV_TOKEN: Used for uploading test coverage reports .github/workflows/python_test.yml10-11The codebase uses detect-secrets via .secrets.baseline to ensure that no sensitive credentials are committed to the repository, including internal service tokens and API keys used in tests .secrets.baseline1-88
Sources: .github/workflows/typescript_test.yml1-13 .github/workflows/ci.yml71-74 .github/workflows/python_test.yml1-11 .secrets.baseline1-88
Refresh this wiki