# spinnaker/spinnaker: the issue-tracking monorepo behind a multi-cloud CD platform

> The spinnaker/spinnaker repository is not the product you install. It is the issue tracker and monorepo umbrella for Spinnaker's microservices, and the README says so plainly.

**spinnaker/spinnaker** — Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.

- Repository: https://github.com/spinnaker/spinnaker
- Website: http://www.spinnaker.io/
- Stars: 9,794 · Forks: 1,272
- Language: Java
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/spinnaker-spinnaker

## What spinnaker/spinnaker actually contains

The first thing to get straight is that this repository is a monorepo of source and an issue tracker, not a distribution. The README states that "this repo is only used for issue tracking across the various services at this time" and that releases are not managed here. The top-level entries confirm the scope: clouddriver/, deck/, echo/, fiat/, front50/, gate/, igor/, kayenta/, keel/, kork/, orca/, rosco/ and spin/ sit side by side with build.gradle, settings.gradle and gradle.properties. Each directory is a service with its own responsibility, and the Gradle build ties them together for development rather than for end-user installation.

The problem it solves is organizational. Spinnaker is built from a number of independent microservices, and without a central place to file bugs and enhancements, issues would scatter across a dozen repositories. This repository is that central place, and the README points readers to the Spinnaker site, the Slack workspace and the governance repository for everything else. If you are evaluating Spinnaker as a product, this is the wrong front door. The correct one is the installation guide on spinnaker.io.

## The microservice architecture and what Clouddriver does

Spinnaker's delivery model is a set of cooperating services. The README describes them as independent microservices whose lifecycle is managed by the Halyard CLI or by the Kubernetes Operator, which the README marks as Beta. Clouddriver is the component that talks to cloud providers; the README says you use it to deploy to all of the major public cloud providers and to Kubernetes. Orca runs the pipelines, and the pipeline is the unit of work: a sequence of stages that can bake a VM image, deploy a manifest to Kubernetes, attach a load balancer, or update a server group.

The resource vocabulary is specific and worth learning before you read any pipeline JSON. Applications contain clusters, clusters contain server groups, and server groups sit behind load balancers and security groups (firewalls). A deployment to a public cloud provider is described as "baked" immutable infrastructure, while container workloads go through provider integrations or the Kubernetes v2 deploy-manifest path. Kayenta is the piece behind automated canary analysis, which is how Spinnaker compares a new version against a baseline before promotion. That is the mechanism that makes the "confidence" claim in the project description concrete rather than marketing.

Two newer directions appear in the README. The plugin framework is meant to add system integrations without updating Spinnaker itself, and managed delivery provides declarative definitions of common infrastructure that you move through environments from a visual interface. The README frames the plugin direction as reducing the threat surface, which is a reasonable reading of a smaller core, but it also means integration behaviour can depend on plugin code you did not write.

## Installing Spinnaker: what the repository does and does not give you

There are no end-user install commands in this repository. The README sends users to the Spinnaker site and its installation guide, and it names two lifecycle managers: the Halyard CLI and the Kubernetes Operator, with the Operator marked Beta. Because the README does not print the Halyard commands, the honest starting point is the installation guide rather than a copied snippet.

For contributors, the path is different and is documented. The README points to the Developer Setup Guide for pulling Spinnaker from source and running it locally against any of the supported cloud providers. The repository root carries the Gradle wrapper, so a source checkout is built with the wrapper rather than a system Gradle install.

```bash
./gradlew build
```

The wrapper script gradlew and the accompanying gradlew.bat are present at the top level, alongside settings.gradle and versions.gradle, which is what you would expect from a multi-module Gradle build. The examples directory holds examples/codelabs/ and examples/solutions/, which are the closest thing here to runnable material; the README's how-to guides, videos and codelabs link is where the walkthroughs live. If you came looking for a docker run line or a Helm chart in this repository, there is none in the README.

## Where Spinnaker is the wrong tool

The operational weight is the first limitation, and it is structural rather than a bug. Spinnaker is a set of independent microservices, so you are running and upgrading several services, not one binary. The README offers two lifecycle managers to cope with that, and one of them, the Kubernetes Operator, is labelled Beta. If your team has no appetite for operating a distributed control plane, the platform will cost more than it returns.

The second limitation is documentation drift. This repository is the issue tracker, and the README explicitly says releases are not managed here and updates are not regularly made to this repository. That means anything you read in these directories reflects the source tree, while the authoritative version and installation information lives on the versions page and the installation guide. A reader who treats this repository as the source of truth for a supported release will be misled.

