Skip to content

Spinnaker Overview

First PublishedByAtif Alam

Spinnaker is an open-source, multi-cloud continuous delivery platform originally developed by Netflix and later open-sourced with Google. It targets teams that release to Kubernetes, VMs, and multiple clouds from one orchestration layer. Platform and SRE teams usually operate it — not a solo-developer install like a single CI runner.

For general CI/CD concepts first, see CI/CD overview and Pipeline fundamentals.

CI vs CD

Section titled “CI vs CD”

Spinnaker separates CI (build/test) from CD (deploy/release). It does not compile your code. It takes artifacts from CI tools (Jenkins, GitHub Actions, GitLab CI, and others) and orchestrates deployment across environments and clouds.

Typical artifacts Spinnaker consumes:

  • Container/OCI images from a registry (most common on Kubernetes)
  • Helm charts or rendered manifests
  • Machine images (AMIs on AWS, GCE images) baked via Rosco and Packer — see AWS compute for VM-style deployments

See Artifact management for tagging, promotion, and registry patterns upstream of Spinnaker.

Push-based CD

Section titled “Push-based CD”

Spinnaker is push-based CD: the Spinnaker control plane orchestrates deployments into your infrastructure using pipeline stages. That differs from pull-based GitOps, where an in-cluster operator reconciles the cluster to Git.

Spinnaker (push)GitOps (pull)
Who deploysSpinnaker services (Orca, Clouddriver)In-cluster operator (Argo CD, Flux)
Source of truthPipeline config + artifact versions (Front50)Git repository
StrengthsMulti-cloud, VM + K8s, manual judgment, canary stagesDrift detection, Git audit trail, lighter ops for K8s-only
Tradeoff~10 microservices to run; cluster/cloud credentials in CD planeLess natural for multi-cloud VM workflows

Compare models in GitOps — Push vs Pull.

Environments and promotion

Section titled “Environments and promotion”

Most Spinnaker setups define pipelines per application that promote the same artifact through dev → staging → production (and across regions). A Manual judgment stage pauses for human approval before prod — a common pattern tied to Release management and separation-of-duties checks in Compliance.

Deployment strategies (rolling, blue/green, canary) are expressed as pipeline stages; see Deployment strategies. Kayenta can automate canary analysis against metrics from Prometheus or other backends.

Platform components

Section titled “Platform components”

Spinnaker is a microservices platform. Each service has a focused role:

ComponentRole
DeckBrowser UI — pipelines, deployments, applications
GateAPI gateway for Deck and the spin CLI
OrcaPipeline orchestration — stages, tasks, retries
ClouddriverCloud abstraction — AWS, GCP, Azure, Kubernetes; only service that talks directly to infrastructure
RoscoImage bakery — Packer AMIs/GCE images for VM deployments
IgorCI integration — triggers from Jenkins, GitHub Actions, and others
EchoEvent bus — cron, webhooks, pub/sub; outbound Slack, PagerDuty, email
Front50Metadata store — pipelines, apps, projects (S3, GCS, or SQL)
FiatAuthorization — OAuth, LDAP, GitHub; who can run which pipeline (Kubernetes RBAC is separate — cluster permissions inside targets)
KayentaAutomated canary analysis — baseline vs canary metrics
HalyardLegacy CLI to install/configure Spinnaker; many teams now use the Spinnaker Operator instead (install runbooks out of scope here)

Spinnaker accounts are cloud or cluster targets (credentials + environment), not end-user login accounts. Fiat handles user identity and permissions.

Architecture flow

Section titled “Architecture flow”

Primary path when CI completes a build:

flowchart TD
  deck[Deck UI]
  gate[Gate API]
  ciTool["CI Jenkins or GHA"]
  igor[Igor]
  echo[Echo]
  orca[Orca]
  clouddriver[Clouddriver]
  infra["Infrastructure K8s or cloud"]
  deck --> gate
  ciTool --> igor --> echo --> orca --> clouddriver --> infra

Echo also routes non-CI triggers (cron schedules, webhooks, pub/sub). Users and automation reach the platform through Deck or Gate (spin CLI).

Key concepts

Section titled “Key concepts”
ConceptDescription
ApplicationLogical grouping of resources and pipelines
PipelineOrdered stages — deploy, canary, wait, webhook, Manual judgment, etc.
ClusterServer groups with the same name across regions
Server groupDeployment unit — e.g. a Kubernetes Deployment or AWS ASG
StageOne pipeline step — Bake, Deploy, Wait, Manual judgment, etc.
Manual judgmentHuman approval gate before continuing (e.g. prod promote)

When to choose Spinnaker

Section titled “When to choose Spinnaker”
NeedSpinnakerArgo CDFlux
Multi-cloud + VMs + K8sStrongK8s-focusedK8s-focused
Rich UI for releasesDeckArgo CD UICLI-first
Git as deploy source of truthPipelines + artifactsStrongStrong
Manual approval stagesNativePossible via sync policies / hooksPossible via automation
Operational footprintHeavy (~10 services)ModerateLighter

Spinnaker is powerful but operationally heavy. Many Kubernetes-only teams choose Argo CD or Flux instead. Spinnaker fits when you need one CD plane across clouds, legacy VM fleets, and advanced pipeline stages (canary + Kayenta, manual judgment, multi-region).

Key Takeaways

Section titled “Key Takeaways”
  • Spinnaker does CD only — CI builds artifacts; Igor connects CI to pipelines.
  • Push-based orchestration vs GitOps pull — pick based on multi-cloud needs and ops capacity.
  • Pipelines promote artifacts through environments with optional Manual judgment before production.
  • Clouddriver is the only component that mutates infrastructure; Orca runs the pipeline graph.
  • Kayenta ties canary stages to metrics; pair with Deployment strategies and SLOs.
  • For K8s-only Git-native delivery, compare GitOps before committing to Spinnaker.
Section titled “Related Links”