Why Pipekit

A control plane for Argo Workflows. Observability, governance, scale, and security on top of what Argo already gives you.

Pipekit is the control plane for Argo Workflows. Platform teams use it to operate Argo at scale and give their developers a self-serve surface; data and ML teams use it to find, debug, and re-run their pipelines without learning the cluster.

Pipekit sits on top of Argo, not in place of it. Your workflows still execute as Argo Workflows on your own Kubernetes clusters; Pipekit adds the dashboards, access control, multi-cluster management, log handling, and integrations that teams typically rebuild themselves.

Four reasons teams adopt Pipekit:

• Observability: unified UI across clusters, persisted Run history and logs, log-level detection and search, OpenTelemetry workflow metrics.

• Governance: workspaces, IdP-backed RBAC, per-environment secrets, default-deny access, audit-quality submission enforcement.

• Scale: multi-cluster routing, node-status offloading, Vector-based log collection, cross-cluster disaster recovery.

• Security: bring-your-own-cluster architecture, SBOMs and signed containers, optional self-hosted control plane for air-gapped deployments.

Architecture at a glance

Pipekit architecture

Pipekit deploys a small agent into each Kubernetes cluster alongside Argo Workflows. The agent brokers commands from Pipekit's control plane and reports status, logs, and metrics back. Your workflows, data, and compute stay in your cluster; the control plane is hosted by Pipekit, or you can self-host the whole stack.

For the two deployment models side by side, see Pipekit Cloud vs Self-Hosted.

To try Pipekit, follow Get Started > Evaluate Pipekit Cloud. It's a 5-minute path from sign-up to a running workflow.