Engineering / Infrastructure practice

How I build and operate systems.

My favorite projects cross traditional boundaries. I want to write the application and understand how it is deployed, authenticated, observed, updated, and protected.

A self-hosted infrastructure lab gives me regular practice with deployment, access control, monitoring, maintenance, and recovery.

A simplified path from request to operation.

This diagram shows the general model I use for learning. It does not represent my live network or private topology.

01RequestUsers
02RouteDNS + TLS
03AccessPrivate network
04ControlIdentity / SSO
05RuntimeContainers
06OperateMetrics + storage

Build. Deploy. Secure. Operate.

01

Build

Turn a defined problem into a working application or automation workflow.

  • Python
  • TypeScript
  • Java
  • HTML / CSS
  • REST APIs
  • Automation
  • Git
02

Deploy

Move software beyond a development machine with repeatable infrastructure.

  • Linux
  • Docker
  • Virtual machines
  • Containers
  • Cloud infrastructure
  • Reverse proxies
  • DNS
  • TLS
03

Secure

Design access deliberately and minimize unnecessary exposure.

  • OAuth 2.0
  • OpenID Connect
  • Single sign-on
  • Private networking
  • Access control
  • Identity management
04

Operate

Keep systems understandable after deployment and diagnose what changes over time.

  • Grafana
  • Metrics
  • Dashboards
  • Alerting
  • Logs
  • Troubleshooting
  • Updates
  • Documentation

Personal infrastructure lab.

The environment includes virtualized and containerized workloads, centralized identity concepts, private networking, reverse proxying, DNS management, monitoring, and cloud-connected services.

Running the lab requires ongoing planning, diagnosis, updates, documentation, and recovery work.

Read the case study
Platform
Linux · Proxmox · Docker · Virtual machines · Containers
Network
DNS · TLS · Reverse proxies · Private access · Cloudflare
Identity
Authentik · OAuth 2.0 · OpenID Connect · Access control
Operation
Grafana · Metrics · Alerts · Troubleshooting · Documentation

Make the system understandable.

  1. 01

    Minimize unnecessary exposure.

    Prefer private access, deliberate identity boundaries, and narrowly scoped administration paths.

  2. 02

    Observe before guessing.

    Use logs, metrics, health signals, and dependency checks to narrow a failure before changing configuration.

  3. 03

    Document for the next incident.

    Record architecture and operational decisions so future maintenance starts with context.

  4. 04

    Plan for recovery.

    Include backups, rollback paths, and reproducible deployment in the original system design.