Conveyor CI is an embeddable workflow orchestration runtime for platform developers. It manages workflows, jobs, state transitions, events, and logs, while execution is delegated to infrastructure-specific drivers.
It is intended for teams building internal developer platforms, custom CI/CD systems, deployment backends, and automation layers that need control over how and where workloads run.
External Platform
UI, auth, product logic, developer experience
Conveyor CI
workflow state, job lifecycle, events, logs, APIs
Driver Layer
Kubernetes driver, server driver, VM driver, edge driver
Execution Environment
containers, processes, devices, clusters, custom systems
Conveyor focuses on the orchestration layer of automation systems. It does not provide a hosted service, a dashboard-first CI product, or a fixed runner model.
Control plane
Manages workflow state, job lifecycle, events, retries, cancellation, and log coordination.
Driver model
Delegates execution to user-defined drivers, allowing workloads to run on Kubernetes, servers, VMs, edge devices, or custom infrastructure.
API-first runtime
Exposes orchestration primitives through APIs and SDKs so Conveyor can be embedded into other platforms.
Log streaming
Streams execution logs from drivers back to the control plane for consumption by external tools or user interfaces.
Conveyor is useful when the workflow engine should be embedded inside another system rather than adopted as a complete CI/CD platform.
Decouples orchestration from execution
Conveyor does not assume how a job should run. It tracks and coordinates the lifecycle while drivers implement the execution strategy.
Useful for platform builders
It is designed for teams building internal developer platforms, CI/CD backends, PaaS systems, or automation layers.
Infrastructure-agnostic by design
The driver boundary allows Conveyor to target different environments without tying the core runtime to one infrastructure API.