DEV Community: Precious Okpor

Your AI agent skills are probably out of date. Mine were. Here's how I handled it.

Precious Okpor — Tue, 03 Nov 2026 17:55:34 +0000

My old agent skill was one long file and it told every agent I used to run MinIO for local S3. Then the minio/minio repository on GitHub was archived, and the skill went on recommending it. The agents had no way to know. They just did what the file said.

Instructions for AI agents go stale the same way documentation does, except an agent acts on them without asking whether they're still true. So I rebuilt mine as dev-pops-skills, a set of agent skills built around one idea: every fact in them carries the date it was last checked, and something notices when that date gets old.

In this post:

what the skills are
how they stay fresh, which is most of the post
what happened when I measured whether agents actually use the skills (20 out of 31)

Seven small skills instead of one long file

dev-pops-skills is my DevOps defaults written down as seven small skills: Docker, CI/CD, Terraform, security scanning, shell scripting, whole-project setup, and one for writing and auditing the skills themselves. They work in Claude Code, Antigravity and any agent that supports the open Agent Skills format. An agent loads only the skill that matches the request, which matters because my old single file was so long the agents rarely followed it.

Each skill lists the defaults it applies without asking, such as pinned image tags and GitHub OIDC roles in place of stored AWS keys. It lists what needs a yes first: deleting volumes, pushing images, running terraform apply. And it ends with checks whose output the agent has to paste back, so "done" means something I can read.

Every fact has a date on it

The repo notices when something goes stale, then an agent updates it with me.

Every external fact a skill relies on lives in a sources.md file next to it, with the link it came from and the date it was checked. That covers image tags, action versions, install paths and whether a project still exists. Facts are looked up online when they're written, never from the model's memory. The MinIO fix, for example, is one row:

| MinIO's GitHub repo `minio/minio` is archived. | https://github.com/minio/minio | 2026-09-26 |

Four things watch those facts:

Skills expire. Each skill records when it was last fully re-checked, and the validator that runs on every pull request warns once that's more than 90 days ago.
A weekly job checks every pin. Every Monday a GitHub Action confirms that each pinned image tag still exists on Docker Hub, and that each pinned GitHub Action exists, isn't archived and isn't a major version behind. On any drift it opens an issue.
Dependabot opens pull requests for minor and patch updates to base images. It ignores major versions on purpose: moving the templates to a new Node major changes a default, and that needs a decision from me, not an automatic PR.
Real projects report back. When an agent hits a broken or missing template while working in one of my projects, it fixes the project with the smallest change it can, then files a finding in the repo's contributions/ folder with a reproduction. It never names the client, and a CI check fails the build if a name from my private list slips through.

When the weekly issue opens, or findings pile up, I ask an agent to "audit the skills". The skill-authoring skill takes over. It re-checks each fact online and shows me a table of what changed before it edits anything. It applies only the fixes I approve, then bumps the skill's version, adds a changelog entry, updates the dates and opens a pull request. Nothing changes without my approval, and main only accepts a PR that passes five CI checks.

The same loop caught my own tooling: when I moved from Gemini CLI to Antigravity, the install paths changed, and that went in with a source and a date like everything else.

The checks need checking too. I once added two linters set to warn without blocking, so I could fix the existing files first, and they showed a green tick on every run. The logs said both had been failing all along, because GitHub shows a non-blocking failure as a pass. So once in a while I open the logs of the checks themselves instead of trusting the tick.

I checked whether the agents actually use them

A skill only helps if the agent decides to load it, and it decides from a one-paragraph description. So I wrote 31 requests the way I'd phrase them, each paired with the skill that should load, plus four that should load none. A script sends each one to a headless Claude Code that has only these skills and records which skill it loads first.

I didn't want to install the CLI on my laptop for this, so the whole test runs in a throwaway Docker container. The image installs Claude Code from Anthropic's signed apt repository, and the build fails if the signing key's fingerprint doesn't match the one in their docs. I logged in once inside the container, the login lived in a Docker volume, and the repo was mounted read-only so nothing in there could change it:

