Spinnaker

Spinnaker is a continuous-delivery platform built at Netflix to solve a problem most CI tools were never designed for: shipping the same release safely across dozens of AWS accounts, several cloud providers, and however many regions sit in between — from one pipeline definition, not one pipeline per target. Netflix open sourced it in November 2015 in partnership with Google, and it grew from there into the default answer for organizations whose deployment surface is genuinely large: not "one app, one cluster," but "one release, forty accounts, three clouds." Two features carry that pitch: a pipeline model built from composable stages instead of shell scripts, and Kayenta, Spinnaker's automated canary analysis engine, which replaces "it looked fine to me" with an actual statistical judgment on whether a canary is safe to promote.

What Spinnaker is and the problem it solves

☺ Like you're 10: Most pipeline tools know how to build code. Spinnaker specializes in the part after that — pushing a finished build out to a lot of places at once, safely.

Spinnaker's origin explains its shape. It evolved out of Asgard, an internal Netflix tool for managing AWS Auto Scaling Groups, at a company that was already running production traffic across a large number of separate AWS accounts for isolation and blast-radius reasons. A tool that only knew how to deploy to "the account" was never going to work there, so Spinnaker was built from the start around an explicit account abstraction — a named set of cloud credentials plus a provider registration — and around pipelines that can target many accounts from a single stage. Netflix and Google jointly open sourced it in 2015; Microsoft, Pivotal, Target, and others joined as contributors soon after, and the project later became a founding member of the Continuous Delivery Foundation (CDF), a Linux Foundation initiative alongside Jenkins and Tekton.

Where a tool like Jenkins or GitHub Actions answers "how do I build and test this change," Spinnaker answers a narrower, later question: "how do I get an already-built artifact safely into every place it needs to run, with a real gate in front of each one." It doesn't compile code, and it isn't a general-purpose CI runner — it consumes an artifact (a container image, a machine image, a Kubernetes manifest) that your CI/CD pipeline already produced, and owns everything from "bake or find that artifact" through "deploy it, verify it, and either promote it everywhere else or roll it back." See deployment strategies for the general vocabulary this page assumes.

Architecture: the microservices behind one pipeline run

☺ Like you're 10: Spinnaker isn't one program — it's about ten small programs, each with one job, that hand a pipeline off to each other in sequence.

Spinnaker ships as roughly ten cooperating microservices rather than one binary, and knowing what each one does is most of what makes the system legible instead of mysterious. Deck is the browser UI. Gate is the API gateway everything else sits behind, and the layer that checks authorization via Fiat. Orca is the orchestration engine — it owns the pipeline's stage graph and actually executes it, stage by stage, tracking which ones are running, waiting, or blocked. Clouddriver is the cloud-provider abstraction layer: it holds every registered account's credentials, caches the live state of every cluster it can see, and is the only service that actually talks to AWS, GCP, Azure, or a Kubernetes API server. Front50 persists pipeline and application configuration, typically to S3, GCS, or Azure Blob Storage. Igor listens for build events from CI tools like Jenkins and translates them into pipeline triggers. Echo handles eventing more broadly — webhooks, cron triggers, pub/sub triggers, and outbound notifications to Slack or email. Rosco is the image bakery, driving Packer under the hood to produce machine images — the direct ancestor of what this course covers as immutable infrastructure & golden images. And Kayenta is the automated canary analysis engine, covered on its own below.

Fiat (authorization), and the storage backends Front50 and Clouddriver's caches depend on, are left off the diagram for space, but the shape holds: a trigger comes in through Gate, Orca drives the stage graph and consults Kayenta when a stage calls for it, and Clouddriver is the only service that ever reaches out to a real cloud account. Everything upstream of Clouddriver is cloud-agnostic; everything the fan-out at the right represents is Clouddriver's actual job.

Applications, pipelines, and stages — the model you build against

☺ Like you're 10: Everything you own lives under an Application; every Application has Pipelines; every Pipeline is a chain of Stages, and a Stage is one real action — bake, deploy, wait for a human, check a canary.

Spinnaker organizes everything a team owns under an Application — a name, a set of permissions, and the pipelines and running infrastructure that belong to it. Within an application, resources follow a resource model borrowed from AWS's Auto Scaling vocabulary and reused across every provider: a Cluster (the logical, ongoing "checkout service in prod") contains one or more Server Groups (a specific deployed version — an ASG on AWS, a ReplicaSet-backed Deployment on the Kubernetes provider), which contain Instances. That's the terminology every screen in Deck and every deploy stage in a pipeline is built around, regardless of which cloud a given cluster actually runs on.

