TopGit
GitHub Repo Review

CDS: Continuous Delivery Platform for CI/CD

ovh/cds
CTopGit review image for ovh/cds
Review by Topgit.dev for ovh/cds, with GitHub repository stats and README context.
Quick verdict

CDS is OVH's self-hosted continuous delivery and DevOps automation platform, built in Go and running in production at OVH since 2015. A CDS Workflow chains pipelines with joins and forks, letting one team maintain a single build-and-deploy pipeline for hundreds of apps instead of one per app. Reach for CDS at that scale; skip it for a single lightweight repo, since CDS is a multi-component platform to operate.

Stars
★ 4.8k
Forks
⑂ 456
Contributors
👥 112
Language
Go
License
BSD-3-Clause
Topic
Automation
Updated
Aug 2026
Homepage
GitHub

Understanding CDS Workflows and Pipelines

CDS is a continuous delivery and DevOps automation platform built around the CDS Workflow, which chains pipelines together with triggers, joins, and forks instead of a flat job list. Each pipeline is a sequence of stages, and each stage runs multiple jobs at once while keeping them isolated. A pipeline starts with zero or one application and environment as context, so it runs against dev, staging, or production just by swapping that context.

Key Capabilities of the CDS Platform

  • CDS Workflows chain pipelines together with triggers, joins, and forks, so one build pipeline and one deployment pipeline can back hundreds of applications instead of one pipeline per app, per the README.
  • Workflow templates let a team publish a reusable workflow, maintain it as code or from the UI, and bulk-update every workflow built from that template in a single action.
  • Workflow-as-code: you git-push YAML files describing a workflow's pipelines, applications, and environments, so changes can be tested on a dev branch before merging to master.
  • Native two-way integration with GitHub, GitLab, Bitbucket Server, and Gerrit — CDS triggers builds on pushes and reports build status (Building, Success, or Failed) back to the git host.
  • Job's Services spin up ephemeral containers next to a job — the README's own example pairs Redis and PostgreSQL with an application — so tests run against a real database and cache instead of mocks.
  • Hatcheries auto-scale CDS Workers on demand across Kubernetes, OpenStack, VMware vSphere, Docker Swarm, or a local host; OVH's original target was building and deploying 150 applications as containers in under 7 minutes, which the README says became reality in 2015.
  • cdsctl, the CLI, covers everything the web UI can do — create, launch, export, and import workflows, and follow a run from the terminal with cdsctl workflow --track.
  • Group-based permissions restrict read, write, and execute rights per project, and a REST API plus a Go SDK are available for building your own tooling on top of CDS.
How this repository's GitHub stars have grown over time. Source: star-history.com.View the star history

Getting Started with CDS Installation

The README doesn't inline install commands — it links out to a Docker Compose-based 'Ready To Run' tutorial and a from-binaries guide on the OVH documentation site instead. For production use, the README directs you to the official release published on the project's GitHub releases page rather than building from source. CDS has been open source since October 2016 and is meant to be self-hosted inside your own company or at home; the exact step-by-step commands aren't part of the README itself, so treat those linked docs as the source of truth.

Who Benefits from Using CDS?

CDS fits a platform or DevOps team standing up CI/CD for many applications at once, not a single project. If your team would otherwise maintain dozens of near-identical Jenkins-style pipelines, CDS Workflows and workflow templates are built to collapse that into one pipeline reused with a different context per run. It also suits teams already running GitHub, GitLab, Bitbucket Server, or Gerrit that want two-way build-status integration without wiring it up themselves. It's a poor fit for a solo developer or a team with one or two repos — the API/worker/hatchery stack is more infrastructure than a single pipeline needs.

Strengths

  • Production-proven at scale: the README says CDS has run in production at OVH since 2015 and launches more than 7 million CDS workers per year there.
  • Workflow reuse is structural, not just described — joins, forks, and per-run context let one pipeline back many applications instead of copy-pasted pipelines.
  • Stateless API design lets multiple CDS API instances run behind a load balancer, and the README says OVH upgrades CDS several times a day without stopping workers or affecting users.
  • Native two-way integration with GitHub, GitLab, Bitbucket Server, and Gerrit, plus triggers from webhooks, schedulers, and event buses like Kafka or RabbitMQ.
  • cdsctl mirrors the full web UI, so scripting a workflow launch or checking its status doesn't require opening a browser.
  • BSD-3-Clause license — permissive, with no restriction on self-hosting CDS inside a company.

