[Sandbox] Conveyor CI

[jim-junior]

Project summary

Conveyor CI is a headless, embeddable workflow orchestration engine for platform developers to build custom automation, delivery, and task execution systems across arbitrary infrastructure.

Project description

Conveyor CI is a headless workflow orchestration runtime for building custom delivery pipelines and internal developer platforms (IDPs). While traditional CI/CD and Workflow tools bundle a UI, storage, and runners into a monolithic platform, Conveyor CI provides only the orchestration logic via an API-first control plane. This allows platform teams to embed a neutral, highly extensible core into their own systems without reinventing pipeline state management.

Technically, the project focuses on high-performance DAG scheduling, workflow orchestration, event-driven job triggers, and real-time log aggregation. It features a pluggable driver architecture that enforces a strict separation between the control plane (the "brain") and execution logic (the "muscles"). By delegating job processing to user-defined drivers, the engine can orchestrate workloads across diverse environments, including Kubernetes, bare-metal servers, and resource-constrained edge devices. Conveyor CI also allows users to adopt any architecture, it can be used in both a distributed microservices architecture(default) or embedded directly into one single monolith application binary using Go.

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

https://conveyor.open.ug

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 DONE	Develop a Standard SDK implementation in Go Enable Streaming Pipeline Logs
Phase 2	Parallel and Concurrent Workflow Execution
Phase 3	Implement Directed acyclic graph(DAG)
Phase 4	Secrets and Pipeline Variables
Phase 5	Authorization and RBAC
Phase 6	Name-spacing
Phase 7	System Observability and Monitoring
Phase 8	Alignment with the CDEvents specification

Detailed Roadmap Task progress can be tracked via the projects GitHub Milestones

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

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 mainly fills a critical gap for Platform Engineers by providing a "developer-facing" API first workflow orchestration library. Other primary benefits to the landscape include:

• Infrastructure-Agnostic Orchestration: Many cloud-native workflow engines, especially those in the Kubernetes ecosystem, are tightly coupled to Kubernetes APIs and CRDs. Conveyor CI provides a standalone control plane that can operate in environments, such as Edge computing, IoT deployments, and restricted air-gapped networks.
• Minimalist Footprint for Embedded Use: Unlike full CI/CD platforms that bundle UI, storage, scheduling, runners, and administrative workflows, Conveyor focuses only on the orchestration control plane. It is a lightweight binary/library 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 etcd as 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.

Futhermore, due to its headless design, there are multiple scenarios the project can integrate with various CNCF projects, its 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 in that all solve execution/orchestration and DAG-style workflows. It mainly overlaps with Argo Workflows

The differentiator is Conveyor’s headless, code-driven and 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 workflow orchestration projects within the CNCF landscape, specifically those managing Directed Acyclic Graphs (DAGs) and pipeline execution.

• Argo Workflows: is an open-source, Kubernetes-native workflow engine designed for orchestrating complex data pipelines and batch processing at scale, its 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 a headless/embeddable engine.

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)

jim.junior.beingana@gmail.com

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

[chadbeaudin]

Recommend the project consider resubmitting in 6 months with more adopters and more contributors.