About

Hey, I'm Steven.

I'm an infrastructure and security engineer who believes the way you build things says something about who you are. By day, I work across Microsoft 365, identity management, and security governance at a global financial services firm. By night, I run a Kubernetes homelab and write about the decisions behind it here.

What NaviauxLab Is About

This site documents real infrastructure engineering: the decisions, failures, tradeoffs, and operating habits behind systems that have to keep working after the initial build is done.

When I write about resource limits, identity, network policy, observability, or recovery, it is because those problems showed up in a real environment. The useful part is rarely the tool by itself. It is the judgment around when to add complexity, when to simplify, and what evidence tells you a system is behaving.

The Architect vs. The Slumlord

There is a framework I keep coming back to: The Architect vs. The Slumlord.

The Slumlord ships fast, cuts corners, and deals with consequences later, or never. The Architect builds with intention: pinned versions instead of :latest, network policies on every namespace, resource limits on every container, and GitOps instead of kubectl apply at 2 AM.

Neither mode is purely right. Speed matters. Perfection is the enemy of shipped. This site is about being intentional: choosing where to invest the extra effort and being honest about where you did not.

What I Cover

• Kubernetes and GitOps - declarative infrastructure, cluster operations, and release discipline
• Security and identity - Microsoft 365 governance, SSO, secrets handling, and default-deny design
• Observability - metrics, logs, alerts, and dashboards that answer operational questions
• Self-hosting - small systems that are backed up, monitored, and understandable
• Infrastructure philosophy - why the decision matters more than the implementation detail

The Operating Model

My homelab is a small Kubernetes environment managed as code. I use it to test patterns I care about: immutable nodes, encrypted secrets, declarative deployments, ingress policy, backups, and failure recovery.

The point is not the exact hardware or a public list of every running service. The point is building systems that can be explained, rebuilt, monitored, and improved without relying on memory or luck.

Connect

The best way to follow along is to subscribe for blog updates. If you want to talk infrastructure, security, Microsoft 365, Kubernetes operations, or self-hosted systems, LinkedIn is the best place to start a conversation.

• Subscribe for blog updates
• Connect on LinkedIn
• Read the public code on GitHub

If something I wrote helped you, or if you think I got something wrong, I would like to hear about it.