Related Pages

Related topics: Stacks, Orchestrators, and Integration Ecosystem, Containerization, Image Building, and Server Deployment, Server, REST API, Data Models, and Persistence

Pipeline Authoring: Steps, Pipelines, Snapshots, and Dynamic Execution

Overview

ZenML's pipeline authoring layer is the user-facing surface for describing ML and AI workflows in Python. It provides a small, opinionated vocabulary: @step defines the smallest executable unit, @pipeline composes steps into a DAG, snapshots freeze a pipeline's code, configuration, and container image for reproducibility, and dynamic execution allows the DAG to be expanded at runtime. Together these primitives let users iterate locally and then promote the same code to remote orchestrators, step operators, and deployment endpoints without rewriting application logic.

Steps: The Executable Unit

A step is any function decorated with @step. The decorator in src/zenml/steps/step_decorator.py wraps the function with a BaseStep instance defined in src/zenml/steps/base_step.py, which captures the function signature, type hints, parameters, and materializers required to serialize inputs and outputs. Steps may declare typed inputs and outputs (Pydantic models, DataFrames, files, custom artifacts) and ZenML infers the corresponding materializer automatically.

Beyond the standard Python-function step, ZenML exposes command_step in src/zenml/steps/command_step.py for wrapping arbitrary external programs (shell commands, scripts, or binaries) as steps — useful for invoking legacy tooling that cannot be imported as Python.

Step-level configuration (resources, retries, caching, custom materializers) is set via the Settings and ResourceSettings objects passed to the decorator or configured globally per stack component.

Pipelines: Composing Steps into a DAG

A pipeline is a function decorated with @pipeline whose body invokes one or more step functions. The decorator lives in src/zenml/pipelines/pipeline_decorator.py and returns a PipelineDefinition instance implemented in src/zenml/pipelines/pipeline_definition.py. The definition walks the call graph, infers step-to-step data dependencies from positional and keyword arguments, and emits a DAG. Outputs from one step that are passed as inputs to another become implicit edges; this is the same mechanism used by the quickstart example and the MLOps starter.

Pipelines accept DockerSettings, ResourceSettings, and stack-component-specific settings; when code is added, the build machinery in src/zenml/pipelines/build_utils.py materializes a container image, packages the source tree, and resolves secrets. The active stack's orchestrator then schedules the DAG.

Snapshots: Freezing a Pipeline for Reproducibility

A snapshot is an immutable, server-side record of a pipeline's code, configuration, and container image. The quickstart example demonstrates the typical workflow:

zenml pipeline snapshot create pipelines.simple_pipeline.simple_pipeline --name my_snapshot

Snapshots decouple *what to run* from *how to run it*: a CI/CD job, a teammate, or a dashboard button can trigger a snapshot by name without needing access to the original source tree. They capture:

• The pipeline function reference and a content hash of the code
• Resolved settings and configuration values
• The container image digest produced by the build step
• Parameter values supplied at snapshot time

This is the same mechanism used to deploy pipelines as long-running HTTP services (see the deploying_ml_model and deploying_agent examples), where zenml pipeline deploy materializes a snapshot bound to an HTTP runtime.

Dynamic Execution: Runtime DAG Expansion

Static pipelines require every step to be known at compile time. ZenML also supports dynamic pipelines, where a step can invoke other steps during execution and the orchestrator materializes them into a single DAG. The runner is implemented in src/zenml/execution/pipeline/dynamic/runner.py and is showcased in the RLM document analysis example, where a planner step produces N chunk-processing steps whose count is decided by the LLM at runtime.

flowchart TD
    A[load_documents] --> B[plan_decomposition]
    B --> C1[process_chunk]
    B --> C2[process_chunk_2]
    B --> C3[process_chunk_3]
    B --> CN[process_chunk_N]
    C1 --> D[aggregate_results]
    C2 --> D
    C3 --> D
    CN --> D
    D --> E[report]

Release 0.95.1 improved dynamic-pipeline reliability with step operators: a step that calls step()(...) inside a dynamic pipeline no longer needs to be listed explicitly in pipeline.depends_on, and ZenML falls back gracefully when the orchestrator cannot run the child step inline.

Common Failure Modes

