CDS is an enterprise continuous delivery platform written in Go

CDS is a continuous delivery platform written in Go

CDS stands for Continuous Delivery Service. The README describes it as an Enterprise-Grade Continuous Delivery and DevOps Automation Platform written in Go. The project is under active development, and its documentation is published on ovh.github.io/cds. CDS is built for organizations that want to automate build, test, and deployment through one platform instead of maintaining many separate scripts. The README frames CDS as a tool for continuous delivery, the practice of keeping software ready to ship through automated pipelines. Continuous delivery builds on continuous integration, where code changes are merged and tested often, and extends it to releasing software on demand. A platform like CDS wraps those steps in one system so teams do not script each stage by hand.

Workflows chain pipelines with triggers

Most CI/CD tools organize work around jobs inside a pipeline. CDS introduces a concept it calls CDS Workflows. A workflow lets you chain pipelines together with triggers, so the result of one stage can start the next. A pipeline is structured into sequential stages, and each stage can hold one or more concurrent jobs. This model lets a team represent a full release path, from build through deploy, as one connected object rather than many unrelated tasks. The README highlights workflows as a key feature of CDS. Triggers are the links between pipelines: when one pipeline finishes, it can fire the next one, passing along the context it produced. This removes the manual handoffs that slow releases and makes the whole path auditable in one view.

The cdsctl command line and workflow as code

CDS ships a command line named cdsctl that the README calls the most powerful command line for a CI/CD platform. You can script nearly everything with cdsctl, and it includes commands such as cdsctl shell to browse projects and workflows without opening a browser. Beyond the CLI, CDS supports workflow as code: you define your workflow, pipeline, application, and environment in YAML files and git-push them. This lets you test a new workflow on a dev branch before merging it into master, which keeps pipeline changes under version control.

Native Git integration with GitHub, GitLab, and Bitbucket Server

CDS integrates with popular Git hosts. The README states it has native two-way integration with GitHub, GitLab, and Bitbucket Server. In practice this means CDS can start a build when a change is pushed, and it can report the build status of each commit back to the Git tool as Building, Success, or Failed. A CDS application maps to a single Git repository, and that link is how CDS knows which code to build. The integration is described as two-way because status flows back to the Git provider as well as in. Because the status flows back to the Git provider, reviewers see clear marks next to their commits without leaving their normal workflow. That close loop between source control and CI/CD is what the README means by native integration.

Workflow templates and visual configuration

Teams can configure CDS in two ways. The web UI lets you build complex workflows graphically, which the README notes is often easier for complex use cases. Workflow templates let a company share and reuse workflows across many teams, so a predefined catalog of workflows can standardize test and deployment practices. Templates can be maintained as code or from the UI, and a single action can bulk update a set of workflows, which reduces maintenance effort as the number of teams grows.

Production use at OVH and monitoring

CDS has been used in production since 2015 at OVH, and the README states it launches more than 7 million CDS workers per year. It provides the monitoring and measurement features needed for production activity, including logs, metrics, and monitoring. For data safety, all data is stored in the database with nothing on the filesystem, so a regular database backup is enough to stay safe. This design keeps state in one place and simplifies disaster recovery. The monitoring story matters because a delivery platform is only useful if operators can see what ran, for how long, and whether it succeeded. Logs and metrics give that visibility, while the database-only storage model keeps the operational surface small.

Why teams choose CDS

The README lists several reasons teams use CDS, grouped under self-service, horizontal scalability, high availability, pipeline reutilisability, a REST API, and customizability. Horizontal scalability and high availability matter for large fleets of workers, while the REST API and customizability let teams fit CDS into existing tooling. A Docker-Compose setup is offered for anyone who wants to try CDS locally before a larger deployment, and the project points to ready-to-run tutorials for that path.

Editorial conclusion

CDS (Continuous Delivery Service) is an enterprise-grade CI/CD and DevOps automation platform written in Go. Its workflow model chains pipelines with triggers, the cdsctl command line and workflow-as-code cover scripting and version control, and native GitHub, GitLab, and Bitbucket Server integration keeps builds tied to source control. Used in production at OVH since 2015 with more than 7 million workers launched per year, CDS pairs scalability and availability with templates and a REST API for teams that want to standardize delivery across many projects.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. ovh/cds on GitHub
3. Project website
4. README
5. Releases