Spinnaker: thirteen services in one Gradle build, and two lifecycle tools

One repository, thirteen services, one Gradle build that touches all of them

Everything lives in one repository, and the service list is the first thing to read. The monorepo holds the source for every core microservice: clouddriver, deck, echo, fiat, front50, gate, igor, kayenta, keel, kork, orca, rosco and spin, and it is also where builds, releases and issue tracking happen. The build is one Gradle setup: build.gradle at the root next to settings.gradle, gradle.properties, versions.gradle, kotlin.gradle, wiremock-substitution.gradle, gradlew and gradlew.bat, with spinnaker-gradle-project and spinnaker-kustomize directories alongside the wrapper. MONOREPO.md is where the structure and the build process are described, and the primary language of the tree is Java with Kotlin carried in its own build file. The consequence for anyone contributing is that no service is isolated by repository.

Halyard or the Operator drives the install, and the Operator is marked Beta

Spinnaker is not a binary you download and run. It is a set of microservices whose lifecycle is managed by a tool outside this repository, and the README names two candidates. The Halyard CLI manages the lifecycle of the other services, and a Kubernetes Operator, labelled Beta, is offered as the alternative. Both live in separate projects, which means the compatibility between a given Operator or Halyard version and these thirteen services is answered there, not here. The consequence for an adopter is that you choose a lifecycle tool before you install anything, and the README does not say what the Beta Operator does not yet cover, nor what happens to an existing Halyard managed install if you move between them. Treat that as an open question to settle in the tool's own repository and issue tracker rather than assuming parity.

Managed delivery adds a second vocabulary alongside pipelines

Managed delivery is the newer featureset named here, and it sits next to the pipeline model rather than replacing it. Users declare requirements using prebuilt definitions of common infrastructure and other requirements, then move those changes through environments through a visual interface. The older model is still what the rest of the project describes: pipelines that promote a change from a git commit into a dev environment and onward through multiple production environments, with several ways to initiate a deployment. The consequence is two vocabularies for the same act of shipping. A team that standardises on managed delivery gets declarative requirements and a visual promotion path, bounded by whatever has a prebuilt definition, and the README does not enumerate which resources ship with one. A team on pipelines keeps the full stage model. Choosing per application is the honest answer, and running both inside one service doubles the concepts your operators have to hold.

Plugins extend Spinnaker without an upgrade, and nothing declares compatibility

The extension story is the plugin framework, which exists so system integrations can be added without updating Spinnaker itself. The project frames that as a way to leverage a wider software delivery toolchain while moving towards a smaller threat surface. Beyond that sentence the README adds nothing: no plugin listing, no compatibility matrix, no statement of which integrations are plugins and which are services, and no version range a plugin declares about the core it needs. If an integration has to survive an upgrade, track the core version yourself and treat plugin updates as code changes with their own tests.

Baked VMs, Kubernetes manifests and native cloud resources are not one abstraction

What Spinnaker manages is an application, and what sits inside an application is not a single kind of thing. The resources named are virtual machine deployments baked as immutable infrastructure, container deployments to a cloud, container deployments to Kubernetes, load balancers, security groups, server groups, clusters, firewalls and functions. That list spans at least three provisioning models: bake an image, apply a manifest to a cluster, and create native cloud resources that other teams and tools also create. The consequence for a team moving from virtual machines to Kubernetes is that the migration is not a change of deploy stage. Model your applications by which of these resource sets they actually use, because a single pipeline template covering all of them ends up the hardest thing in your own configuration.

Canary analysis is the stated safety net, and the README never names its service

Confidence in this platform rests on automated canary analysis, and the README names that capability without naming the service behind it. Of the thirteen services, only one gets a job description in the README: Clouddriver is what deploys to the major public cloud providers and to Kubernetes. The rest are listed and left undefined, so the data flow between them lives in the Concepts topic and in the code rather than in this repository. The consequence for an adopter is that a canary needs a metric source feeding it, and nothing here tells you what a run does when that source is missing or unreachable. Verify that behaviour in your own environment before you let automated promotion make the decision for you, and read the Concepts documentation rather than inferring the architecture from the directory names.

Version numbers are patch trains, and 2026.3.0 is older than 2026.2.4

The version numbers are train lines, not a ladder, and the recent release list shows it directly. Three tags exist: spinnaker-release-2026.4.0 published on 2026-10-29, spinnaker-release-2026.2.5 on 2026-10-23 and spinnaker-release-2026.3.2 on 2026-10-23. Patch releases for two different lines were published on the same day, so version numbers do not form a single ladder, and taking the highest patch number is not the same as taking the newest line. The consequence is that upgrade policy has to name a line rather than a version: decide which of the 2026.2, 2026.3 or 2026.4 lines you follow, then take patches inside it. Two of those three tags landed on the same day, which is what a batch of patch cuts looks like. RELEASE.md at the repository root is the file to read for how that happens, the versions page linked from the README is the other place, and the tree itself was pushed to on 2026-11-01.

The repository contains no install path, only routes to one

Nothing in this tree installs Spinnaker. The root file is README.adoc, written in AsciiDoc with a doctype declaration, and its work is routing you elsewhere: the main site for installation, a Concepts topic for the design, a guides section with videos and codelabs, a Slack workspace for questions, a governance repository for how the project is run, and a Developer Setup Guide for running the source locally against a supported cloud provider. What the repository holds is the material for people changing it: MONOREPO.md, RELEASE.md, CODE_STYLE.md, AGENTS.md, CLAUDE.md, a .mergify.yml for merge automation, examples/codelabs and examples/solutions, and a plans directory. The consequence is that operational knowledge is a website dependency. If you need to know how to stand Spinnaker up, the answer is not in the tree, and pinning a version means also pinning what the documentation said when that version shipped.

Editorial conclusion

Spinnaker fits organisations running several clouds or Kubernetes at scale, with people who can absorb thirteen services and one Gradle monorepo. It does not fit a single cloud team wanting a light deploy tool, because the repository carries no install path of its own and one of the two lifecycle tools is marked Beta. Before adopting, read MONOREPO.md and RELEASE.md, pick a version line instead of the newest tag, and decide whether Halyard or the Operator drives your install.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. spinnaker/spinnaker on GitHub