EKS GitOps Factory
You already deployed EKS
Amazon Elastic Kubernetes Service — the managed Kubernetes control plane this factory targets. and you manage apps with Argo CD
GitOps continuous delivery controller that syncs Kubernetes manifests from Git into the cluster. on a GitOps
Operate the cluster from Git as the source of truth — changes land as PRs, then sync, not as ad-hoc kubectl. path. The next job is migrating what you already run somewhere else — Podman
Daemonless container engine — another common source runtime this factory helps migrate from., Docker Compose, ECS
Amazon Elastic Container Service — one of the existing runtimes apps may migrate from onto EKS., or other hosts — onto that same cluster and the same repo shape. At 100 apps and roughly 450 engineer-hours per migration wave, configuration drift becomes the default outcome unless the repo carries one reusable contract.
Why the factory exists
Section titled “Why the factory exists”At a few apps, a careful engineer can do that by hand. At hundreds of containers, across multiple teams, it does not scale. Each person brings a slightly different layout, naming, and policy choices. Reviews get slow, and the drift is hard to see because nobody wrote down one way to do it.
Prompting a model harder does not fix it. A bare model invents a different tree for each app, and given a shell it will apply that tree straight to a live cluster.
So the decisions move into the repository instead of into the prompt. Steering
Always-on and conditional markdown in `.kiro/steering/` that encodes naming, overlays, clusters, and archetypes a reviewer would otherwise carry in their head. carries the knowledge a reviewer would otherwise supply from memory, a skill
Ordered procedure under `.kiro/skills/` (for example `add-app`) so the agent follows one sequence instead of inventing a tree each time. fixes the procedure into an ordered sequence, hooks
Hard gates in `.kiro/hooks/` that refuse forbidden paths, bad PDBs, and live cluster apply from chat. refuse what must not happen no matter how the request is phrased, and an agent
Kiro agent bundle (for example `eks-migration`) that loads steering and skills so one thin prompt activates the contract. bundles the three so one thin prompt activates all of it.
skills generate → hooks enforce → humans approve. This page claims none of the three clauses yet — it states the shape of the argument the rest of the site walks, and each page that follows takes up the clause it can actually prove.
Three labs, one argument
Section titled “Three labs, one argument”Each lab rests on the conclusion of the one before it, so the order is the point.
- First — Lab A proves policy passes before any cluster exists. Prove policy offline (Lab A)
- Second — Lab B proves the configuration in the repository is what makes a thin prompt safe. What makes prompts safe (Lab B)
- Third — Lab C proves a thin prompt produces a compliant dual-overlay
Factory default: every app gets both a dev and a prod overlay so promotion stays the same shape. app. Onboard an app (Lab C)
What the factory does not remove is the part that needs judgement: understanding the workload, shrinking IAM
AWS Identity and Access Management — you still shrink roles to least privilege; the factory does not invent that judgement. to what the app actually calls, getting DNS
Domain Name System — app hostnames and private zones stay a human cutover concern. and TLS
Transport Layer Security — certificates and HTTPS termination stay outside the factory draft. right, and carrying cutover risk. This site is documentation only — you clone the source factory
jajera/kiro-eks-argocd-migration — the upstream factory repo with Terraform, policy, `.kiro/` contract, and runnable labs; this site is docs only. (jajera/kiro-eks-argocd-migration) and run every command there, and a human still merges the result.
Next: Why manual onboarding breaks settles why the multi-team hand path fails and what the factory refuses to take off your hands.