Projects

What I've Been Building

These are selected systems and patterns from my professional infrastructure work and personal homelab. The public notes focus on architecture, tradeoffs, and operating lessons rather than publishing a map of live services.

Kubernetes Homelab: GitOps Operating Model

Problem: I wanted a small platform that could run real workloads without turning into a pile of one-off shell history and undocumented exceptions.

Architecture: The cluster is managed declaratively. Node configuration, workloads, ingress, storage, secrets, and monitoring are all represented as code and reviewed through Git. The operating model favors immutable nodes, encrypted secrets, default-deny network policy, and repeatable deployment paths.

Tradeoff: GitOps adds structure and ceremony. That is worth it when the alternative is drift: configuration that exists only because someone typed the right command once.

Result: The environment is small enough to understand and disciplined enough to recover. Changes have history, workloads have limits, and the cluster has a clear path back from mistakes.

Personal Operations Dashboard

Problem: Personal data is easy to collect and hard to make useful. Dashboards often show what happened without helping decide what to do next.

Architecture: I built a private dashboard around server-rendered workflows, structured data, and agent-assisted summaries. The system pulls signals into one place, keeps the interface fast, and treats forecasts and recommendations as prompts for judgment rather than automatic truth.

Tradeoff: More integration means more maintenance. The boundary I care about is whether a connection creates a decision I can actually use.

Result: The dashboard became a working personal operating picture instead of a novelty: habits, priorities, trends, and review loops in one place.

Observability and Recovery

Problem: A self-hosted environment is only useful if failures are visible and recovery is practiced. Silent failure is worse than downtime because it teaches false confidence.

Architecture: Metrics, logs, alerts, backup jobs, and external health checks are treated as part of the platform, not optional extras. Alerts route through simple channels, dashboards answer operational questions, and backups are designed around restore paths rather than archive aesthetics.

Tradeoff: Observability can become its own garden of dashboards. I keep the focus on questions that change behavior: what is broken, what is saturating, what changed, and what needs human attention.

Result: The platform is easier to reason about under stress because the signals are already there before something fails.

Knowledge Management System

Problem: Infrastructure work produces decisions faster than memory can retain them. Without a written system, context gets lost and old mistakes look new again.

Architecture: I maintain a structured knowledge base with notes, decision records, study material, project context, and book syntheses. The useful unit is not the note; it is the retrieval path back to why a decision was made.

Tradeoff: Too much structure makes note-taking brittle. Too little structure turns it into a junk drawer. I bias toward lightweight metadata, links, and repeatable review paths.

Result: The knowledge base acts as long-term memory for projects and learning, especially when work stretches across weeks or months.

Patterns I Keep Coming Back To

• Make the desired state explicit. If the system matters, its configuration should not live only in an operator's memory.
• Design for recovery before polish. A clean dashboard does not matter if restore paths are untested.
• Use constraints as architecture input. Small environments force better choices when you let the limits be real.
• Keep security boring. Least privilege, encrypted secrets, identity boundaries, and default-deny policy beat cleverness.

Talk Shop

If you are thinking through platform reliability, Microsoft 365 security, Kubernetes operations, or self-hosting tradeoffs, start here.