Current Considerations for CDS Adoption

  • CDS is a multi-component system — API, workers, hatcheries, and a UI — not a single binary, so standing it up is more infrastructure than a lightweight CI action.
  • The README flags this project as under active development and gives no version number or release cadence, so expect ongoing change.
  • Persisting build artifacts long-term needs Swift Storage or a filesystem, and the README calls the filesystem option not recommended, so realistic use likely means configuring object storage up front.
  • Exact install commands aren't documented inline — the README defers to external tutorials (Docker Compose, from-binaries) rather than walking through setup itself.
  • Auto-scaling depends on configuring a hatchery for your own infrastructure — Kubernetes, OpenStack, vSphere, Swarm, or local — there's no generic default that works out of the box.

Comparing CDS with Other CI/CD Tools

jenkins — the long-running self-hosted CI/CD server; more plugin-driven and free-form than CDS's structured Workflow/pipeline/stage model, and considerably older.GoCD — another self-hosted continuous delivery platform comparable in scope to CDS, built around explicit pipeline dependency graphs rather than CDS's joins and forks.GitLab CI/CD — pipelines built into a self-hosted GitLab instance; a smaller deployment if you already run GitLab, versus CDS's separate API/worker/hatchery stack.Concourse CI — another self-hosted, stateless CI/CD platform built around pipelines-as-code, similar in deployment weight to CDS.

Common Questions About CDS

Can CDS be used in production environments?

CDS is designed for production use — the README says it has run in production at OVH since 2015 and launches more than 7 million CDS workers per year there. CDS ships logs, metrics, and monitoring for tracking production activity, and OVH recommends installing the official release from CDS's GitHub releases page instead of building from source.

How do I back up data in CDS?

CDS stores all of its data in the database and nothing on the filesystem, according to the README, so backing up CDS means backing up that database on a regular schedule — there's no separate filesystem state to capture.

What is the licensing model for CDS?

CDS is released under the 3-clause BSD license, listed as BSD-3-Clause on GitHub — a permissive open-source license with no copyleft requirement on software built around CDS.

What types of Git integrations does CDS support?

CDS natively integrates with GitHub, GitLab, Bitbucket Server, and Gerrit, per the README. The integration is two-way: CDS can trigger a build when a change is pushed, and it pushes the build status (Building, Success, or Failed) back to the git-based tool.

Where can I find help or support for CDS?

The README points to the CDS Core Team on GitHub Discussions for help, alongside the project's documentation site at ovh.github.io/cds and the blog posts and conference talks about CDS linked from the README.

The problem it solves

Most CI/CD tools model a project as a flat pipeline of jobs, so a company running hundreds of applications ends up copying the same build-and-deploy logic into hundreds of near-identical pipelines, one per app. CDS's README frames its own reason for existing around that duplication: a CDS Workflow lets you chain pipelines with joins and forks so the same build pipeline and the same deployment pipeline can back every application, with only the per-run context — which application, which environment — changing between runs.

Best use cases

  • Replacing dozens of near-duplicate CI pipelines with one CDS Workflow and one shared deployment pipeline reused across every application, the pattern the README describes for large application counts.
  • Running integration tests that need a live database or cache for the duration of a job, using Job's Services to start containers like Redis or PostgreSQL alongside the test.
  • Standardizing test and deployment practice across teams by publishing a workflow template that every project inherits and bulk-updates from.
  • Auto-scaling CI workers across Kubernetes, OpenStack, vSphere, or Swarm through hatcheries instead of running a fixed pool of static build agents.
  • Deploying an application to a Kubernetes cluster in Helm format through the built-in Kubernetes integration on a CDS project.

Related repositories

Source & attribution

Facts and quotes sourced from the ovh/cds GitHub repository and its README.

GitHub data · last synced Aug 12, 2026Reviewed by Henry
Back to TopGit

Curious whether cds is right for you?

Let ChatGPT, Claude, or Perplexity look into it — click below and see what AI actually says about cds.

GitHub