docker run --rm -v dev-pops-eval-home:/home/eval -v "$PWD:/repo:ro" dev-pops-eval ./scripts/eval-triggers.sh --run

When I was done, I deleted the volume and the image, and my machine was back where it started.

The first full run, on Haiku, got 20 of 31. No request loaded the wrong skill, and all four unrelated ones ("write a React component for a sortable table") correctly loaded nothing. Every miss loaded no skill at all.

Most of those misses were my test's fault. I had asked the agent to "tidy this Makefile" in a project with no Makefile, and it said so, which is the right answer. Each request now runs against a small stand-in project that has the files it mentions. One miss was real: "write a shell script that waits for Postgres" never loaded the scripting skill, and that description is next on my list.

The test also drained my Claude session. I wanted one fact from each run, which skill loaded first, but every request started a full agent session that kept going after it had loaded the skill. It explored the project, read the skill's reference files, and several runs wrote me careful plans for work I would never read. After one full run, I queued two more to measure variance, and eleven prompts into the first of them my five-hour usage window ran dry. A test about whether agents follow instructions had been spending my limit on agents following instructions very thoroughly. Now each run stops the moment a skill loads, gets read-only tools, and is capped at three turns and three cents. By default it runs a sample of nine prompts.

If you want to try it

These are my defaults: Node and TypeScript, Docker Compose, GitHub Actions, and AWS with Terraform. If yours differ, fork the repo and change them; the skill-authoring skill walks an agent through it, and the freshness checks come with it once you enable Actions on your fork (GitHub turns scheduled workflows off on forks).

The repo is poppyszn/dev-pops-skills, MIT licensed. If you found this useful, star it so the next updates show up in your feed, and share the post with whoever on your team keeps the agent instructions. I'd like to hear how other people keep theirs from going stale.

How to Properly Set Up K3s on Your Homelab or Server (2026 Edition)

Precious Okpor — Sat, 13 Jun 2026 12:46:59 +0000

I recently migrated my homelab from Docker + Jenkins to K3S because it was my production infrastructure that runs K3S on AWS, and my homelab should mirror that same flow.

This guide documents exactly how I set up K3S, MetalLB, Traefik, cert-manager with Let's Encrypt, and ArgoCD. All on a single Ubuntu 26.04 VM.

One important thing most 2025 tutorials won't tell you is that ingress-nginx was archived on March 24, 2026, which means no more releases or security patches. The good news is K3S ships Traefik v3 as its default ingress controller, so you get a maintained, production-grade ingress out of the box.

What We're Building

Component	Role
K3s v1.33	Lightweight Kubernetes runtime
MetalLB v0.16.1	LoadBalancer IP assignment for bare metal
Traefik v3	Ingress controller (bundled with K3s)
cert-manager	Automated TLS certificate management
Let's Encrypt (HTTP-01)	Free, trusted certificates
ArgoCD	GitOps continuous delivery
Helm 3	Package manager

Prerequisites

