Kedro architecture overview

Note: This documentation is based on Kedro 0.17.0, if you spot anything that is incorrect then please create an issue or pull request.

Here is a diagram showing high-level architecture of Kedro library:

Kedro architecture diagram

Note: The arrow A -> B on the diagram above should be read as: “A is aware of existence of B or directly uses B, while B does not necessarily know about A”.
Note: Internally we use import-linter to enforce this structure and generally want the lower layer to be unaware of the above layers.

Building blocks

The architecture diagram above is formed of the following building blocks:


This section contains the building blocks that help accessing core components of the Kedro project (e.g., the data catalog or the pipeline).

A Python file that contains project specific CLI commands (e.g., kedro run, kedro test, etc.). This file must be located at the root of the project.

A Python file located in src/<python_package>/ This file serves as the main entry point of the project and is used to run the project in package mode.


pyproject.yml identifies the project root, which is used by other Kedro components and contains the following metadata entries:

  • package_name: A valid Python package name for your project package
  • project_name: A human readable name for your project
  • project_version: Kedro version with which the project was generated
  • source_dir: (Optional) The directory of the source path relative to the project root path. Default directory is src/ and when customised the path should be separated by a forward slash (e.g src/<path_to_src>/)

pyproject.toml must be located at the root of the project. We use the pyproject.toml for all configuration needed to create the Python package and allow the Kedro CLI to find where the source code is.

We use the for all project settings, which will not change at run time, but at development time. contains the following configuration entries:

  • DISABLE_HOOKS_FOR_PLUGINS: (Optional, tuple) A list of the installed plugins for which to disable auto-registry
  • HOOKS: (Optional, tuple) A list of instances of Hooks implementations to be registered with the project (default is an instance of <python_project>.hooks.ProjectHooks)
  • SESSION_STORE_CLASS: (Optional, class) Define a store class to be used to save data from a KedroSession
  • SESSION_STORE_ARGS: (Optional, dict) Define keyword arguments to be passed to SESSION_STORE_CLASS constructor
  • CONTEXT_CLASS: (Optional, class) Define a project context class to be used at runtime. Defaults to KedroContext class

This script is automatically invoked at IPython kernel startup when calling kedro jupyter notebook, kedro jupyter lab and kedro ipython CLI commands. creates an instance of KedroContext object, which can be used to interact with the current project right away.


This section contains the building blocks that help running native Kedro and plugin CLI commands.

kedro cli

Any Kedro CLI command (e.g., kedro new, kedro run) executed by a user.


A Python file that contains Kedro global CLI commands, i.e. the ones that do not require a Kedro project in the current working directory to work (e.g., kedro new, kedro info).


Any CLI command that is implemented by a Kedro plugin (e.g., Kedro-Docker, Kedro-Airflow, Kedro-Viz).


A python function that instantiates the project context by calling load_context(). get_project_context() also preserves backwards compatible interface to ensure old versions of the plugins continue working even if breaking changes are introduced in load_context().

Note: This function is intended for plugin use only. It is now deprecated and will be removed in version 0.18.0. To instantiate the project context outside of a plugin, you should call KedroSession.load_context().


Note: This function is now deprecated in favour of KedroSession.load_context() and will be removed in Kedro 0.18.0.

A Python function that locates Kedro project based on pyproject.toml and instantiates the project context.


KedroSession is the object that is responsible for managing the lifecycle of a Kedro run.


The base class for project context implementations. It holds the configuration and Kedro’s main functionality, and also serves the purpose of the main entry point for interactions with the core project components.


This section lists core Kedro components. These library components can be used both in conjunction and separately.


Helper class that enables loading the project configuration in a consistent way.


A collection of Node objects with the preserved execution order.


A base class for all Pipeline runner implementations.


A dataset store providing load and save capabilities for the underlying datasets.


A base class for all dataset implementations.