Kubeflow Pipelines is a platform for building and deploying portable, scalable machine learning workflows based on Docker containers within the Kubeflow project.
Use Kubeflow Pipelines to compose a multi-step workflow (pipeline) as a graph of containerized tasks using Python code and/or YAML. Then, run your pipeline with specified pipeline arguments, rerun your pipeline with new arguments or data, schedule your pipeline to run on a recurring basis, organize your runs into experiments, save machine learning artifacts to compliant artifact registries, and visualize it all through the Kubeflow Dashboard.
Installation
To install kfp, run:
pip install kfp
Preview pipelines locally
kfp visualize reads Python (.py) or compiled KFP v2 specifications
(.yaml, .yml, .json), without a cluster or server credentials:
# Offline, interactive React Flow HTML (defaults to pipeline.html).
kfp visualize pipeline.py
# Select a function when a Python file defines multiple pipelines.
kfp visualize pipeline.py --function training -o training.html
# Mermaid diagrams in Markdown; the output extension selects the format.
kfp visualize pipeline.yaml -o pipeline.md
# Equivalent: kfp visualize pipeline.yaml --format markdown
# Regenerate HTML on saved changes, without starting a server.
kfp visualize pipeline.py -w
# Regenerate Markdown for an editor or third-party Mermaid viewer.
kfp visualize pipeline.py --format markdown -w
# Compile once per change and update both pipeline.html and pipeline.md.
kfp visualize pipeline.py --format both -w
# Choose another output stem: report.html and report.md.
kfp visualize pipeline.py --format both -o report -w
# Serve a live preview and automatically open it in the default browser.
kfp visualize pipeline.py --format both -w -s
# Serve and open a snapshot without watching for edits.
kfp visualize pipeline.py -s
# Serve without launching a browser (useful on remote/headless machines).
kfp visualize pipeline.py -w -s --no-open
# Short form: kfp visualize pipeline.py -w -s -n
--format accepts html, both, or markdown, defaulting to HTML. When
--format is omitted, an explicit .html or .md output path selects the
format. With both, -o report, -o report.html, and -o report.md all produce
report.html and report.md. Both artifacts are rendered and staged before
either destination is replaced. Each replacement is atomic, but the pair is
not a filesystem transaction.
HTML exports include JavaScript, styles, data, and third-party licenses: they
work offline, including in HTML previewers that permit JavaScript. They contain
the same graph canvas, task/artifact cards, inline DAG expansion, controls, and
node inspector as the KFP pipeline UI. Markdown exports contain one Mermaid
task-dependency diagram per DAG and need a Mermaid-aware renderer. Both show
static dependencies, including parameter/artifact inputs and explicit ordering;
loops are not unrolled, and no runtime execution status is shown. Legacy Argo
Workflow YAML and standalone component specs are not supported. Compiler multi-document YAML and Kubernetes PipelineVersion
manifests are supported. JSON files use JSON parsing to preserve Unicode and
numeric constants.
HTML validates reusable DAG definitions once and keeps the spec compact.
Markdown expands instance paths, with a limit of 10,000 DAGs, tasks, and
dependency edges in total; use HTML for pipelines that exceed this limit.
Missing/empty task display names and incomplete task-output or final-status
producer references are rejected before replacing an export. All formats require
a deploymentSpec field so their validated state can also be served by the shared
KFP graph/inspector; an explicit empty object is supported. Removing the field
or a producer name during an edit preserves the previous exports and preview.
-w is a short alias for --watch. Watching only updates files; it never
starts a server unless --serve / -s is also supplied. Watch mode observes
saved files, not unsaved editor buffers. Python inputs are recompiled in a
fresh process after changes to .py files beneath the
input's directory (excluding hidden directories, venv, node_modules, and
__pycache__). Imports outside that directory and non-Python configuration files
are not watched. YAML/JSON inputs watch only the input file. Compilation has a
60-second timeout. Compilation, rendering, or staging failures preserve the
last successful exports and print the error; the live HTML viewer also displays
it and recovers on the next valid change. Third-party HTML/Markdown viewers
control their own reload behavior.
--serve / -s serves an HTML preview with any export format and opens the
preview once in the default browser after the server starts. The launch attempt
runs in the background, so a browser command that waits for its window to close
does not block updates. Stopping the CLI does not wait for or close the browser.
By itself it serves a snapshot; combine it with --watch / -w for live updates. Pass --no-open /
-n to keep serving without launching a browser. The URL is always printed, and
if automatic launch fails, serving continues with a warning so you can open it
manually. Plain exports and watch-only commands never launch a browser.
The server binds only to
127.0.0.1 on an automatically selected port and serves only the viewer and its
graph data, not the workspace. Keep it private: the graph includes component
specifications. A separately opened .html file is an offline snapshot, not a
live connection. Remote environments require port forwarding to reach the
printed URL; retain its 127.0.0.1:<port> Host and token path. Stop with Ctrl+C.
Only compile trusted Python: importing a pipeline executes its module-level code, including arbitrary side effects. The visualizer does not itself submit runs. Exported task/component specifications can contain source code or literal credentials; review them before sharing.
Getting started
The following is an example of a simple pipeline that uses the kfp v2 syntax:
from kfp import dsl
import kfp
@dsl.component
def add(a: float, b: float) -> float:
'''Calculates sum of two arguments'''
return a + b
@dsl.pipeline(
name='Addition pipeline',
description='An example pipeline that performs addition calculations.')
def add_pipeline(
a: float = 1.0,
b: float = 7.0,
):
first_add_task = add(a=a, b=4.0)
second_add_task = add(a=first_add_task.output, b=b)
client = kfp.Client(host='<my-host-url>')
client.create_run_from_pipeline_func(
add_pipeline, arguments={
'a': 7.0,
'b': 8.0
})
Metadata
Release files for kfp 2.18.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| kfp-2.18.0.tar.gz | 1.1 MB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| kfp-2.18.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 2.3 MB
Release files / kfp-2.18.0.tar.gz
| Download URL | kfp-2.18.0.tar.gz |
|---|---|
| Size | 1.1 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
8331041be2a8cca9188e5a4c716844afbb163cd0f34983654f40fee50b7dd451
|
|
BLAKE2b-256 checksum How to use checksums |
d68aed632db82041b4238ea423ad2dfd0ee4c5c37ac15d46f9a762b0c75ca5a3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 28, 2026.
Transparency logRelease files / kfp-2.18.0-py3-none-any.whl
| Download URL | kfp-2.18.0-py3-none-any.whl |
|---|---|
| Size | 1.2 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
4afaeb45fd923c27a5958eac59c3a06f844441533e1c38c69214209392f7cbca
|
|
BLAKE2b-256 checksum How to use checksums |
1f374331d305eae12f0761f39564a4ba60aeeeda04faa9e594f137914b94e5c6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 28, 2026.
Transparency logSecurity for kfp 2.18.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for kfp-2.18.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 28, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.