Building an Interlinked DevOps Project Ecosystem

Most DevOps portfolios I review have the same problem: ten repos that each do one small thing, none of which talk to each other. A lone Terraform file here, a Docker Compose there, a Kubernetes manifest with no context. They prove you can follow a tutorial. They don't prove you can build a platform.

So I rebuilt my open-source work as an interlinked ecosystem: six projects that compose into something resembling a real enterprise platform. This post explains the architecture and why interlinking is the thing that actually signals seniority.

The six projects

Project	Layer	What it owns
terraform-aws-reference-architecture	Infrastructure	VPCs, compute, databases, state
gitops-kubernetes-platform	Delivery	ArgoCD app-of-apps, Helm
cicd-pipeline-templates	Build	Reusable pipelines, image signing
observability-stack	Operate	Metrics, logs, traces, alerts
vault-on-kubernetes	Secure	Secrets, HA Vault, K8s auth
devsecops-starter-kit	Govern	Scanning, pre-commit, policy

How they compose

The point isn't six repos. It's that they slot together into one delivery lifecycle:

  Terraform           CI/CD              GitOps             Observability
  provisions   ──►    builds &     ──►   deploys to   ──►   watches the
  the cluster         signs images       the cluster        running system
      │                   │                  │                   │
      └──────── DevSecOps scans everything along the way ────────┘
      └──────── Vault provides secrets to the workloads ─────────┘

A change flows like this:

1. Infrastructure is provisioned by the Terraform reference architecture (VPC, EKS, RDS).
2. CI/CD templates build the app, scan it, sign the image with cosign, and push it.
3. GitOps (ArgoCD app-of-apps) notices the new image reference in Git and reconciles the cluster to match.
4. Vault injects the secrets the workload needs at runtime, nothing hardcoded.
5. Observability picks up the new pods automatically, with dashboards and alerts already defined as code.
6. DevSecOps scanning runs at every commit and in every pipeline, so nothing insecure reaches main.

That's the loop a real platform team runs. Showing the loop is far more convincing than showing six isolated parts.

Why interlinking beats polish

A recruiter or staff engineer skimming your GitHub is asking one question: can this person reason about systems, or just components? Interlinked projects answer it instantly:

• Single repos say: "I learned a tool."
• An ecosystem says: "I understand how the tools fit, where the seams are, and what breaks when they don't."

The second is the actual job. Production isn't a Terraform exam; it's the messy boundary between IaC, delivery, secrets, and observability, and whether the whole thing degrades gracefully when one part misbehaves.

The principles I held to

A few rules kept the ecosystem coherent instead of sprawling:

1. Every repo runs from its README. If a reviewer can't docker compose up or terraform validate from the instructions, the repo is a liability, not an asset.
2. No secrets, ever. Sensitive values are env-driven, gitignored, and scanned for. A leaked key in a portfolio repo is worse than no repo.
3. CI on everything. Green check marks aren't decoration, they prove the code is valid on a clean machine, not just mine.
4. Honest framing. Reference implementations are labeled as such. They demonstrate skill; they don't pretend to be a specific client's production system.
5. Cross-links both ways. Each repo points to the ones it composes with, and to the article explaining it. Context is the product.

What I'd tell my earlier self

Don't optimize for more repos. Optimize for repos that reference each other and add up to a story. One coherent platform beats twenty orphaned demos every time.

If you're building your own DevOps portfolio, pick a lifecycle, provision, build, deliver, operate, secure, and build one small, runnable, honest project for each layer. Then wire them together. That ecosystem is the thing that gets you hired.

---

Want to see it end to end? Start with the Terraform reference architecture, then follow the links through GitOps, CI/CD, and observability.