Kedro-Viz: an interactive graph of a Kedro pipeline, in the browser

A development tool that reads a Kedro project, not a plotting library

Kedro-Viz is an interactive development tool for building data science pipelines with Kedro. Its job is to take the pipeline definition that already exists in a Kedro project and render it as something a person can look at.

The features list describes the product rather precisely. There is complete visualisation of a Kedro project and its pipelines, light and dark themes, scaling to big pipelines with hundreds of nodes, a filterable and searchable interface, a focus mode for modular pipeline visualisation, and a rich metadata side panel to display parameters, plots and so on. Every type of Plotly chart is supported, and the tool autoreloads on a code change.

The audience is a data science team working on a pipeline that has outgrown the point where reading the code is enough. Two hundred nodes in a catalogue is not something anyone holds in their head, and the focus mode and the search box exist for that reason. A second audience is anyone embedding the visualisation into a web application, which is why the second distribution exists at all.

The project lives at kedro-org/kedro-viz, is licensed Apache-2.0, and the last push was on 2026-10-19 with v12.5.0 released on 2026-09-29. A live demo is hosted at demo.kedro.org, which is the fastest way to see what a pipeline actually looks like before installing anything.

Two ways to install: the plugin or the React component

There are two supported installation routes, and the choice determines how the tool gets its data.

As a Kedro plugin, which the documentation calls the most common way, installation is a pip command:

pip install kedro-viz

The plugin registers itself with Kedro, so the visualisation is launched from the same command line as the rest of the project.

As a standalone React component, for embedding Kedro-Viz in your own web application, the package is the npm one:

npm install @quantumblack/kedro-viz

The npm package is scoped to quantumblack and its version tracks the Python package, currently 12.5.0. The repository ships a separate README.npm.md for the npm audience, and the package.json shows the shape of the published artefact: the main entry points at lib/components/app/index.js and an .mjs variant, with the styles and the data utilities exposed as additional export paths so a host application can pull in the stylesheet and the data helpers without importing the whole application.

Whichever route you take, the supported Python versions are 3.10, 3.11, 3.12 and 3.13 according to the badge in the project readme, and the compatibility table is the thing to read before anything else.

kedro viz run opens a browser at port 4141

The command line entry point is a single command, run from the root folder of your Kedro project:

kedro viz run

A browser tab opens automatically and serves the visualisation at http://127.0.0.1:4141/. The default port is 4141 and the default host is localhost, and the browser is only opened if the host is localhost.

The documented options cover the cases where the defaults do not fit. The host and port flags change where the server listens, --browser and --no-browser control the automatic tab, and --pipeline selects a named registered pipeline instead of the default one:

  --host TEXT               Host that viz will listen to. Defaults to
                            localhost.

  --port INTEGER            TCP port that viz will listen to. Defaults to
                            4141.

  --browser / --no-browser  Whether to open viz interface in the default
                            browser or not. Browser will only be opened if
                            host is localhost. Defaults to True.

  -p, --pipeline TEXT       Name of the registered pipeline to visualise. If not
                            set, the default pipeline is visualised

Two options are worth pausing on. The --autoreload flag restarts the viz server when a Python or YAML file changes in the Kedro project, which pairs with the autoreload feature in the product itself and turns the browser into a live view of the catalogue. The --lite flag is described as experimental and opens Kedro-Viz without the Kedro project dependencies, which is the option to try if the environment is not installable but you still want the interface.

There are also --save-file and --load-file, which take a directory path, so a visualisation state can be written to disk and read back later.

The compatibility table, not the version number, is the contract

Kedro-Viz tracks Kedro closely, and the readme makes that explicit by asking you to ensure your Kedro, Kedro-Viz and Kedro-datasets versions are supported by referencing a table. That table is the most practically important thing in the documentation.

Read across the rows and the constraint is clear. For Python 3.6, the last supported versions are Kedro 0.17.7 and Kedro-Viz 4.1.1, with no Kedro-datasets. For 3.7, Kedro 0.18.14, Kedro-Viz 6.7.0 and Kedro-datasets 1.8.0. For 3.8, Kedro is Latest, Kedro-Viz 7.1.0 and Kedro-datasets 1.8.0. For 3.9, Kedro and Kedro-Viz are both Latest with Kedro-datasets 5.0.0. From Python 3.10 onwards, all three are Latest.

The pattern to notice is that a Kedro-Viz version is pinned per Python minor version, and a Kedro-datasets version is pinned separately, and the pins only loosen on the newest interpreters. In other words, running an old Python locks you to an old visualisation tool, and the tool you get is not the current one.

That is a real upgrade cost. Moving a project to a newer Python is what unlocks a newer Kedro-Viz, so the visualisation layer and the interpreter are coupled, and a team that is stuck on an older Python for other reasons is also stuck with a 2021-era user interface. The table also shows Kedro-Viz moving to a 12.x line on current Python, which is a large version range to have accumulated for a tool that is a development aid rather than a runtime dependency.

