Kedro as a Service | Kedro Blogkedro
Feature highlight — 10 min read<br>Kedro as a Service<br>We're developing a new Kedro Server API and Service Session to enable Kedro pipelines to run as reusable and callable services. We’re showing you all what we’ve done so far, and we'll continue to iterate depending on feedback.
29 Jun 2026 (last updated 30 Jun 2026)
Kedro as a Service<br>Over the years, one of the most requested capabilities from the Kedro community has been the ability to execute pipelines repeatedly inside long-running services and expose them programmatically to external systems.<br>This capability has become even more important as AI systems for agentic systems.<br>We’re in the process of developing a Kedro Server API and underlying KedroServiceSession so that structured Kedro pipelines can operate as callable, API-accessible services within larger systems. We’re showing you all what we’ve done so far, and we'll continue to iterate depending on feedback.<br>The Kedro project was open sourced 7 years ago when execution patterns were primarily designed around batch-oriented workloads, where workflows were triggered independently and execution context was recreated for each run. The model works well for many data processing scenarios, but users have reported that it’s limiting for interactive applications, repeated execution loops, API-driven workflows, dashboards, real-time inference, and particularly for long-running gen AI services. A critical architectural requirement for agentic workflows is an execution framework that is directly callable from external systems.<br>What we’ve done so far<br>1. Kedro Server API<br>We’ve recently added a Kedro Server API that offers a way to trigger pipelines by invoking them over HTTP. They can be called programmatically from other applications, and integrated directly into larger systems as callable services. Kedro pipelines are now available as reusable building blocks accessible to any system that can make an HTTP request.<br>It doesn’t change Kedro's role as a pipeline authoring framework but extends the ways structured Kedro pipelines can participate inside modern AI systems.<br>The Kedro HTTP Server is a FastAPI-based server that wraps a Kedro project and exposes its pipelines and project metadata as REST endpoints. It can be started with a single CLI command from within a Kedro project: kedro server start<br>Once running, the server exposes three core endpoints:<br>GET /health — Returns server status and the running Kedro version. This is the standard liveness check for monitoring and orchestration platforms.
POST /run — Triggers pipeline execution. This is the primary endpoint for service-oriented workflows. The request body maps directly to the same execution parameters available via kedro run: which pipelines to execute, which nodes to include or exclude, tags, runner type, load versions, and runtime parameters.
For example:<br>1{<br>2"pipeline_names": ["scoring"],<br>3"runtime_params": { "threshold": 0.85 },<br>4"runner": "SequentialRunner",<br>5"tags": ["production"]<br>6}<br>7GET /snapshot — Returns a read-only inspection snapshot of the Kedro project: project metadata, registered pipelines, declared datasets, and parameter keys. This provides a consistent, queryable view of project structure that can be consumed by external tooling, dashboards, and interfaces such as Kedro-Viz.
2. KedroServiceSession<br>Traditionally, KedroSession was designed as a short-lived execution context: a pipeline run would create a session, load configuration and catalog objects, execute the workflow, and then terminate.<br>KedroServiceSession extends this model by enabling persistent, repeatable execution within the same running process. Unlike the standard KedroSession, which is designed for a single run, KedroServiceSession can accept multiple run() calls on the same session instance. Project-level state such as the hook manager is initialized once and carried across runs, while each individual execution still loads its own configuration and data catalog so that runs can be kept isolated and reproducible.<br>Each run can also receive its own runtime parameters, enabling callers to inject dynamic inputs, such as model thresholds, or request-specific values, without changing pipeline code or project configuration.<br>It means the execution model for Kedro pipelines is more service-oriented, as it supports patterns such as model serving APIs, interactive applications, agentic workflows, and other systems that need repeated execution with dynamic inputs.<br>KedroServiceSession is currently under active development, and future iterations are exploring pre-loading of execution resources such as the catalog and configuration to further reduce per-run overhead to make it better suited to latency-sensitive workloads as the feature matures.
Example Use Cases<br>The following examples represent a subset of the types of workflows enabled by the KedroServiceSession and Server API, intended to give users a few concrete examples of how these...