Where to Go From Here
No hands-on work in this one. You have a working pipeline behind you — lint, test, matrix builds, artifacts, OIDC-based deploy, a green badge on a README you can point to. This chapter is about what’s deliberately not in that pipeline, and not in this course, so you know what you’re choosing not to reach for rather than not knowing it exists at all.
Self-Hosted Runners at Scale
You’ve seen self-hosted runners as a concept — when you’d want one instead of a GitHub-hosted runner, and the basic tradeoff of control versus maintenance burden. What this course hasn’t covered is running a fleet of them: autoscaling runner pools that spin up and down with queue depth, runner groups that route different jobs to different hardware, or orchestrating self-hosted runners inside Kubernetes with something like Actions Runner Controller. That’s an entirely different operational problem from “I have one machine I trust more than GitHub’s” — it’s closer to running your own small piece of infrastructure that happens to execute CI jobs, with all the monitoring, capacity planning, and security hardening that implies. Worth knowing it exists; not worth building until a single self-hosted runner has actually become a bottleneck for you.
GitOps Tooling
Every deploy job you’ve written in this course pushes changes outward — the workflow runs, and it directly tells AWS “update to this.” GitOps tools like ArgoCD or Flux work the other way around: your desired state lives in a Git repository, and an agent running inside the target cluster continuously reconciles the live environment to match what’s committed, rather than waiting to be told. It’s a genuinely different architecture, not just a different tool doing the same job — the CI/CD pipeline’s role shrinks to “build the artifact and update the Git repository,” and a separate system takes it from there. That shift matters most once you’re running enough services that manually triggered deploys become a coordination problem in their own right, which is well past where this course’s examples sit.
Kubernetes, Beyond the Preview
The EKS chapter earlier in this section was explicitly a conceptual preview — enough to recognize the shape of a Kubernetes deployment step in a workflow, not enough to actually run a cluster with confidence. That was intentional. Kubernetes has its own enormous surface area — pods, services, ingress, config maps, secrets management, networking policy, autoscaling, the works — and folding a real treatment of it into a CI/CD course would have meant doing neither subject justice. A dedicated Kubernetes course is a better home for that material than a few more chapters bolted onto the end of this one, and one is planned. Consider what you’ve seen here a map of where Kubernetes fits into a pipeline, not a substitute for learning Kubernetes itself.
What You Actually Have Now
Set the “not covered” list aside for a moment, because it’s worth being clear about what you did build, across this whole course and not just the capstone: you can take a repository from nothing to a pipeline that lints and tests on every change, runs across a matrix of environments, shares data and artifacts between jobs, deploys to real infrastructure without ever touching a long-lived credential, and fails loudly and specifically when something’s wrong instead of failing silently or not at all. That’s not a toy skill set. It’s the actual job, for a large share of the teams running production software today.
The gaps listed above aren’t gaps in what you learned — they’re the next things, for whenever you actually need them. That’s a good place to stop.