A Pipeline is a directed graph of Stages, each with a type, a set of parameters, and requisiteStageRefIds declaring which stages must finish first — stages without a dependency on each other run in parallel automatically. The common stage types are bake (Rosco builds a machine image via Packer), findImageFromTags (locate an already-built container or machine image by tag), deploy (stand up one or more clusters, across one or more accounts), manualJudgment (pause and wait for a human to click continue, with optional Slack/email notification), kayentaCanary (run automated canary analysis and gate on the score), webhook (call an arbitrary external HTTP endpoint and optionally wait on its result), and script or runJob (execute an arbitrary job, often a Kubernetes Job, for something Spinnaker has no native stage for). Triggers that start a pipeline include a Git push, a CI build finishing (via Igor), a new image landing in a registry, a cron schedule, a pub/sub message, or another pipeline completing.

{
  "name": "Deploy to prod",
  "application": "checkout",
  "stages": [
    {
      "refId": "1",
      "name": "Find image",
      "type": "findImageFromTags",
      "cloudProviderType": "kubernetes",
      "packageName": "checkout"
    },
    {
      "refId": "2",
      "name": "Canary analysis",
      "type": "kayentaCanary",
      "requisiteStageRefIds": ["1"],
      "canaryConfig": {
        "canaryConfigId": "checkout-latency-errors",
        "scoreThresholds": { "marginal": 75, "pass": 95 },
        "lifetimeDuration": "PT30M",
        "metricsAccountName": "prometheus-prod"
      }
    },
    {
      "refId": "3",
      "name": "Manual judgment",
      "type": "manualJudgment",
      "requisiteStageRefIds": ["2"],
      "notifications": [{ "type": "slack", "when": ["manualJudgment"] }]
    },
    {
      "refId": "4",
      "name": "Deploy — 3 accounts, parallel",
      "type": "deploy",
      "requisiteStageRefIds": ["3"],
      "clusters": [
        { "account": "prod-use1", "provider": "aws",        "strategy": "redblack" },
        { "account": "prod-euw1", "provider": "aws",        "strategy": "redblack" },
        { "account": "prod-gke",  "provider": "kubernetes", "strategy": "rollingredblack" }
      ]
    }
  ]
}

Read that stage graph left to right: find the artifact, score a canary against it, stop for a human to look at the score, then — only after both gates pass — deploy to three accounts across two cloud providers in one stage, in parallel. That last stage is the entire pitch of this page in eleven lines of JSON.

Deployment strategies: Highlander, Red/Black, Rolling Red/Black, and native Canary

☺ Like you're 10: Four different answers to "how do I swap the old version for the new one," trading speed of rollback against how gently traffic gets moved.

A deploy stage's strategy field picks how a new server group replaces the old one within a cluster, and this is the concrete implementation of the general vocabulary in deployment strategies. Highlander is the bluntest: deploy the new server group, wait for it to become healthy, then immediately destroy every other server group in the cluster — "there can be only one." Red/Black (Spinnaker's name for blue/green) deploys the new server group alongside the old one, cuts traffic over, and disables — but doesn't destroy — the previous server group, so a rollback is "re-enable the old one and cut traffic back," not a redeploy. Rolling Red/Black shifts traffic between old and new in configurable percentage increments with a pause between each step, trading Red/Black's instant cutover for a gentler, slower one. And a native Canary strategy deploys a canary server group sized at a small fraction of the cluster's capacity, alongside a baseline — this is the strategy that pairs with the kayentaCanary stage below, and it's worth not confusing the deployment strategy (how traffic gets shifted) with the canary analysis stage (how the decision to promote gets made) — you can run a Red/Black deploy strategy and still gate its promotion on a separate kayentaCanary stage, which is exactly what the pipeline JSON above does.

Automated canary analysis with Kayenta

☺ Like you're 10: Kayenta doesn't ask a human "does this look okay" — it runs real statistics comparing the new version against an untouched twin, and only a passing score gets to move on.

A kayentaCanary stage deploys two server groups side by side: a baseline, running the current production build, and a canary, running the candidate, both sized and configured identically and receiving a comparable slice of real traffic. Over an analysis window — PT30M in the pipeline above, ISO-8601 duration syntax for thirty minutes — Kayenta pulls the same set of metrics from both, from whatever monitoring backend the platform has wired in: Prometheus, Datadog, Google Cloud Monitoring, SignalFx, and others are all supported query sources, and this is where monitoring & observability and Spinnaker actually meet. A canary config, referenced by canaryConfigId, names the specific metrics, their direction of badness, and how heavily each one counts:

