Portfolio projects that get you hired

When you're trying to get your first DevOps job, you're stuck in a classic loop: companies want experience, but you need a job to get experience. Portfolio projects break that loop. They show what you can actually do, in a way a CV line like "familiar with Kubernetes" never can.

Here are fifteen projects that I think demonstrate real skills, grouped by level. You don't need to build all of them. Three or four good ones, done properly and well documented, are worth more than fifteen half-finished repos.

Beginner projects

1. A static website with CI/CD. A personal site or blog built with a static site generator, deployed automatically on every push with GitHub Actions to GitHub Pages, Netlify, or an S3 bucket behind a CDN. Add a custom domain and HTTPS. Shows: Git, CI/CD basics, DNS, TLS.

2. A hardened Linux server. A cloud VM with SSH keys only, a firewall, automatic security updates, fail2ban, a non-root user, and NGINX serving your site. Documented step by step, then automated with a script or Ansible. Shows: Linux, security basics, automation.

3. Containerised app with Docker Compose. A small web app with a database and a cache, running with one docker compose up. Multi-stage Dockerfile, small image, health checks. Shows: containers, networking between services.

4. Uptime and certificate monitor. A Python script (or small Go tool) that checks a list of websites for availability and certificate expiry, runs on a schedule, and sends alerts to Slack, Telegram or email. Shows: scripting, APIs, scheduling, thinking about reliability.

5. Infrastructure for a simple app in Terraform. A VPC, subnets, a VM or container service, a database and a load balancer, all in Terraform, with remote state. Destroy and recreate it in one command. Shows: cloud fundamentals, infrastructure as code.

Intermediate projects

6. Full CI/CD pipeline for a containerised app. Tests, linting, image build, security scan (Trivy), push to a registry, deploy to staging automatically, promote to production with approval. Use OIDC instead of stored cloud keys. Shows: real-world pipeline design and security awareness.

7. Kubernetes deployment with Helm. Your app running on a local cluster (kind or k3s) and on a managed cluster, packaged as a Helm chart with sensible defaults, probes, resource requests and a Gateway API route. Shows: Kubernetes fundamentals.

8. GitOps with Argo CD or Flux. A GitOps repository managing several apps across two environments, with automatic sync, and promotion between environments through pull requests. Shows: modern deployment practices.

9. Observability stack. Prometheus, Grafana and Loki (or a ClickHouse-based tool) monitoring your app. A RED dashboard, two meaningful alerts with runbooks, and OpenTelemetry tracing across two services. Shows: you think beyond "it's deployed".

10. Automated backups and restore test. Scheduled database backups to object storage in another region, and an automated job that restores the latest backup to a test database and verifies the data, with alerts if anything fails. Shows: reliability thinking, which most junior candidates skip.

A project that shows you thought about what happens when things break is worth more than one that only works on a sunny day.

Advanced projects

11. A homelab Kubernetes cluster. Three nodes (mini PCs, Raspberry Pis or VMs), Talos or k3s, Cilium, GitOps, cert-manager, storage, monitoring and backups. Write about what broke and how you fixed it. Shows: deep understanding of the layers managed services hide.

12. Internal developer platform in miniature. A template that creates a new service with repo, pipeline, Helm chart, monitoring and a catalog entry (Backstage or a simple CLI). One command from idea to running service. Shows: platform engineering mindset.

13. Policy and supply chain security. Signed images with Cosign, SBOMs, Kyverno policies that block unsigned images, privileged containers and latest tags, and a pipeline that enforces it all. Shows: security beyond the basics, highly relevant with new regulations.

14. Multi-environment infrastructure with Terraform modules. Reusable modules, separate state per environment, plan on pull request and apply on merge, policy checks, cost estimates with Infracost. Shows: production-grade infrastructure as code.

15. Chaos and resilience testing. Run chaos experiments (Chaos Mesh or LitmusChaos) against your app: kill pods, add latency, fail a dependency. Document hypotheses, results and the fixes you made. Shows: SRE thinking and maturity.

What to include in the README

Your README matters as much as the code. Employers often only read the README. Include:

• What it is and why you built it, in two or three sentences.
• An architecture diagram. Even a simple one.
• How to run it, step by step.
• Design decisions and trade-offs: why this tool and not another.
• What you'd do next with more time.
• What broke and what you learned. This is the most impressive section for many interviewers.

Hosting it cheaply

You don't need a big budget:

• Free tiers on AWS, Azure, Google Cloud and Oracle Cloud.
• Local clusters (kind, k3d, minikube) for most Kubernetes work.
• Cheap VPS providers like Hetzner for always-on projects at a few euros a month.
• Always set budget alerts, and destroy expensive resources with Terraform when you're done. Screenshots and a recorded demo can replace a permanently running environment.

Presenting projects in interviews

• Pick one or two projects to talk about in depth rather than listing everything.
• Tell the story: what problem, what you built, what went wrong, what you learned.
• Be ready to go deep: why this design? What would you change at ten times the scale?
• Link them on your CV and LinkedIn, and consider writing a blog post about each one.

So, where do I start?

Pick a project one level above what you're comfortable with. Finish it, document it well, and write about it. Then build the next one on top of it. A single app that grows through several projects (containerised, deployed, monitored, secured) tells a great story.

My take: show, don't tell. A well-documented project that survived your own chaos test says more than any line on a CV.

— Desly