Deploying the visualisation as a static site on S3, Azure or GCP

Kedro-Viz can be published rather than served locally, and the deploy command handles the cloud side:

kedro viz deploy

The documented options name the three supported cloud platforms and require an endpoint and a bucket name:

  --platform TEXT     Supported Cloud Platforms like ('aws', 'azure', 'gcp')
                      to host Kedro Viz  [required]

  --endpoint TEXT     Static Website hosted endpoint.(eg., For AWS - http://<b
                      ucket_name>.s3-website.<region_name>.amazonaws.com/)
                      [required]

  --bucket-name TEXT  Bucket name where Kedro Viz will be hosted  [required]

Two flags decide how much of the project travels with the diagram. --include-hooks adds all registered hooks in the Kedro project, and --include-previews adds a preview for all the datasets. Both are opt-in, which is a sensible default: a published diagram of an internal project does not automatically expose the code paths and the data that a local user can see.

There is also a command for producing a build directory of a local instance with static data, and the deployment path is what makes a pipeline shareable with people who do not have the project installed, such as a reviewer who only wants to understand the shape of the pipeline. The trade-off is that a deployed copy is a frozen copy, and the readme does not describe a mechanism for keeping a published deployment in step with the project.

Building from source: npm for the front end, Python for the package

The repository builds a JavaScript front end and a Python package that ships it, and the Makefile shows the whole pipeline.

The front end is built with vite, and the built assets are copied into the Python package directory:

build:
	rm -rf dist package/dist package/kedro_viz/html pip-wheel-metadata package/kedro_viz.egg-info
	npm run build
	cp -R dist package/kedro_viz/html

The package target then builds the Python distribution, and it refuses to continue if the built html is missing, which is a guard against shipping an empty package:

package:
	test -f package/kedro_viz/html/index.html || (echo "Built npm package not found; packaging process cancelled."; exit 1)
	cd package && rm -rf build/ dist/
	cd package && python -m build

The dev server is a Python entry point that serves the package directory:

run:
	PYTHONWARNINGS=$(PYTHONWARNINGS) PYTHONPATH="$(shell pwd)/package" python package/kedro_viz/server.py $(PROJECT_PATH)

The quality gates are strict in a way that reveals how the project is run. The Python test target requires full coverage:

pytest:
	cd package && PYTHONWARNINGS=$(PYTHONWARNINGS) pytest --cov-fail-under=100

End-to-end tests run through behave, and the linters are ruff for formatting and style plus mypy for types, with a separate mypy invocation for the test package that disables the abstract error code. There are also security gates, trufflehog for secret scanning and bandit for a security lint of the package, and a GitHub Actions workflow is referenced by the readme badges.

The repository also carries a demo-project directory, a cypress test setup and several vite configuration files, one for the app, one for the ESM build and one for the library build, which tells you the three distribution targets are built separately.

The boundaries: a Kedro-only tool with a version matrix and a browser dependency

There are three limits to weigh before adopting it, and none of them are hidden.

The first is scope. Kedro-Viz reads a Kedro project. If your pipeline is defined in some other orchestration tool, there is nothing for it to render, and the standalone React component does not change that, since it still needs Kedro-Viz data. The tool is also a development aid rather than something you ship, so the return on it is indirect: it shortens the time it takes a person to understand a pipeline, which only pays off if people are actually reading the pipeline.

The second is the browser dependency. The visualisation is a React application served over HTTP, and the default run binds to localhost on port 4141 and opens a browser tab. The --host flag exists, and the readme says the browser is only opened if the host is localhost, so pointing it at another machine is possible. But nothing in the documentation describes authentication for a non-local host, and the deploy command expects a static website endpoint on your own bucket, which implies the responsibility for access control is yours.

The third is the version matrix, discussed above, which couples the tool to your Python version and to matching Kedro and Kedro-datasets releases.

On the documentation side, the readme points to the Kedro documentation for visualisation and to a Slack organisation, and the repository includes ARCHITECTURE.md, LAYOUT_ENGINE.md and STYLE_GUIDE.md. The last of those is the practical check before extending the tool, because adding a panel or a chart means writing code in a style the project has already decided on.

Editorial conclusion

Kedro-Viz is a good fit for a data science team that has outgrown reading pipeline code, and a poor fit for a project that has no Kedro dependency, needs a pipeline diagram in a slide rather than in a browser, or cannot accept a tool whose version support is tied to a narrow Python and Kedro range. Before adopting it, check your Python version against the compatibility table, confirm the Kedro and Kedro-datasets versions in the same row are supported, and try kedro viz run with the --include-hooks flag to see whether the hook output you need is present.

Frequently asked questions

Official sources

1. kedro-org/kedro-viz on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases