Design-partner architecture

Use case · Self-hosted CI/CD

Model CI/CD as a governed workflow on infrastructure you control

CI is a useful secondary wedge for Rollout's runtime: builds, tests, approvals, and deploys are durable steps with shared state and one run record. The engine exists today; general self-host distribution does not. We deploy this architecture with design partners while the self-host capstone is completed.

  1. 01

    Trigger

    Start from a webhook, a schedule, a workspace state change, or an operator.

  2. 02

    Restore

    Mount a lockfile-keyed cache and a run workspace shared by downstream steps.

  3. 03

    Build + test

    Run shell or container work on Docker or Kubernetes and stream the result.

  4. 04

    Gate + deploy

    Pause for a recorded approval, then continue into staging or production.

  5. 05

    Review

    Inspect one run record with step status, output, timing, and the operator decision.

rollout.dev/workflows/release-pipeline · build, approval, deploy
A release workflow with build, staging, approval, production deploy, and verification steps
Captured from a representative demo workspace; availability is described below.

Runtime contracts

The pieces behind the pipeline

These are implemented engine capabilities, with documentation for the behavior and configuration boundary behind each claim.
Execution Shipped

Docker and Kubernetes runtimes

A workflow selects its runtime once; shell steps execute in ephemeral containers or tenant-isolated Kubernetes pods instead of on the Phoenix host.

Workflow docs →
State Shipped

One workspace across the run

Steps share `/workspace`, while persistent-by-key cache volumes retain dependency or layer state across runs on the configured Docker or Kubernetes storage backend.

Node settings →
Resources Kubernetes

CPU and memory per shell step

A Kubernetes shell step can override its CPU and memory limits without making every other step pay for the same runner shape.

Workflow nodes →
Control Durable

Approvals are run state

A human-input node suspends the run without holding compute and resumes the same run after the response arrives.

Human approvals →

Availability

Implemented engine, unfinished distribution

Shipped in the engine

The workflow engine, Docker and Kubernetes runtimes, cache volumes, resource controls, human gates, and run history are implemented. Rollout production still deploys through GitHub Actions while the self-host CI capstone is completed.

Planned distribution

General self-host distribution is still planned. Today this is available through a design partnership, deployed with the founder on infrastructure you control.

Fit

Know the boundary before you move a pipeline

  • This is not a drop-in runner for GitHub Actions YAML; the pipeline is modeled as a Rollout workflow.
  • On Kubernetes, shared-workspace steps use one RWO workspace and therefore serialize; isolated steps can run in parallel.
  • Persistent cache volumes work through Docker volumes or Kubernetes PVCs. The separate rollout.cache archive nodes currently require the Local blob backend.
  • The built-in matrix primitive is single-axis today.

Bring a pipeline, not a blank canvas

We are working with a small number of teams to deploy real build and release workflows on infrastructure they control.

Prefer to talk it through? Talk to the founder

Need the commercial shape first? See pricing.