A VM or server running Ubuntu 24.04 and above
A public domain with an A record pointing to your server's public IP (Optional)
Port 80 and 443 open on your server/firewall (required for Let's Encrypt HTTP-01 challenge)
A local IP subnet for MetalLB (e.g. 192.168.1.0/24) — adjust to match your network

Step 1: System Prep

Before installing anything, get the system into the right state.

# Update system
sudo apt update && sudo apt upgrade -y

# Install dependencies
sudo apt install -y curl wget git open-iscsi nfs-common

# Disable swap (Kubernetes requires this)
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# Load required kernel modules
sudo modprobe overlay
sudo modprobe br_netfilter

# Persist kernel modules across reboots
cat <<EOF | sudo tee /etc/modules-load.d/k3s.conf
overlay
br_netfilter
EOF

# Set required sysctl parameters
cat <<EOF | sudo tee /etc/sysctl.d/k3s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system

Step 2: Install K3s

K3s ships with its own built-in ServiceLB (Klipper). We disable it because MetalLB will handle LoadBalancer IP assignment instead. Traefik stays on.

curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=stable sh -s - \
  --disable servicelb \
  --write-kubeconfig-mode 644

# Wait for node to be ready
sudo kubectl wait --for=condition=ready node --all --timeout=120s

# Verify
sudo kubectl get nodes
sudo kubectl get pods -A

Set up kubeconfig for your non-root user:

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
chmod 600 ~/.kube/config

# Persist in shell
echo 'export KUBECONFIG=~/.kube/config' >> ~/.bashrc
source ~/.bashrc

# Confirm it works
kubectl get nodes

You should see your node in Ready state.

Step 3: Install Helm

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Verify
helm version

Step 4: Install MetalLB

On bare metal and VMs, LoadBalancer type services stay stuck in <pending> forever without a load balancer controller. MetalLB fixes this by assigning real IPs from a pool you define.

# Add the MetalLB Helm repo
helm repo add metallb https://metallb.github.io/metallb
helm repo update

# Install
helm install metallb metallb/metallb \
  --namespace metallb-system \
  --create-namespace \
  --wait

# Confirm pods are running
kubectl get pods -n metallb-system

Now configure the IP address pool. Pick a range from your local subnet that is outside your router's DHCP range to avoid conflicts. Adjust 192.168.1.200-192.168.1.220 to match your network:

cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: homelab-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.200-192.168.1.220
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: homelab-l2
  namespace: metallb-system
spec:
  ipAddressPools:
  - homelab-pool
EOF

# Verify
kubectl get ipaddresspool -n metallb-system
kubectl get l2advertisement -n metallb-system

Step 5: Verify Traefik

K3S already installed Traefik v3 during setup. You don't need to install it separately. Just confirm it's running and that MetalLB has assigned it an IP:

# Traefik should be running in kube-system
kubectl get pods -n kube-system | grep traefik

# The service should now have an EXTERNAL-IP from your MetalLB pool
kubectl get svc traefik -n kube-system

You should see an IP in the 192.168.1.200-220 range (or whichever range you set) in the EXTERNAL-IP column. That's MetalLB doing its job.

Step 6: Install cert-manager

cert-manager automates the full lifecycle of TLS certificates — requesting, renewing, and storing them as Kubernetes secrets. We use the HTTP-01 challenge, which means Let's Encrypt will verify your domain by making an HTTP request to your server.

# Add the Jetstack Helm repo
helm repo add jetstack https://charts.jetstack.io
helm repo update

# Install cert-manager with CRDs
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true \
  --wait

# Verify all 3 pods are running: controller, cainjector, webhook
kubectl get pods -n cert-manager

Now create a ClusterIssuer to tell cert-manager how to obtain certificates:

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: your@email.com        # ← replace with your email
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: traefik
EOF

# Verify the issuer is ready
kubectl get clusterissuer letsencrypt-prod

The STATUS should show True under READY.

Step 7: Install ArgoCD

ArgoCD gives you GitOps-based deployments — your cluster state is driven by Git, not manual kubectl apply commands. It's the right pattern for a homelab that mirrors how production should work.

# Add the Argo Helm repo
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

# Install ArgoCD
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer \
  --wait

# Verify pods are running
kubectl get pods -n argocd

# Get the external IP (assigned by MetalLB)
kubectl get svc argocd-server -n argocd

# Get the initial admin password
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d && echo

Access the ArgoCD UI at https://<EXTERNAL-IP> with username admin and the password above. Change the password after the first login.

Step 8: Smoke Test

Deploy a quick test app to confirm the full stack is working end to end:

# Deploy a test nginx pod
kubectl create deployment test-app --image=nginx:alpine

# Expose it as a LoadBalancer service
kubectl expose deployment test-app \
  --port=80 \
  --type=LoadBalancer \
  --name=test-app-svc

# Watch for MetalLB to assign an external IP
kubectl get svc test-app-svc --watch

# Once an IP appears, curl it
curl http://<EXTERNAL-IP>

# Clean up
kubectl delete deployment test-app
kubectl delete svc test-app-svc

If you get an nginx welcome page, everything is wired up correctly.

How to Deploy an App with TLS

Once you deploy a real app, here's what an Ingress resource looks like using Traefik + cert-manager. Just add the annotation, and cert-manager handles the certificate request automatically:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: default
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: traefik
  rules:
  - host: myapp.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-svc
            port:
              number: 80
  tls:
  - hosts:
    - myapp.yourdomain.com
    secretName: myapp-tls

Apply it, and cert-manager will automatically:

Detect the cert-manager.io/cluster-issuer annotation
Create a Certificate resource
Complete the HTTP-01 challenge with Let's Encrypt
Store the issued cert in the myapp-tls secret
Renew it automatically before expiry

What's Next

With this foundation in place, here's what I'd layer on next:

Prometheus + Grafana: observability for the cluster (you already have prom-client experience, this maps directly)
Gitea + Woodpecker CI: lightweight self-hosted CI that replaces Jenkins
Harbor: private container registry running inside the cluster
Longhorn: persistent storage for stateful workloads

The goal is a homelab that serves as a direct rehearsal environment for production.

Summary

System prep → K3s → Helm → MetalLB → Traefik (built-in) → cert-manager → ArgoCD

Every piece here is actively maintained in 2026. No ingress-nginx, no Klipper ServiceLB conflicts, no Jenkins.

If this helped you, drop a comment with what you're running on your homelab. Always curious what other engineers are self-hosting.

How I Containerised 5 Monoliths and Deployed Them to EKS

Precious Okpor — Wed, 08 Apr 2026 15:18:55 +0000

There's a blog post I've always found frustrating: the kind that shows you a perfect Dockerfile, a clean terraform apply, and a screenshot of everything working on the first try. No errors. No wrong turns.

This isn't that post.

I'm a DevOps and Cloud Engineer — in practice, I do DevOps and SRE work: Kubernetes clusters, CI/CD pipelines, AWS infrastructure. I containerise things regularly. But I'd never sat down and worked through five different stacks back to back, treating each one as a distinct challenge.

So I did. Here's what I built, what broke, and what I learned.

The Setup

Five demo apps. Each represents a different monolith archetype. Each has a /health endpoint and one meaningful route — simple enough that the app isn't the distraction. AI helped with creating the apps so I could focus on the DevOps aspects of the project.

App	Stack	What it teaches
`app-node-api`	Node.js + Express	`node_modules`, `.dockerignore` discipline
`app-python-api`	Python + Flask	Slim vs Alpine tradeoffs
`app-nestjs-api`	NestJS (TypeScript)	Three-stage builds: deps → compile → runtime
`app-react-spa`	React + Nginx	Static asset serving, SPA routing
`app-go-service`	Go	Distroless images, static binaries

The full repo: eks-monolith-migration — IaC, Dockerfiles, k8s manifests, CI/CD, all of it.

Phase 1: The Dockerfiles

App 1 — Node.js: The `.dockerignore` Wake-Up Call

Node.js is where most people make the biggest beginner mistake: not using .dockerignore, so Docker sends your entire node_modules as build context on every build.

My .dockerignore:

node_modules
npm-debug.log
.env
.git

My Dockerfile: two-stage. Install deps in stage one, copy only what runs in stage two.

FROM node:24-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:24-alpine AS runtime
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY src/ ./src/
ENV NODE_ENV=production
USER node
EXPOSE 3001
CMD ["node", "src/index.js"]

USER node is easy to forget and almost never done in tutorials. Running as root inside a container means a container escape gives an attacker root on the host. One line fixes it.

Image size: 235MB vs 1.1GB naive.

App 2 — Python/Flask: The Alpine Trap

My first instinct: python:3.12-alpine. Alpine is tiny. Tiny equals good.

The problem: Alpine uses musl libc. Many Python packages with C extensions (numpy, psycopg2, cryptography) either have no Alpine-compatible wheels or compile from source — turning a 30-second build into a 5-minute build. Sometimes it just breaks.

Use python:3.12-slim instead. Debian-based, glibc, pre-compiled wheels.

FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

FROM python:3.12-slim AS runtime
WORKDIR /app
COPY --from=builder /install /usr/local
COPY app.py .
ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1
RUN useradd -m appuser && USER appuser
EXPOSE 3002
CMD ["gunicorn", "--bind", "0.0.0.0:3002", "app:app"]

Two things worth noting:

PYTHONUNBUFFERED=1 — without this, stdout is buffered. Your logs go missing in Kubernetes until the buffer flushes.
gunicorn instead of Flask's dev server — the dev server is single-threaded and literally prints "do not use in production" on startup. Take it at its word.

Image size: 186MB.

App 3 — NestJS: The Three-Stage Build

NestJS is TypeScript. TypeScript compiles to JavaScript. That means your build process is: install deps → compile → run. Three distinct stages.

The trap: carrying your TypeScript compiler, devDependencies, and .ts source files into the production image.

FROM node:24-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:24-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:24-alpine AS runtime
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY --from=build /app/dist ./dist
ENV NODE_ENV=production
USER node
EXPOSE 3003
CMD ["node", "dist/main.js"]

The runtime stage does its own npm ci --only=production. It doesn't copy node_modules from the build stage — those include devDependencies. Fresh install, production only, then just the compiled dist/.

Your TypeScript source never touches the production image. Your test runner isn't there. Your type definitions aren't there.

Image size: 295MB.

App 4 — React + Nginx: The SPA Routing Gotcha

React apps are static files. After npm run build, you have an index.html and some JS bundles. You don't need Node at runtime — you need a web server.

Everyone knows this in theory. Fewer people get the Nginx config right.

The issue: React Router. If a user navigates directly to /about or refreshes on /dashboard, Nginx looks for a file at that path. There isn't one. 404.

The fix is one directive: try_files $uri $uri/ /index.html;

server {
    listen 3004;
    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

FROM node:24-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine AS runtime
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx/nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 3004

Image size: 74.4MB. Smallest of the five — Nginx Alpine is tiny and we're just serving static files.

App 5 — Go: The Satisfying One

Go compiles to a single static binary. No runtime, no interpreter, no VM. Just a binary.

This means you can build in one container and copy the binary into a container that has almost nothing — gcr.io/distroless/static.

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server .

FROM gcr.io/distroless/static-debian12 AS runtime
WORKDIR /app
COPY --from=builder /app/server .
EXPOSE 3005
CMD ["/app/server"]

CGO_ENABLED=0 disables C bindings. GOOS=linux targets Linux explicitly. Together they ensure the binary is truly static and will run in distroless.

No shell in that container. No ls, no curl, no package manager. kubectl exec into it and try to run bash — nothing. This is the point. Near-zero attack surface.

Image size: 8.88MB.

The Before vs. After Table

App	Naive	Optimized
Node.js API	~1.1GB	235MB
Python API	~920MB	186MB
NestJS API	~1.3GB	295MB
React SPA	~400MB	74.4MB
Go Service	~800MB	8.88MB

The Go number is not a typo. I was surprised myself.

Phase 2: Infrastructure with Terraform

Three modules: vpc, eks, ecr.

The VPC creates public subnets for the load balancer, private subnets for worker nodes, and a NAT gateway so private nodes can pull images. Standard layout.

The EKS module provisions a managed node group (t3.medium — the minimum that comfortably runs EKS system pods alongside workloads) and enables OIDC, which is what makes IRSA work.

IRSA — IAM Roles for Service Accounts — is how you give pods AWS permissions without credentials anywhere. An IAM role attaches to a Kubernetes service account. Pods get temporary credentials via OIDC token exchange. No AWS_ACCESS_KEY_ID in your manifests.

The ECR module creates five repos with lifecycle policies:

policy = jsonencode({
  rules = [{
    rulePriority = 1
    description  = "Keep last 10 images"
    selection = {
      tagStatus   = "any"
      countType   = "imageCountMoreThan"
      countNumber = 10
    }
    action = { type = "expire" }
  }]
})

Without lifecycle policies, ECR accumulates images indefinitely. Ten images covers comfortable rollback. More than that is sentiment, not operations.

What broke: The AWS Load Balancer Controller IAM policy. The controller needs a specific IAM policy to provision ALBs. If the IRSA annotation on the controller's service account doesn't match the IAM role ARN exactly, the controller runs but your Ingress resources never get an ADDRESS. I spent an hour on this.

Phase 3: Kubernetes Manifests

Two things I enforced on every deployment that most tutorials skip:

Resource requests and limits:

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Without requests, the scheduler can't place your pod intelligently. Without limits, a misbehaving pod starves everything else on the node.

Minimum two replicas via HPA:

spec:
  minReplicas: 2
  maxReplicas: 5

One replica is a single point of failure. A node rotation takes down your service. Two replicas means you survive a pod restart gracefully.

Phase 4: GitOps with ArgoCD

ArgoCD watches your Git repository for manifest changes and syncs them to the cluster. The cluster pulls its desired state from Git — Git is the source of truth. A rogue kubectl apply directly on the cluster? ArgoCD reverts it on the next sync cycle.

I used a single ApplicationSet instead of five separate Application resources:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: monolith-apps
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - app: app-node-api
          - app: app-python-api
          - app: app-nestjs-api
          - app: app-react-spa
          - app: app-go-service
  template:
    metadata:
      name: '{{app}}'
    spec:
      source:
        path: 'k8s/apps/{{app}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

One manifest. Five apps. Adding a sixth is one line in the elements list.

Seeing all five apps show Synced and Healthy simultaneously in the ArgoCD dashboard was genuinely satisfying.

Phase 5: GitHub Actions CI/CD

Two workflows:

ci-build-push.yml — triggers on push to main. Matrix build across all five apps, tags each image with the git commit SHA, pushes to ECR. Authenticates with AWS via OIDC — no static credentials stored anywhere.

cd-update-manifests.yml — runs after the build. Updates the image tag in k8s/apps/<app>/deployment.yaml, commits back to the repo. ArgoCD detects the drift and syncs within 30 seconds.

- name: Authenticate to AWS
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-ecr
    aws-region: us-east-1

The commit SHA as the image tag matters. latest tells you nothing about what's actually running. A commit SHA is immutable and traceable — you can answer "what code is in production?" with a single kubectl get deployment.

What I'd Do Differently

Separate the manifests repo. When app code and k8s manifests live together, the CI commit that updates image tags triggers another CI run on the same repo. With branch filtering, you avoid a loop, but a dedicated *-k8s repo is cleaner.

Secrets management from the start. I used hardcoded values for the demo. Retrofitting the External Secrets Operator + AWS Secrets Manager later is painful. Wire it up day one.

Distroless everywhere, not just Go. Distroless images exist for Node.js and Python, too. I used Alpine variants for easier debugging — in production, I'd push toward distroless across the board.

Takeaways

Five stacks. Five Dockerfiles. One EKS cluster. One ApplicationSet. One pipeline.

The image optimisation alone — from multi-gigabyte naive images to sub-200MB across the board — is something concrete you can demonstrate. The Go service at 12MB in a distroless container with near-zero attack surface is something worth building just to see it work.

The deeper lesson is GitOps. Self-healing deployments, Git as the source of truth, no manual kubectl apply in production — these are what make Kubernetes manageable at scale, not just powerful on a laptop.

Full repo: github.com/poppyszn/eks-monolith-migration

Questions on any specific part — the OIDC setup, the ApplicationSet pattern, the ALB Controller IAM issue, the Nginx SPA config — drop them in the comments.