简体中文
English
Website review
This review may include AI-generated content and is not individually verified. Domain, certificate and other facts come from the observed data on this page.
What is Bodywork?
Bodywork is a command-line tool for deploying machine learning pipelines to Kubernetes. It handles containers and orchestration for you, so you don't have to build and manage a container image for each pipeline stage. It is aimed at teams that want to run ML pipelines and deploy models on Kubernetes, and it positions itself as a lighter, simpler alternative to running Kubeflow or assembling a platform around a workflow orchestrator such as Apache Airflow, Argo Workflows or Dagster.
How it models a pipeline
Every stage in a Bodywork pipeline does one of two things:
- A batch job — prepare features, train a model, compute batch predictions, and similar finite tasks.
- A long-running service — for example, a Flask app that serves predictions over HTTP.
Combining jobs and services covers common cases such as serving a pre-trained model or running continuous training on a schedule.
What you actually write
Stages are ordinary executable Python modules or Jupyter notebooks committed to your project's Git repository. There is no new API to learn and no required codebase structure. Stages are then assembled into a DAG that defines the workflow, with key settings held in a single bodywork.yaml file. At runtime, each stage pulls the needed files from Git, installs the required dependencies, and runs the designated Python module.
Where the trade-off sits
The main convenience is skipping container builds and much of the surrounding DevOps work. The cost is that your stages run inside Bodywork's custom container image and follow its Git-plus-config conventions, so you have less control over the exact runtime environment than you would with hand-built images. If your team already has strong container and orchestration practices, that control may matter more than the saved effort; if you mainly want ML pipelines running on Kubernetes without becoming a platform team, this is the gap Bodywork targets.
A reasonable first step is to take one existing batch job — feature preparation is usually the simplest — express it as a Python module or notebook, and define it in a bodywork.yaml to see how the workflow fits your project before migrating anything larger.
How do I install Bodywork on my Kubernetes cluster?
Bodywork is installed as a command-line tool on your local machine, then connected to a Kubernetes cluster where it deploys your pipelines. The installation itself is a Python package install; the cluster is prepared separately by pointing Bodywork at an existing kubeconfig context.
Typical setup path
- Install the CLI locally — install the
bodyworkPython package with pip into a virtual environment on the machine you will deploy from (your laptop or a CI runner). - Have a Kubernetes cluster and a working kubeconfig — Bodywork targets a cluster you already have, whether that is a managed service or a local cluster. Your
kubectlcontext must be able to reach it. - Configure Bodywork for that cluster — run the setup step that installs Bodywork's own components into the cluster's namespace, so it can create the jobs and services your pipeline needs.
- Deploy a project — point the CLI at a Git repository containing a
bodywork.yamland your stage code, and it builds the run from there.
The official documentation covers the exact commands under its Install and Setup Kubernetes sections at Bodywork.
What to check before you start
- Cluster access and permissions: you need credentials that can create namespaces, jobs and deployments. If your team uses role-based access control, confirm your account has the required rights before installing.
- A reachable Git remote: Bodywork stages pull project files from your Git repository at runtime, so the cluster must be able to clone it. Private repositories need credentials configured for the cluster, not just your laptop.
- Python version and environment isolation: install the CLI in a virtual environment so it does not conflict with other tooling on your machine.
A concrete first run
For a first test, use a small public repository with a single batch job stage, deploy it to a development namespace, and watch the resulting Kubernetes job. That confirms the CLI, cluster access and Git pull all work before you add services or scheduled training.
If your team already runs Kubeflow, Airflow, Argo Workflows or Dagster, the decision is less about installation effort and more about whether you want a lighter tool that handles containers and orchestration for you, versus extending a platform you already operate.
What is the difference between a Bodywork job and a service in a pipeline?
In Bodywork, every pipeline stage is one of two types: a job or a service. The distinction is about runtime behaviour, not about what the code is written in.
- A job runs a batch task to completion and then stops — for example preparing features, training a model, or computing batch predictions.
- A service starts a long-running process that keeps running, such as a Flask app serving model predictions over HTTP.
Because both types are just executable Python modules or notebooks pulled from your Git repository, you can mix them freely in one DAG: a job can train a model, and a service can then expose it. The choice comes down to whether the stage has a natural end or must stay alive to answer requests.
How to decide
| Question | Job | Service |
|---|---|---|
| Does the stage finish on its own? | Yes | No — it runs until stopped |
| Typical use | Feature prep, training, batch scoring | Model serving over HTTP |
| Resource pattern | Short-lived, repeatable | Persistent, always available |
A practical example: a nightly pipeline uses a job to retrain and a service to serve the current model. If you are unsure, ask whether anything needs to connect to the stage after it starts — if yes, it is a service; if it just produces an output and exits, it is a job.
For the full set of stage configuration options, see the Bodywork documentation at Bodywork.
How do I configure a Bodywork pipeline with bodywork.yaml?
A Bodywork pipeline is defined in a single bodywork.yaml file at the root of your project's Git repository. In that file you declare the pipeline's workflow stages and their dependencies, and Bodywork turns that declaration into a DAG that runs on Kubernetes. Because Bodywork pulls your project files from Git and installs dependencies at stage start, the YAML is the main place where you describe what each stage does and how it should run, rather than writing container or orchestration code.
What typically goes in the file
- Project/workflow metadata: the pipeline name, the Git repository details Bodywork should use, and the Python version or dependencies relevant to your stages.
- Stages: each stage names its executable entry point — a Python module or Jupyter notebook committed to your repo — and the type of work it performs.
- Stage type: a stage either runs a batch job (feature preparation, training, batch prediction) or starts a long-running service (for example, a Flask app serving predictions over HTTP).
- Dependencies: the relationships between stages that define the DAG's order, so Bodywork knows which stages must finish before others begin.
- Runtime settings: per-stage configuration such as resource requirements, environment variables, secrets, and any schedule for continuous training.
A practical example
A common shape is three stages: a batch job that prepares features, a batch job that trains a model and depends on the feature stage, and a service stage that serves the trained model and depends on training. The batch stages run and exit; the service stage stays up. That single file then expresses the whole pipeline, and Bodywork handles the containers and orchestration.
How to get the exact keys
The precise field names, nesting, and allowed values are version-specific, so use the official documentation for the schema and a working example:
- Bodywork documentation — the user guide and key concepts cover
bodywork.yamlstructure and stage definitions. - Kubernetes — useful background for the cluster Bodywork deploys to, including namespaces, resources, and secrets.
A sensible next step is to copy the quickstart's bodywork.yaml and adapt it stage by stage, validating with the CLI before deploying. If a stage fails, check the entry-point path, the dependency ordering, and whether the required dependencies are declared — those are the most common configuration mistakes.
Can Bodywork replace Kubeflow or Airflow for my ML workflows?
Bodywork can replace them for a specific kind of team: one that wants ML batch jobs and model-serving processes running on Kubernetes without building a platform around a general-purpose orchestrator. It is not a drop-in substitute for Kubeflow or Airflow in every situation, because the scope is deliberately narrower.
What Bodywork actually gives you
According to its own overview, Bodywork is a command line tool that deploys ML pipelines to Kubernetes and handles containers and orchestration for you. Each pipeline stage is either a batch job (feature preparation, training, batch prediction) or a long-running process (for example, an HTTP model-serving app). Stages are assembled into DAGs described in a single bodywork.yaml. You write ordinary Python modules or notebooks, commit them to Git, and Bodywork's container image pulls the files, installs dependencies, and runs the stage — so you don't build or manage per-stage container images.
How it compares
| Consideration | Bodywork | Kubeflow | Airflow |
|---|---|---|---|
| Primary focus | ML pipelines and model deployment on Kubernetes | End-to-end ML platform on Kubernetes | General workflow orchestration |
| Where code runs | Kubernetes | Kubernetes | Anywhere, including VMs and Kubernetes |
| Learning curve | Low: Python plus one YAML file | High: many components and concepts | Moderate to high: DAGs, operators, scheduling |
| Container management | Handled by Bodywork | You own much of it | You own it |
| Best fit | Small teams wanting simple ML DevOps | Larger platform teams | Data engineering and diverse workflows |
When to choose which
Pick Bodywork if your workflows are recognisably ML-shaped (train, retrain, serve), your team already runs Kubernetes, and you would rather not operate a platform. Pick Kubeflow if you need a broad, multi-tenant ML platform with notebooks, experiment tracking and pipelines as first-class services. Pick Airflow if your pipelines reach well beyond ML into data engineering, or if you need to orchestrate systems outside Kubernetes.
A concrete test: if you can express your workflow as a handful of Python stages plus a serving process, and nobody on the team wants to maintain orchestration infrastructure, Bodywork is a reasonable fit. If you need complex scheduling, many non-ML tasks, or a shared platform for multiple teams, a general orchestrator will serve you better.
For related tooling, see Apache Airflow, Kubeflow and Argo Workflows.
How does Bodywork handle container images and dependencies for ML stages?
Bodywork avoids per-stage container builds. Instead of packaging each ML stage into its own image, it runs every stage inside one custom Bodywork container image. At the start of a stage, that container pulls the required files from your project's Git repository, installs the stage's Python dependencies with pip, and then runs the designated Python module or notebook.
That model has two practical consequences:
- You manage code and dependencies, not Dockerfiles. A stage is defined by committing an executable Python module or Jupyter notebook to your Git repository. There are no new APIs to learn and no image build step to maintain for each stage.
- Dependencies are resolved at stage runtime. Because pip-installing happens when the stage starts, dependency declarations need to be available in the repository and consistent with the environment the Bodywork image provides. This is convenient, but it also means stage startup includes installation time, and reproducibility depends on pinning versions carefully.
Jobs and services
Any pipeline stage does one of two things: run a batch job (feature preparation, training, batch prediction) or start a long-running process (such as a Flask app serving predictions over HTTP). Both run in the same Bodywork container image, so serving and batch work follow the same dependency mechanism. Stages are assembled into DAGs and configured in a single bodywork.yaml file, which is where workflow and stage settings live.
How to decide if this fits
If your team already uses Kubernetes and wants to run ML pipelines without building and maintaining an image per stage, Bodywork's approach removes a meaningful amount of DevOps work. If you need strict, pre-baked image reproducibility, per-stage isolation, or dependencies that cannot be installed at runtime, a platform built around custom images may suit you better.
A useful next step is to take one existing training script, commit it with a pinned requirements.txt, and define it as a single batch stage in bodywork.yaml. That small test shows you how installation time and dependency resolution behave in your environment before you commit to a full pipeline.
For teams comparing orchestration options, Bodywork positions itself as a lighter alternative to Kubeflow or to assembling a platform around a general workflow tool such as Apache Airflow, Argo Workflows or Dagster. The trade-off is that those tools give you more control over execution and packaging, while Bodywork gives you less to build and operate.
Cloudflare
Google Workspace
User reviews (0)