Third, the cloud integrations are the product's centre of gravity. If your delivery target is a single Kubernetes cluster and nothing else, Spinnaker's multi-cloud abstraction, its load balancer and firewall concepts, and its VM baking path are surface area you pay for and do not use. The README's own framing is about a paved road with guardrails across providers; on one cluster, that road is longer than the trip.

## How Spinnaker differs from Argo CD and Jenkins

The closest comparison for Kubernetes-centric teams is Argo CD. Argo CD is a GitOps controller that reconciles a cluster against a Git repository; the cluster state is the target and Git is the desired state. Spinnaker's pipeline model is imperative by comparison: you define stages, and Orca executes them, with a deploy-manifest stage as one option among VM bakes, load balancer changes and server group updates. The practical difference is that Argo CD answers "is the cluster in sync with Git" while Spinnaker answers "run this release process across these environments, with a canary in front of production." If you only need the first question answered, Spinnaker's stage model is overhead.

Against Jenkins, the difference is the deployment abstraction. Jenkins orchestrates jobs and leaves deployment semantics to scripts and plugins. Spinnaker models the deployment targets themselves: clusters, server groups, load balancers, firewalls. That is why the same pipeline can promote an image across a dev environment and several production environments with a canary stage in between. The trade is that you adopt Spinnaker's vocabulary, and the README's concepts page is required reading rather than optional background.

## Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-21. Recent releases listed for the project are spinnaker-release-2026.3.0 (2026-09-07), spinnaker-release-2026.2.3 (2026-07-30) and spinnaker-release-2026.1.2 (2026-07-30). Note the split: those releases are project releases, and the README states they are not managed in this repository. The versions page on spinnaker.io is where the README sends you for current available versions.

Upgrade cost follows from the microservice layout. You upgrade the set of services, and the lifecycle manager you chose, Halyard or the Kubernetes Operator, is what performs that work. The README does not document rollback, and it does not describe a compatibility matrix between service versions, so pinning to a release from the versions page and reading the release notes is the only guidance the README supports. The plugin framework adds a second upgrade axis: plugins are meant to extend Spinnaker without updating it, which also means plugin compatibility is a thing you track separately.

The licence is Apache-2.0, stated in the repository and in the LICENSE file at the top level. Apache-2.0 is a permissive licence with an explicit patent grant, and it permits commercial use and modification. It also carries notice and attribution obligations when you redistribute. This is a description of the licence text, not legal advice; if you are embedding Spinnaker in a product you ship, have counsel read the LICENSE and any third-party notices in the dependency tree.

## Conclusion

Adopt Spinnaker if you run several clouds or Kubernetes clusters and need pipelines with guardrails, canary analysis and config-as-code. Do not adopt it if you want a single-binary deploy tool or cannot run a set of independent microservices. Before committing, confirm which release from the versions page matches your cloud providers, and check whether Halyard or the Kubernetes Operator fits your existing cluster. Start from the installation guide, not from this repository, because this repository only tracks issues.

## FAQ

### How do I install Spinnaker?

The README directs users to the Spinnaker site and its installation guide, and names the Halyard CLI and the Kubernetes Operator (Beta) as the tools that manage the lifecycle of the microservices. Installation is not performed from the spinnaker/spinnaker repository, which the README says is used only for issue tracking.

### How do I use Spinnaker?

You manage delivery through the GUI or config-as-code, building pipelines that deploy VMs, containers, Kubernetes manifests, load balancers, security groups, server groups, clusters, firewalls and functions. The README points to the how-to guides, videos and codelabs on spinnaker.io for walkthroughs, and to the concepts page for the resource model.

### Is spinnaker/spinnaker the same as the Spinnaker platform?

No. The README states that this repository is only used for issue tracking across the various services, that releases are not managed here, and that the core code for the microservices lives in the other Spinnaker repositories. The directories at the top level, such as clouddriver/, orca/ and deck/, are part of a monorepo layout for development.

### Which cloud providers does Spinnaker support?

The README names AWS, GCP and Kubernetes, and says Clouddriver deploys to all of the major public cloud providers and Kubernetes. It also links to a supported-providers page in the setup documentation for the full list.

### What is the licence for spinnaker/spinnaker?

The repository is licensed under Apache-2.0, with the LICENSE file at the top level. That is a permissive licence, but redistribution carries notice and attribution obligations.

## Sources

- [License: Apache-2.0](https://github.com/spinnaker/spinnaker/blob/main/LICENSE)
- [Project website](http://www.spinnaker.io/)
- [README](https://github.com/spinnaker/spinnaker/blob/main/README.md)
- [Releases](https://github.com/spinnaker/spinnaker/releases)
- [spinnaker/spinnaker on GitHub](https://github.com/spinnaker/spinnaker)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spinnaker-spinnaker