zenml - Moses Yebei

The Problem

ML and AI engineers face infrastructure fragmentation when operationalizing pipelines and agents. Teams must manage containerization, experiment tracking, metadata, and backend integrations independently, creating operational overhead that slows delivery from prototype to production.

What This Does

ZenML provides a framework for writing pipelines as workflows that execute on configurable infrastructure stacks. The codebase is organized around core concepts: the docs/book/ directory contains the book-style documentation and architecture diagrams (e.g., SystemArchitecture.png, core-concepts.png), while .github/workflows/ hosts 56 CI/CD workflow files that enforce testing, linting, and release gates. Docker configurations under docker/ include base.Dockerfile, zenml-dev.Dockerfile, and server-specific builds, indicating the project containers itself for reproducibility. The README references PyPI distribution (pypi.org/project/zenml/), and the presence of LICENSE, CONTRIBUTING.md, and CODE-OF-CONDUCT.md confirms standard open-source governance.

How To Use It

Setup: The package is published to PyPI and installable via pip install zenml. Docker images can be built from the docker/ directory files for development or server deployments. No pyproject.toml or setup.py files are visible in the file listing, but the PyPI shields in README.md confirm the package is publicly distributed.

Configuration: ZenML operates through "stacks" that abstract infrastructure backends. The README lists integrations with MLflow, Langgraph, Langfuse, Sagemaker, and GCP Vertex, but specific environment variable names or secret management files are not documented in the visible structure. The .github/workflows/ includes secrets-related setups (e.g., create-gh-secret.png in docs), suggesting GitHub Secrets or similar are expected for cloud integrations.

Running it: As a Python package, pipelines are authored using ZenML's pipeline decorator and executed through the ZenML orchestrator. The entry point is not a single main.py in the root; rather, users import and define pipelines in their own code, then invoke them via the ZenML CLI or API. Docker-based local runs would use the zenml-dev.Dockerfile for environment parity.

Real-World Use

A data science team writes a model training pipeline using ZenML's @pipeline decorator, specifying a stack with a MLflow artifact store and a DagsHub experiment tracker. The pipeline runs on a Kubernetes backend via the ZenML orchestrator, which containers the code, logs metrics to MLflow, and registers the model. The team iterates by modifying the pipeline code and re-running; ZenML tracks run metadata without requiring manual infrastructure changes. Connectors and deployers allow the same pipeline to be promoted to production on Sagemaker or GCP Vertex with stack configuration changes alone.

Code Health & Issues

Tests: Only 9 test files are present in the root structure, which is minimal for a codebase of this scale (200 files, extensive docs). The CI workflows (ci-fast.yml, unit-test.yml, etc.) suggest testing is enforced in CI, but the low file count raises questions about coverage depth. SDLC: CI/CD is well-supported with 56 GitHub Actions workflows covering linting, security scanning (trivy), codeql, and release gates. Dependabot is configured (dependabot.yml). Documentation: 117 doc files exist, including a full book-style docs structure, which is strong for an open-source project. License & Governance: LICENSE, CODE-OF-CONDUCT.md, and CONTRIBUTING.md are present, indicating compliance readiness. Dependency hygiene: No lockfile is visible in the file listing, though .trivyignore suggests container security scanning is in use.

The Bottom Line

ZenML is a well-structured, heavily documented platform suitable for teams needing to standardize ML pipeline operations across diverse infrastructure backends. The extensive CI/CD configuration and docs are notable strengths. However, the sparse test file count and absence of a visible lockfile or pyproject.toml are gaps that should be addressed before relying on it for mission-critical deployments. Teams already invested in ZenML's stack model or those requiring multi-cloud pipeline portability will find the most value here.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

3,360 files

Python2204
Markdown455
YAML116
Shell28
HTML15
JSON13

DjangoFlaskFastAPIDockerKubernetesPyTorchTensorFlowTransformersYOLOLangChainpandasSparkAirflowMLflow

Module dependencies

The 10 most depended-upon modules of 1,477, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_tests_unit_test_general["test_general"] n1_tests_harness_model___init__["__init__"] n2_tests_harness_model_base["base"] n3_sts_harness_model_deployment["deployment"] n4_ess_deployment_client_sqlite["client_sqlite"] n5_tests_harness_model_secret["secret"] n6_tests_harness_cli_cli["cli"] n7_ts_harness_model_environment["environment"] n8_egration_functional_conftest["conftest"] n9_gration_functional_cli_utils["utils"] n1_tests_harness_model___init__ --> n2_tests_harness_model_base n1_tests_harness_model___init__ --> n3_sts_harness_model_deployment n1_tests_harness_model___init__ --> n7_ts_harness_model_environment n1_tests_harness_model___init__ --> n5_tests_harness_model_secret n4_ess_deployment_client_sqlite --> n1_tests_harness_model___init__ n3_sts_harness_model_deployment --> n2_tests_harness_model_base n3_sts_harness_model_deployment --> n5_tests_harness_model_secret n5_tests_harness_model_secret --> n2_tests_harness_model_base n7_ts_harness_model_environment --> n2_tests_harness_model_base n7_ts_harness_model_environment --> n3_sts_harness_model_deployment classDef cyc stroke:#ef4444,stroke-width:2px; class n1_tests_harness_model___init__,n3_sts_harness_model_deployment,n4_ess_deployment_client_sqlite,n7_ts_harness_model_environment cyc;

Dependencies

7 of 15 declared dependencies are a major version behind. Resolved 15 of 15 against the registry.

Package	Declared	Latest	Behind
`pandas`	>=1.5.0	3.0.5	2 major
`openai`	>=1.0.0	3.1.0	2 major
`langfuse`	>=2,<3	4.14.4	2 major
`secure`	>=0.3.0	2.0.1	2 major
`langgraph`	>=0.5.0	1.2.11	1 major
`langchain-core`	>=0.3.0	1.5.5	1 major
`numpy`	>=1.21.0	2.5.2	1 major

Findings

LowDependencies declared without a lockfile - non-reproducible builds examples/agent_comparison/requirements.txt
LowSecret-shaped paths present; the code-health audit confirms or clears them docs/book/api-docs/oss-api-docs/v1/secrets.md, docs/book/how-to/secrets/secrets.md, helm/templates/custom-ca-secrets.yaml

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium2

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Pin the container base image by digestmedium

examples/e2e_nlp/gradio/Dockerfile

python:3.9

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Move large binaries to Git LFS or out of the repositorymedium7 occurrences

docs/book/.gitbook/assets/readme_simple_pipeline.gif

7 blobs over 5MB: readme_simple_pipeline.gif 13.7MB, readme_compute.gif 10.9MB, readme_mcp.gif 8.7MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.