How is a Bodywork Pipeline Configured?

Updated

A Bodywork pipeline is configured with a single bodywork.yaml file. That file defines the stages of your pipeline and how they connect into a DAG (directed acyclic graph), while the actual work inside each stage lives in ordinary Python modules or Jupyter notebooks committed to your project's Git repository. There are no new APIs to learn and no boilerplate code to write.

The Configuration Model

Bodywork separates what runs from how it is wired together:

Concern Where it lives
Stage logic (feature prep, training, serving, etc.) Python modules or notebooks in your Git repo
Pipeline structure and key settings bodywork.yaml
Runtime environment Bodywork's custom container image

Because the stage code is just normal Python, you can structure your codebase however you like. The bodywork.yaml file is the only place where pipeline-level configuration is expressed.

Pipeline = Jobs + Services

Every stage in a Bodywork pipeline does one of two things:

  • Run a batch job — prepare features, train models, compute batch predictions, and similar finite tasks.
  • Start a long-running process — for example, a Flask app that serves model predictions over HTTP.

These two building blocks are enough to compose pipelines for common ML use cases, from serving a pre-trained model to running continuous training on a schedule. The stages are assembled into a DAG that defines the workflow, and that DAG is declared in bodywork.yaml.

What You Do Not Have to Configure

Bodywork handles containers and orchestration for you. In practice this means:

  • You do not build or manage container images for any stage.
  • All stages run using Bodywork's custom container image.
  • Each stage pulls the required files directly from your project's Git repository (for example, GitHub), pip-installs its dependencies, and then runs the stage's designated Python module.

So the configuration surface stays small: your code, your Git repo, and one YAML file describing the pipeline.

Who This Configuration Style Suits

Bodywork is aimed at teams that want to run ML pipelines and deploy models to Kubernetes. It is positioned as a lightweight, simpler alternative to Kubeflow, or to building your own platform around a workflow orchestrator such as Apache Airflow, Argo Workflows, or Dagster.

If your team already writes Python and keeps code in Git, the configuration overhead is close to zero — you add a bodywork.yaml and let Bodywork handle containers and orchestration. If you need fine-grained control over container images or a large existing orchestration platform, that trade-off is worth weighing against the simplicity described above.