A few recurring issues observed in community discussions are worth knowing about when authoring pipelines:

• Git submodules dropped from code archive (#4408): when a pipeline downloads code from the artifact store (allow_download_from_artifact_store: true), submodules are not included in the archive, which silently breaks step execution. Workaround: clone with --recurse-submodules locally before running.
• Build-time secrets in Dockerfiles (#4599): DockerSettings.build_options.build_args does not currently emit matching ARG instructions in the generated Dockerfile, so secret values are not accessible at image build time.
• Dynamic pipelines with step operators: prior to 0.95.1, running a dynamic child step on a step operator required it to be declared in pipeline.depends_on; this constraint has been relaxed.

See Also

• Pipeline Deployment — turning snapshots into HTTP services
• Agent Deployment — LLM-powered pipelines with embedded UI
• Helm Chart — deploying the ZenML server that stores snapshots and pipeline metadata
• ZenML Documentation: Pipelines & Steps

Related Pages

Related topics: Pipeline Authoring: Steps, Pipelines, Snapshots, and Dynamic Execution, Containerization, Image Building, and Server Deployment

Stacks, Orchestrators, and Integration Ecosystem

Overview and Purpose

ZenML is an open-source MLOps framework that abstracts infrastructure so that ML/AI engineers can write pipelines (workflows) that run on any stack (infrastructure backend). The framework's core promise is that the same pipeline code executes unchanged across local laptops, Kubernetes clusters, or cloud-managed orchestrators (Source: README.md).

A *stack* is the named collection of pluggable components that ZenML uses to materialize a pipeline: an orchestrator decides where steps run, an artifact store decides where outputs are persisted, a container registry decides where images are pushed, an experiment tracker records metrics, and so on. Stacks therefore decouple pipeline logic from infrastructure concerns and let teams swap backends without editing pipeline code (Source: examples/mlops_starter/README.md).

The integration ecosystem wraps third-party tools — MLflow, LangGraph, Langfuse, Sagemaker, GCP Vertex, Kubernetes, SkyPilot, Hugging Face Hub, Neptune, and many others — as first-class ZenML stack component *flavors*. This ecosystem is what allows ZenML to interoperate with existing tooling rather than replacing it (Source: README.md).

Stacks and Stack Components

Anatomy of a Stack

A stack is registered in the ZenML server and selected (either explicitly or by default) whenever a pipeline runs. Examples demonstrate this concretely: the MLOps starter registers a default local stack and uses it for the feature engineering, training, inference, and deploy pipelines (Source: examples/mlops_starter/README.md). The NLP template provides a make install-local-stack target that provisions the same local stack with all required integrations (Source: examples/e2e_nlp/README.md).

Each component type — orchestrator, artifact store, container registry, experiment tracker, model deployer, step operator, secret manager, feature store, annotator, data validator, image builder — is implemented by a *flavor*. A flavor is a Python class that registers the component with ZenML's flavor registry and exposes the configuration schema used by zenml stack register (Source: src/zenml/integrations/README.md). The flavor registry is what makes integrations discoverable and lets users register custom flavors with zenml <STACK_COMPONENT> flavor register <module.MyFlavor> (Source: src/zenml/integrations/README.md).

Stack Lifecycle

Stacks follow a register → activate → use → share lifecycle. Once registered, a stack can be set as the active default (zenml stack set) and is then used automatically by every pipeline run on that client. Teams that move from local development to production typically register a cloud stack (for example, a Kubeflow orchestrator with an S3 artifact store) and switch with a single command, without changing pipeline source code (Source: README.md).

The helm chart exposes these stack-related server settings through Kubernetes values, and the chart itself is the recommended path for self-hosting a remote ZenML server against which teams register and share stacks (Source: helm/README.md).

Orchestrators

The orchestrator is the central stack component: it schedules step execution, manages dependencies, and (for dynamic pipelines) handles runtime fan-out. Every ZenML deployment ships with at least one orchestrator flavor active (Source: src/zenml/integrations/README.md).

ZenML provides local orchestrators that execute steps in-process for development, and a wide range of remote orchestrators — Kubernetes-native options such as Kubeflow and Argo Workflows, managed cloud options such as AWS Sagemaker, AzureML, GCP Vertex AI, and lightweight options such as the local Docker orchestrator. The 0.95.1 release notes specifically improved the behavior of *dynamic pipelines* when steps are routed to a remote step operator, fixing failures that previously occurred unless the step was explicitly listed in pipeline.depends_on (Source: community release notes — issue #0.95.1 fix summary).

For real-time serving, ZenML distinguishes between batch execution (orchestrator-driven) and deployment: zenml pipeline deploy pipelines.inference_pipeline.churn_inference_pipeline produces a long-running FastAPI HTTP service that loads the model once at startup for sub-100ms latency (Source: examples/deploying_ml_model/README.md). The agent deployment example similarly shows deployment settings, including CORS configuration and an embedded UI, being injected into the deployed pipeline (Source: examples/deploying_agent/README.md).

flowchart LR
    A[Pipeline Code] --> B[Active Stack]
    B --> C[Orchestrator]
    B --> D[Artifact Store]
    B --> E[Container Registry]
    B --> F[Experiment Tracker]
    C -->|schedules steps| G[Step Runners]
    G -->|persist outputs| D
    G -->|push images| E
    G -->|log metrics| F
    G --> H[(Pipeline Run Metadata)]

Integration Ecosystem

Built-in and Community Integrations

The integration directory under src/zenml/integrations/ is the canonical location for every flavor shipped with ZenML. Each integration packages one or more flavors (for example, the MLflow integration provides an experiment tracker and a model deployer) and installs the third-party Python client that the flavor delegates to (Source: src/zenml/integrations/README.md).

The ecosystem is broad. The README highlights integrations with MLflow, LangGraph, Langfuse, Sagemaker, and GCP Vertex (Source: README.md). The dedicated agent-framework example folder shows production-ready orchestration over LangGraph, LiteLLM, and Langfuse with full lineage tracking (Source: examples/agent_framework_integrations/README.md). The agent comparison example extends this with an AgentMaterializer that emits Mermaid diagrams and HTML reports into the ZenML dashboard (Source: examples/agent_comparison/README.md).

Building a Custom Integration

The integration README documents the canonical three-step flow for adding a new component:

1. Develop the flavor as a standalone Python class — implement the abstract StackComponent subclass and its Flavor counterpart, register them via zenml <component> flavor register <module.MyFlavor>, and validate against the active stack (Source: src/zenml/integrations/README.md).
2. Package the integration — create a directory under src/zenml/integrations/<name>/ containing the flavor modules, an __init__.py that re-exports them, and a check_installation() helper used by ZenML to surface clear errors when the third-party dependency is missing.
3. Integrate into the ZenML repo — clone the repository, follow the contributing guide, add the integration directory, register it in the central integration list, and add tests under tests/integration/examples/ (Source: src/zenml/integrations/README.md).

Community-Driven Caveats

The integration ecosystem depends on third-party SaaS providers, so the health of an integration is bound to the provider's roadmap. Issue #4498 reports that Neptune is sunsetting its SaaS services as of March 5th, which will break any stack that registers the Neptune experiment tracker flavor (Source: community context — issue #4498). Other reported integration pain points include MLflow authentication mismatches against AzureML custom tracking servers (issue #4407) and missing git-submodule support when downloading code from the artifact store (issue #4408). These highlight that integration health should be verified before committing production stacks to a particular flavor (Source: community context — issues #4407, #4408).

See Also

• Quickstart Example — minimal pipeline → deploy loop using the default local stack
• Helm Chart — deploying a shared ZenML server for team-wide stack registration
• Integrations Developer Guide — three-step flow for shipping a new flavor
• Agent Comparison Example — multi-framework integration showcase
• Deploying ML Models Example — from training pipeline to deployed HTTP service
• Deploying Agents Example — agentic pipeline deployment with embedded UI

Related Pages

Related topics: Stacks, Orchestrators, and Integration Ecosystem, Server, REST API, Data Models, and Persistence

Containerization, Image Building, and Server Deployment

Overview

ZenML uses Docker throughout its execution path: it auto-generates Dockerfiles for pipelines, builds images via pluggable image builders, and provides a server backend for multi-user collaboration. The system is wired together by the DockerSettings configuration model, the abstract BaseImageBuilder interface, the PipelineDockerImageBuilder orchestrator, and the Kubernetes-friendly Helm chart for server deployment.

This page documents the moving parts of that pipeline, the configuration knobs exposed to users, and the failure modes that the community has reported.

Configuration: `DockerSettings`

The single source of truth for pipeline containerization is DockerSettings in src/zenml/config/docker_settings.py. It is a Pydantic model that travels with the pipeline definition and is consumed by the image builder at build time. Common fields include parent_image, dockerfile, target_repository, requirements, and the nested BuildOptions object that carries build_args and build_context overrides.

from zenml.config import DockerSettings

docker_settings = DockerSettings(
    parent_image="python:3.11-slim",
    requirements=["scikit-learn==1.5.0"],
    build_options={"build_args": {"ZENML_CUSTOM_TOKEN": "abc"}},
)

Source: src/zenml/config/docker_settings.py:1-80

Community issue #4599 requests that DockerSettings.build_options.build_args automatically inject matching ARG instructions into the auto-generated Dockerfile. Today, the key-value map is forwarded to docker build --build-arg, but the corresponding ARG <key> declaration must already be present in the user-supplied Dockerfile (or in a hand-rolled one set via the dockerfile field); otherwise the build fails because the build secret is undefined.

Image Builders and Build Context

ZenML abstracts the actual docker build call behind BaseImageBuilder in src/zenml/image_builders/base_image_builder.py. Two concrete implementations are shipped with the framework:

• LocalImageBuilder — src/zenml/image_builders/local_image_builder.py. Calls the host's Docker daemon. The default for local development and CI runners.
• KanikoImageBuilder — src/zenml/integrations/kaniko/image_builders/kaniko_image_builder.py. Builds images inside a Kubernetes cluster using Kaniko, which does not require a privileged Docker socket. This is the recommended option for production Kubernetes deployments.

BuildContext (src/zenml/image_builders/build_context.py) materializes the directory handed to the builder: it stages the pipeline code snapshot, an auto-generated requirements.txt, the user Dockerfile if any, and any extra files registered through build_options.build_context.

PipelineDockerImageBuilder (src/zenml/utils/pipeline_docker_image_builder.py) is the high-level coordinator. It:

1. Resolves the final DockerSettings (merging stack defaults with pipeline overrides).
2. Generates a Dockerfile if the user did not supply one.
3. Prepares the BuildContext.
4. Calls the active BaseImageBuilder.
5. Tags and pushes the resulting image to the target registry.
6. Returns the image digest, which the orchestrator bakes into the run metadata.

Source: src/zenml/utils/pipeline_docker_image_builder.py:1-120

flowchart TD
    DS[DockerSettings] --> PDB[PipelineDockerImageBuilder]
    PDB --> BC[BuildContext]
    PDB --> DK{Dockerfile needed?}
    DK -->|Yes| GEN[Generate Dockerfile]
    DK -->|No| USR[User Dockerfile]
    GEN --> CTX[Compose Context]
    USR --> CTX
    BC --> CTX
    CTX --> IB{Image Builder}
    IB -->|Local| LD[Local Docker Daemon]
    IB -->|Kaniko| KN[Kaniko in K8s]
    LD --> PUSH[Push to Registry]
    KN --> PUSH
    PUSH --> ORCH[Orchestrator runs step image]

Community issue #4408 shows a gap in this build context: when code is fetched from the artifact store (allow_download_from_artifact_store: true), git submodules are not archived alongside the rest of the working tree. The fix requires teaching BuildContext to walk .gitmodules and bundle submodule contents into the code archive before it is uploaded.

Auto-Generated Dockerfile

When DockerSettings.dockerfile is empty, PipelineDockerImageBuilder renders a default Dockerfile that:

• Sets FROM to the resolved parent_image.
• Copies the staged context into /app.
• Runs pip install for the user requirements and the matching ZenML client version.
• Sets an ENTRYPOINT that invokes the orchestrator-specific step entry point.

The 0.95.1 release adds a fix relevant to this flow: when a step is executed through a step operator inside a dynamic pipeline, the orchestrator now falls back to scanning the pipeline DAG to discover the dependency, so the step is scheduled correctly even when it is not explicitly listed in pipeline.depends_on.

Server Deployment

For team and production use, ZenML provides a centralized server. The reference deployment is the Helm chart in helm/:

helm install my-zenml oci://public.ecr.aws/zenml/zenml --version 0.95.1

Source: helm/README.md:1-60

The chart provisions the ZenML server deployment and service, a relational database, optional ingress, and integrations with AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault. Custom CA certificates can be supplied under server.certificates.customCAs for environments that use private certificate authorities. Source: helm/values.yaml.

Community issue #4251 reports a common deployment-side pitfall: zenml login to a self-hosted remote server fails with SQL-related errors when the client is installed with pip install zenml (no extras). The server-side database drivers ship only with the [server] extra, so the client must install with pip install "zenml[server]" before connecting.

See Also

• src/zenml/stack/image_builder.py — Stack component registration for image builders.
• src/zenml/orchestrators/ — Orchestrators that consume the built images.
• Pipeline Deployments — Concept guide for deploying pipelines as HTTP services.
• Helm Deployment Guide — Production server deployment reference.

Related Pages

Related topics: Pipeline Authoring: Steps, Pipelines, Snapshots, and Dynamic Execution, Stacks, Orchestrators, and Integration Ecosystem, Containerization, Image Building, and Server Deployment

Server, REST API, Data Models, and Persistence

Overview

ZenML is an MLOps framework that allows users to write Pythonic workflows (pipelines) executed on heterogeneous infrastructure (stacks). The server, REST API, data models, and persistence layer form the backbone that makes this possible in multi-user, production, and team-collaboration scenarios.

The server is the central coordination point that exposes a REST API to clients (the ZenML Python client, the CLI, the ZenML Dashboard, and integrations), enforces authentication and authorization, gates premium features, and persists state via pluggable stores. Source: README.md.

The server can run:

• Embedded in-process with the local CLI/Dashboard (zenml login --local)
• Remotely as a self-hosted service deployed with Docker, Helm, or ZenML Pro
• In a Kubernetes cluster using the official Helm chart

Source: helm/README.md.

Server Architecture and REST API

Request Lifecycle

The REST API is implemented as a FastAPI application whose entry point is src/zenml/zen_server/zen_server_api.py. Each incoming request flows through a series of middleware/components before reaching the endpoint handler:

flowchart LR
    A[Client SDK / CLI / Dashboard] --> B[FastAPI Router]
    B --> C[Auth Middleware]
    C --> D[RBAC Permission Check]
    D --> E[Feature Gate Check]
    E --> F[Streaming Endpoint Handler]
    F --> G[Zen Store CRUD]
    G --> H[(SQL DB / External Store)]
    H --> G
    G --> F
    F --> A

The key components are:

Source: the listed files above.

Authentication Schemes

Authentication is pluggable. The Helm chart exposes auth.type with values such as oauth2, http_basic, no_auth, and a device-flow scheme. Source: helm/README.md. The auth.py module defines credential verification, token issuance, and the dependency-injected helpers (auth_context) used by endpoints to attach the authenticated user. Source: src/zenml/zen_server/auth.py.

Authorization (RBAC)

RBAC is enforced through the interface in src/zenml/zen_server/rbac/__init__.py. Each protected endpoint declares the action and resource type it operates on (e.g., CREATE, pipeline, READ, artifact), and the RBAC layer resolves whether the calling user has the appropriate permission via their assigned roles. If RBAC is disabled in the deployment, the layer short-circuits to allow access.

Feature Gating

Some capabilities (e.g., model control plane dashboards, advanced RBAC, certain integrations) are only available with a valid ZenML Pro license. The interface in src/zenml/zen_server/feature_gate/feature_gate_interface.py defines the contract: given a tenant ID and a feature key, return whether the feature is enabled. Endpoints call this gate before performing gated operations.

Streaming Endpoints

Pipeline deploys, long-running inference requests, and bulk operations are exposed as streaming endpoints using server-sent events. The streaming module in src/zenml/zen_server/streaming/__init__.py handles event framing, backpressure, and connection lifecycle.

Data Models and Persistence

Zen Stores

The data layer is abstracted by the ZenStore interface. There are two production implementations:

1. SQL ZenStore — the default, backed by SQLAlchemy-compatible databases (SQLite for local, MySQL/PostgreSQL for remote). Source: src/zenml/zen_stores/sql_zen_store.py.
2. REST ZenStore — used by clients that connect to a remote server; it serializes/deserializes models and forwards CRUD calls to the REST API.

Core Domain Entities

The SQL ZenStore defines table schemas for the principal entities:

• Users, Teams, Roles, Permissions — identity and authorization
• Workspaces, Projects — tenancy and grouping
• Stacks, Stack Components, Flavors — infrastructure configuration
• Pipelines, Pipeline Runs, Steps, Step Runs — execution history
• Artifacts, Artifact Versions, Artifact Visualizations — produced data
• Schedules, Pipeline Builds, Pipeline Deployments — execution plans
• Models, Model Versions, Model Versions Stages — model control plane
• Service Connectors, Service Connector Types — external service credentials

Source: src/zenml/zen_stores/sql_zen_store.py.

Schema Migrations

Schema changes are managed through versioned migration scripts. On server startup, the SQL ZenStore checks the current schema version and applies pending migrations before accepting traffic. This is why database upgrades require care and cannot be skipped between minor versions.

Secrets Storage

Sensitive values (passwords, tokens) are not stored in the main database. Instead, the server supports pluggable secrets stores — AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, and HashiCorp Vault — configured via Helm values or environment variables. Source: helm/README.md.

Deployment and Community Considerations

Helm Deployment

The official Helm chart at helm/README.md packages the server with configurable:

• Database backend (external MySQL/PostgreSQL is recommended for production)
• Authentication type
• Secrets store backend
• Custom CA certificates for self-signed infrastructure
• Resource limits, replica count, and ingress configuration

Known Issues and Limitations

Several community-reported issues are tightly coupled to this subsystem:

• Issue #4251 — zenml login fails without SQL dependencies when connecting to remote server. A base pip install zenml (without [sql] extras) cannot connect to a self-hosted remote server because the SQLAlchemy-based REST ZenStore requires the SQL dependency to even parse server-side schemas. The fix is to install with the appropriate extras (e.g., zenml[server]) when connecting to remote deployments.
• Issue #4407 — MLflow authentication on AzureML with custom tracking server. Authentication for the MLflow experiment tracker integration is delegated to the underlying tracking server; misconfigured AzureML credentials propagate to the ZenML stack component.
• Issue #4498 — Neptune experiment tracker sunset. When third-party SaaS providers (such as Neptune) sunset, integrations that hard-depend on their services break at the stack-component layer; users must migrate stacks to alternative experiment trackers before the deadline.

These issues highlight that authentication, integrations, and persistence are coupled: a server-level configuration change can break stack components, and a base-package install can omit dependencies required by remote connectivity.

See Also

• ZenML Repository README
• ZenML Helm Chart
• Deployment Documentation
• Stacks and Components
• ZenML Pro

Doramagic Pitfall Log

Found 12 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Installation risk - Installation risk requires verification.

1. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/zenml-io/zenml/issues/4912

2. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/zenml-io/zenml/issues/4905

3. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/zenml-io/zenml/issues/4740

4. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/zenml-io/zenml

5. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/zenml-io/zenml/issues/4972

6. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/zenml-io/zenml

7. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/zenml-io/zenml

8. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/zenml-io/zenml

9. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/zenml-io/zenml/issues/4894

10. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/zenml-io/zenml/issues/4652

11. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/zenml-io/zenml

12. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/zenml-io/zenml

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using zenml with real data or production workflows.

• More flexible numpy versioning - github / github_issue
• Display failure/success hooks and their output - github / github_issue
• OAuth-Based Authentication for Managed MLflow Backends - github / github_issue
• Add dependency audit workflow - github / github_issue
• Kubernetes deployer Service selector mismatch (ZenML 0.94.2) - github / github_issue
• Pending pods visibility - github / github_issue
• Clean up the failing tests on the CI - github / github_issue
• Extend platform trigger event sources (+ snapshots) - github / github_issue
• skypilot/utils.py: create_docker_run_command passes -e KEY without value - github / github_issue
• 0.95.1 - github / github_release
• 0.95.0 - github / github_release
• 0.94.6 - github / github_release