{
  "name": "checkout-latency-errors",
  "configVersion": "1",
  "metrics": [
    {
      "name": "error-rate",
      "query": { "type": "prometheus", "metricName": "http_requests_total{status=~\"5..\"}" },
      "analysisConfigurations": { "canary": { "direction": "increase" } },
      "groups": ["critical"]
    },
    {
      "name": "p99-latency",
      "query": { "type": "prometheus", "metricName": "http_request_duration_seconds{quantile=\"0.99\"}" },
      "analysisConfigurations": { "canary": { "direction": "increase" } },
      "groups": ["critical"]
    }
  ],
  "judge": { "name": "NetflixACAJudge-v1.0" },
  "classifier": { "groupWeights": { "critical": 100 } }
}

Each metric's two time series — baseline and canary — go through a statistical judge (the default, NetflixACAJudge, uses a Mann-Whitney U test to compare the two distributions rather than a naive average) and come back with a per-metric score. Group scores roll up into an overall score against the scoreThresholds set on the stage — below marginal fails outright, at or above pass succeeds, and the band between is a judgment call the pipeline can route to a human via a following manualJudgment stage. Metrics marked "groups": ["critical"] can be configured so that a single failing critical metric fails the whole canary regardless of what the aggregate score says — the mechanism that stops one metric with a lot of noisy good days from washing out one metric that's genuinely on fire.

The real differentiator: multi-cloud, multi-account fan-out

☺ Like you're 10: Most deploy tools are built assuming there's one cloud account waiting on the other end. Spinnaker is built assuming there might be forty, and treats that as the normal case, not the exception.

This is the specific reason organizations reach for Spinnaker over a single-cloud-native alternative, and it's worth being precise about the mechanism rather than the marketing. An account in Spinnaker is a named registration inside Clouddriver: a set of credentials (an IAM role to assume, a service account key, a kubeconfig context) plus which provider it belongs to. Registering an account is a one-time, per-target operation — after that, any pipeline in any application on that Spinnaker instance can address it by name in a deploy stage's clusters array, exactly as the pipeline JSON above targets prod-use1, prod-euw1, and prod-gke in one stage. Because those cluster entries execute in parallel within Orca's single stage execution, one pipeline run genuinely deploys to three accounts across two cloud providers concurrently — not three separate pipeline runs a human or a script has to trigger and track separately.

Contrast that with a single-cloud-native tool. AWS CodePipeline and CodeDeploy are excellent inside one AWS account, or a small number reached via CodePipeline's cross-account actions — see AWS Developer Tools — but fanning the same release out to twenty AWS accounts means either duplicating pipeline definitions per account or building your own StackSets-style orchestration on top; the platform has no first-class concept of "the same deploy, many accounts." A GitOps reconciler like Argo CD is genuinely multi-cluster, but its multiplicity is Kubernetes clusters specifically — it has no native concept of an AWS Auto Scaling Group, a Cloud Foundry org, or Netflix's own Titus container runtime, all of which Spinnaker treats as equally first-class providers alongside Kubernetes. Spinnaker's account abstraction is the thing that makes "one release, many non-uniform targets" a native pipeline concept instead of a scripting problem layered on top of a single-target tool.

Day-to-day: installing, configuring, and triggering pipelines

☺ Like you're 10: One tool configures Spinnaker itself, a second tool talks to a running Spinnaker to manage pipelines, and a plain HTTP call can kick one off from anywhere.

Halyard (the hal CLI) was the original tool for configuring and deploying Spinnaker's own microservices — registering cloud accounts, choosing a persistence backend, and rendering the whole stack. It still shows up in a lot of existing documentation and installs:

# Halyard — configures Spinnaker itself, not your applications
$ hal config provider aws account add prod-use1 --account-id 111111111111 --assume-role role/spinnakerManaged
$ hal config provider aws account add prod-euw1 --account-id 222222222222 --assume-role role/spinnakerManaged
$ hal config provider kubernetes account add prod-gke --context gke_acme_prod-gke_us-central1_prod
$ hal config storage s3 edit --bucket spinnaker-config-acme --region us-east-1
$ hal deploy apply                                   # renders and applies Spinnaker's own microservices

