Intermediate

Kubernetes Secrets are not secrets. They’re base64-encoded plain text, stored in etcd, often visible to anyone with cluster access. This is the default, and it’s terrifying. Every cloud provider offers a Key Management Service. AWS has Secrets Manager, Google has Secret Manager, Azure has Key Vault. They work fine — until you need to migrate, or you want to understand what happens to your secrets, or you simply don’t want your most sensitive data in someone else’s infrastructure. ...

You can’t secure what you don’t understand. And with container images, understanding means knowing exactly what’s inside — every package, every library, every potential vulnerability. Most teams treat their container images as black boxes. They pull a base image, add their code, and push it to production. But that base image? It contains hundreds of packages you didn’t explicitly choose. Any of them could have known vulnerabilities. Trivy makes the invisible visible. It’s an open-source vulnerability scanner that tells you exactly what’s in your images and what risks they carry. ...

Version numbers shouldn’t be a decision. They should be a consequence of the changes you made. Semantic versioning (semver) has clear rules: MAJOR: Breaking changes MINOR: New features, backwards compatible PATCH: Bug fixes, backwards compatible But manually deciding “is this a minor or patch?” is error-prone and inconsistent. Let’s automate it. The Core Idea: Conventional Commits The magic ingredient is conventional commits — a standardized commit message format that tells tooling what kind of change you made. ...

I run GitLab self-hosted. Not because it’s trendy, but because I want to own my CI/CD pipeline. No vendor can change pricing, deprecate features, or access my code without my knowledge. This is sovereignty applied to CI/CD. And GitLab makes it practical. Let me show you how to build a complete pipeline: from code commit to running in Kubernetes. Why Self-Hosted GitLab? Before we dive into pipelines, the “why” matters: Data sovereignty: Your code, your builds, your artifacts stay on your infrastructure No usage limits: Unlimited CI minutes, unlimited storage, unlimited users Network locality: Builds run close to your clusters, faster artifact transfers Customization: Configure runners exactly how you need them Air-gap capable: Works in offline environments The trade-off is operational overhead. You maintain GitLab. For me, that’s worth it. ...

“Should I use ArgoCD or Flux?” I’ve been asked this question dozens of times. The honest answer: both are excellent. The real question is which fits your context better. I use ArgoCD. But that’s a choice based on my specific needs, not a universal truth. Let me explain both tools, their philosophies, and help you decide. The Core Philosophy Difference Before comparing features, understand the fundamental difference in approach: ArgoCD is application-centric. You define Applications that point to Git sources. ArgoCD manages them through a central control plane with a UI. ...