[Sandbox] Conveyor CI #452
Description
Project summary
Conveyor CI is a headless orchestration engine designed for platform developers to build custom CI/CD systems and delivery pipelines.
Project description
Conveyor CI is a headless orchestration engine designed to be the backend for custom Internal Developer Platforms (IDPs). While traditional CI tools bundle a UI, storage, and opinionated runners into a single suite, Conveyor CI provides only the orchestration logic via an API-first control plane. This allows platform engineers to build their own delivery interfaces and automated workflows on top of a neutral, highly extensible core without reinventing pipeline state management.
Technically, Conveyor CI manages high-performance DAG-based scheduling, event-driven job triggers, and real-time log aggregation. It utilizes a pluggable driver architecture that enforces a strict separation between the control plane (the "brain") and execution (the "muscles"). By delegating actual job processing to user-defined drivers, the engine can orchestrate workloads across diverse environments, ranging from standard Kubernetes clusters to resource-constrained edge devices and air-gapped infrastructure.
Powered by an embedded NATS server for messaging and etcd for distributed state, Conveyor CI provides a resilient, horizontally scalable runtime. It exposes a clean SDK Design Architecture and implementations in Go, Rust and Python that standardizes the contract between the orchestrator and the execution environment, enabling the community to build specialized drivers for any infrastructure target while maintaining a unified automation logic.
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/open-ug/conveyor
Additional repos in scope of the application
No response
Website URL
Roadmap
https://conveyor.open.ug/docs/contributing/roadmap
Roadmap context
The project always publishes near monthly releases however all these follow a High-level Road-map. As of 2026 the following are the high level roadmap objectives.
| Phase | Objective |
|---|---|
| Phase 1 |
|
| Phase 2 |
|
| Phase 3 |
|
| Phase 4 |
|
| Phase 5 |
|
| Phase 6 |
|
| Phase 7 |
|
| Phase 8 |
|
Contributing guide
https://conveyor.open.ug/docs/contributing/how-to-contribute
Code of Conduct (CoC)
https://github.com/open-ug/conveyor/blob/main/CODE_OF_CONDUCT.md
Adopters
Crane Cloud utilized Conveyor CI as the headless orchestration engine for Mira, its automated containerization platform. Mira leveraged Conveyor to manage complex build lifecycles for both Git-based workflows and manual ZIP file uploads, with Conveyor CI as a Control plane that orchestrates Mira Drivers that carry out the build, containerization and deployment logic of application source code. This implementation demonstrates Conveyor’s utility as a specialized backend for PaaS providers who require full control over the developer experience without managing a monolithic CI server.
Maintainers file
https://conveyor.open.ug/docs/contributing/mantainers
Security policy file
https://github.com/open-ug/conveyor/blob/main/SECURITY.md
Standard or specification?
N/A
Business product or service to project separation
This project is unrelated to any product or service.
Why CNCF?
Conveyor CI seeks to join the CNCF to establish a neutral, community-driven home for the next generation of headless orchestration. As a project designed to sit at the core of Internal Developer Platforms, its success depends on a broad ecosystem of pluggable drivers and integrations. Joining the CNCF provides the necessary framework to achieve three primary goals:
- Vendor Neutrality and Ecosystem Trust: For Conveyor CI to succeed as a "building block" for other platforms, users must trust that the core orchestration logic is not tied to a single vendor or cloud provider. The CNCF provides the neutral governance required for organizations to confidently build their proprietary infrastructure on top of our SDK.
- Fostering a Shared Driver Ecosystem: The "pluggable driver" model is only as strong as the variety of its drivers. Under the CNCF, we can more effectively collaborate with other project communities to develop standardized execution wrappers. A neutral foundation encourages diverse contributions, ensuring that drivers for niche or specialized hardware are maintained by the community rather than a single entity.
- Community Sustainability: Moving Conveyor CI to the CNCF ensures the project’s long-term sustainability, moving it beyond a single-maintainer model and opening the door for global mentorship and contribution.
Benefit to the landscape
Conveyor CI introduces a decoupled orchestration primitive to the cloud-native ecosystem. Currently, the landscape is divided between full-stack CI/CD platforms (like Jenkins or GitLab) and Kubernetes-native workflow engines (like Tekton or Argo). While powerful, these projects are "operator-facing", they assume the user wants to manage a complex platform with an opinionated UI and heavy infrastructure dependencies.
Conveyor CI fills a critical gap for Platform Engineers by providing a "developer-facing" orchestration library. The primary benefits to the landscape include:
- Infrastructure-Agnostic Orchestration: Most modern orchestrators are hard-coded to the Kubernetes API (CRDs). Conveyor CI provides a standalone control plane that can operate in environments where Kubernetes is too heavy or unavailable, such as Edge computing, IoT deployments, and restricted air-gapped networks.
- Standardization of the "Execution Contract": By providing a formal SDK and a "Driver" interface, Conveyor CI standardizes how custom execution logic (Docker, Firecracker, Bare Metal) communicates with an orchestration core. This allows the community to build and share specialized drivers without reinventing the state-machine, logging, and queuing logic for every new hardware target.
- Minimalist Footprint for Embedded Use: Unlike monolithic CI tools that require high RAM/CPU overhead to manage a dashboard and database, Conveyor CI is a lightweight binary designed to be embedded into other applications. This lowers the barrier to entry for small-scale startups and specialized SaaS providers to offer native automation features without managing a massive infrastructure stack.
Cloud native 'fit'
Conveyor CI is built from the ground up to embody the core principles of the Cloud Native Computing Foundation: resilience, loose coupling, and observability. Its architecture is not merely "container-friendly," but follows the distributed systems patterns pioneered by the CNCF ecosystem.
- Distributed State & Consensus: By utilizing
etcdas its primary state store, Conveyor CI adopts the same consistency and partition-tolerance models that power Kubernetes. This ensures that even in highly distributed or unstable environments (such as the Edge), the "Source of Truth" for pipeline state remains durable and consistent across the cluster. - Event-Driven Orchestration: Instead of relying on brittle polling mechanisms, Conveyor CI leverages NATS for a high-performance, event-driven internal architecture. This allows the engine to scale horizontally as job volume increases, additional instances of the control plane can be deployed to handle orchestrations, while NATS manages the asynchronous delivery of job events to the relevant drivers.
- Decoupling of Logic and Compute: A fundamental cloud-native tenet is the separation of concerns. Conveyor CI achieves this through its Driver-agnostic model. The control plane manages the lifecycle and state transitions (The Logic), while the drivers manage the execution environment (The Compute). This decoupling allows teams to upgrade, scale, or swap infrastructure providers without disrupting the central automation logic.
- Immutable and Stateless Design: The Conveyor CI control plane is designed to be effectively stateless. When requirements need a stateless control plane, it can be configured that critical data is offloaded to the distributed state store, allowing the engine instances to be destroyed and recreated at any time without data loss, a requirement for running reliably on modern container orchestrators.
Cloud native 'integration'
Conveyor CI is engineered to be a good citizen of the CNCF ecosystem by adopting the standards and projects that define modern infrastructure. Its integration strategy is focused on interoperability, modularity, and adherence to cloud-native observability patterns:
- Direct Consumption of CNCF Projects: Rather than implementing proprietary state or messaging protocols, Conveyor CI leverages etcd for distributed consensus and NATS for high-performance, event-driven orchestration. By building on these proven primitives, Conveyor ensures the engine meets the high availability and scalability requirements of production cloud environments.
- Hybrid Kubernetes Interoperability: While Conveyor CI is designed to operate in resource-constrained environments (Edge/IoT), it is fully optimized for Kubernetes. It can be deployed via Helm, managed as a standard microservice, and utilize specialized Kubernetes Drivers to execute workloads as Pods or Jobs. This allows it to act as a unified control plane for organizations managing hybrid infrastructure that spans both cloud clusters and bare-metal edge nodes.
Conveyor CI is also designed to ensure future extensibility and integration with other Cloud Native Projects is possible via it pluggable drivers.
Cloud native overlap
Conveyor overlaps functionally with workflow/orchestration projects (Argo Workflows, Tekton Pipelines, Concourse) in that all solve execution/orchestration and DAG-style workflows.
The differentiator is Conveyor’s headless, driver-focused architecture (API/SDK, driver runtime) and its intent to be a small, embeddable control plane rather than a full suite (dashboard + opinionated UX).
Similar projects
Conveyor CI functionally overlaps with several workflow and orchestration projects within the CNCF landscape, specifically those managing Directed Acyclic Graphs (DAGs) and pipeline execution. However, its architectural intent and target user define a distinct category: it is a CI/CD engine, not a CI/CD platform.
Comparison CNCF Projects
- Argo Workflows: Argo is an operator-facing platform designed for high-visibility workflow management, complete with a robust UI and complex controller logic. Conveyor CI is "headless" by design. It provides no UI and focuses exclusively on being an embeddable engine. While Argo is a tool for end-users to run jobs, Conveyor is a toolkit for developers to build their own automation products.
- OpenChoreo: OpenChoreo is an opinionated Internal Developer Platform (IDP) that aggregates multiple CNCF projects (like Backstage and Argo) into a "Golden Path" for application developers. In contrast, Conveyor CI provides the unbundled orchestration primitives (SDK/API) for platform engineers to build their own bespoke delivery systems without the overhead of a full-stack suite.
Other Landscape Projects
- Tekton Pipelines: Tekton is a powerful, K8s-native framework. However, it is fundamentally coupled to the Kubernetes API and relies on Custom Resource Definitions (CRDs) for state management. Conveyor CI is infrastructure-optional, it provides a standalone Go runtime that can manage workflows on bare metal, edge devices, or air-gapped environments where a Kubernetes control plane is either unavailable or too resource-intensive.
- Jenkins: Jenkins is a monolithic, all-in-one CI server. Conveyor CI enforces a strict separation between the control plane and execution. Unlike Jenkins, which bundles the UI, plugin system, and worker logic, Conveyor offers a minimalist binary that handles only orchestration logic, leaving the specific execution (Drivers) to the platform developer.
Landscape
No
Trademark and accounts
- If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF
IP policy
- If the project is accepted, I agree the project will follow the CNCF IP Policy
Will the project require a license exception?
N/A
Project "Domain Technical Review"
No response
Application contact email(s)
Contributing or sponsoring entity signatory information
Or, if an individual or individual(s):
| Name | Country | Email address |
|---|---|---|
| Beingana Jim Junior | Uganda | jim.junior.beingana@gmail.com |
CNCF contacts
No response
Additional information
No response