Halyard's own maintenance has slowed considerably, and most current guidance points teams toward the Spinnaker Operator — a Kubernetes operator that manages a SpinnakerService custom resource instead — for installing and upgrading Spinnaker itself; check spinnaker.io's current installation guide before committing to either path, since this has shifted more than once. Whichever installer stands the platform up, day-to-day interaction with a running Spinnaker goes through the official spin CLI or the Gate API directly:

# spin — the CLI for managing applications and pipelines on a running Spinnaker
$ spin application list
$ spin application get checkout
$ spin pipeline save -f checkout-deploy.json          # create or update a pipeline from JSON
$ spin pipeline execute -a checkout -n "Deploy to prod" --parameter imageTag=1.4.4
$ spin pipeline get -a checkout -n "Deploy to prod" | jq '.stages[].type'

# Gate's REST API — the same thing, called directly, e.g. from another CI system
$ curl -X POST https://spinnaker.acme.internal/gate/pipelines/v2/checkout/Deploy%20to%20prod \
    -H "Content-Type: application/json" \
    -d '{"parameters": {"imageTag": "1.4.4"}}'

Most real setups wire a CI pipeline — Jenkins, GitHub Actions, GitLab CI/CD — to call that Gate endpoint as its final step, handing off from "build and test" to "deploy and verify" at exactly the boundary this page opened with. A newer, more declarative option called Managed Delivery lets a team commit a delivery-config.yml describing environments and promotion constraints directly to the application's Git repo instead of authoring pipeline JSON by hand; it's a meaningfully different, GitOps-flavored model, and — being newer — it's less universally battle-tested than the classic stage-graph pipeline, so read the current docs closely before betting a first production rollout on it.

Gotchas and failure modes

☺ Like you're 10: The tool that deploys everything else is, itself, about ten separate programs someone has to keep running — and a couple of its behaviors surprise people the first time.

The most consistently underestimated cost of Spinnaker is Spinnaker itself: roughly ten microservices, each with its own scaling characteristics, its own persistence dependency, and its own upgrade cadence, is a genuine distributed system to operate — the tool responsible for safe deploys needs safe deploys of its own. Teams below a certain scale often find the operational overhead outweighs the benefit until the multi-account or multi-cloud need is real, not hypothetical; see the comparison table below for when that threshold is actually crossed.

Two Spinnaker-specific behaviors bite in production regularly. First, Red/Black "disables" rather than deletes — that's the whole point, since it's what makes rollback instant — but disabled server groups still consume capacity and cost until something cleans them up; most platforms configure Spinnaker's server-group TTL or a separate cleanup job rather than relying on someone remembering to prune manually. Second, the Kubernetes v2 provider applies manifests directly rather than routing everything through the AWS-flavored server-group abstraction — which means a deploy (Manifest) stage's failure modes look more like a raw Kubernetes rollout problem (a stuck ReplicaSet, a failed readiness probe) than a classic ASG one, and debugging it means reading Kubernetes events, not Clouddriver's AWS caching layer.

Finally, a fair question before adopting Spinnaker for new infrastructure in 2026: project governance and commit velocity have visibly cooled since Netflix scaled back its own day-to-day involvement, and more than one commercial vendor built around Spinnaker has since redirected part of its own roadmap elsewhere. That doesn't make Spinnaker a wrong choice — the multi-account, multi-cloud pipeline model described on this page has no exact substitute — but it's worth checking the Continuous Delivery Foundation's current Spinnaker project page and recent release history yourself rather than assuming the project's 2019 momentum still applies unchanged.

Spinnaker vs. the alternatives

☺ Like you're 10: Other tools also move a release from build to production — they just draw the line between "simple" and "handles forty accounts at once" in different places.

The practical rule: reach for Spinnaker when the deploy target is genuinely plural and heterogeneous — several AWS accounts, more than one cloud, or both — and the operational cost of running it is smaller than the cost of hand-rolling that fan-out somewhere else. Reach for a lighter, platform-native tool when the target is one cloud, or one Kubernetes footprint, because that's exactly the case those tools were built for and Spinnaker's extra machinery buys nothing. Spinnaker itself isn't a named domain on the AWS DevOps Engineer – Professional (DOP-C02) exam covered on this course's certifications page, but the deployment-strategy and canary-analysis concepts it implements are — verify the current exam guide's exact wording before assuming any one tool name will appear. See feature flags & progressive delivery for how canary analysis fits alongside flag-based rollouts, and release trains & change management for how a multi-account promotion pipeline like the one on this page fits into a broader release process.