Introduction
Pyplines turns operational procedures into reusable workflows. Compose existing Actions into a YAML Definition, deploy it into an Environment, and execute it as a Run with controlled access, approval requirements, and retained execution evidence.
You can use Pyplines without writing Python. When suitable Actions are available in your organization's registry, your work is choosing them, connecting their inputs and outputs, and operating the resulting workflow. Custom Action development extends what the platform can automate.
What you can do
- Capture a repeatable operational procedure in a portable Definition.
- Reuse the same Definition with different Environment configuration and secrets.
- Pin the Actions used by a deployment and retain revisions for later inspection.
- Control who can deploy, start, approve, and recover work.
- Observe execution, investigate failed attempts, and make explicit recovery decisions.
Service checks, controlled remediation, and maintenance procedures are examples of workflows you can compose when your registry supplies the necessary Actions. See Action availability before choosing an integration.
Choose your starting point
| Your task | Start here |
|---|---|
| Use an existing installation | Run your first workflow |
| Understand the platform | Core concepts |
| Turn a procedure into a workflow | Build a Definition |
| Support running automation | Monitor Runs and recover execution |
| Set up Pyplines for a team | Install the platform |
| Add an integration that is missing | Develop an Action |
How the platform fits together
The operator CLI, pyplines, connects to the server API. The server stores Definitions, revisions, access rules, policies, and execution evidence. Enrolled runners execute the pinned Action images using Docker. An Environment connects these workflows to a registry, runner pool, public context, and secrets.
The Action CLI, pyplines-action, and Python SDK are authoring tools for people maintaining Actions. Operators do not need them to use already published Actions.
Current scope
Steps execute sequentially, with conditions controlling whether a step runs. Each Environment executes one Run's attempt at a time; separate Environments can make progress concurrently using available runners.
The current platform uses the CLI and API. It has no web console, built-in schedules, webhooks, loops, arbitrary script steps, or infrastructure state engine. External automation can call the API or CLI to start a Run. See architecture and boundaries for execution and recovery guarantees.
Documentation and software versions
The maintained docs update independently of software releases and describe the supported platform/tooling combination shown in the site. Platform releases contain the server and runner; tooling releases contain the CLIs, SDK, and Action base images. Their versions can differ.
Use the version selector for release snapshots. A snapshot records its release group and version; release candidates are marked as previews. Updating tooling does not rebuild existing Action images or change an existing Run's pinned Actions.