The Platform

Systems I build and operate

Cloud infrastructure, Kubernetes platforms, delivery systems, observability and secrets — from provisioning the environment to carrying the pager for what runs in it.

  • Cloud
  • Kubernetes
  • CI/CD
  • Infrastructure
  • Observability
  • Security
  • Reliability

From source to production

  1. 01Code
  2. 02Build
  3. 03Security
  4. 04Registry
  5. 05Deploy
  6. 06Observe
  7. 07Operate
Cloud
AWS · GCP
Compute
EKS · GKE · EC2 · Bare metal
Platform
Kubernetes · Docker · Helm
Delivery
GitLab CI · GitHub Actions · Terraform · Ansible
Security
Vault · IAM · KMS · DevSecOps
Observability
OpenTelemetry · SigNoz · Grafana · Prometheus
Data
PostgreSQL · Redis · MinIO · OpenSearch
Messaging
NATS JetStream · Redis queues · WebSockets
01 / Stack

Infrastructure I have actually worked with

The stack as I have run it — edge, cloud, orchestration, services, state and the control plane holding it together. Select any layer to open its architecture.

The stack, edge to state

Select a layer for its architecture

Edge

InternetCloudflare

Cloud

Orchestration

Services

Node.js · FastAPI

State

Control

02

Kubernetes

The platform, not the command. Workload shape, traffic path, storage, identity and limits — the parts that decide whether a cluster survives its second year.

  1. Ingress

    TLS termination and host routing

  2. Service

    Stable address in front of moving pods

  3. Deployment

    Rollout strategy, probes, resource limits

  4. Pods

    Requests sized from observed usage, not guesses

  5. Config / secrets

    Mounted, never baked into the image

  6. Persistence

    Claims, storage classes, backup path

Worked with

  • Kubernetes
  • Helm
  • Ingress-NGINX
  • HPA
  • ConfigMaps
  • Secrets
  • PVCs
02 / Operating model

How I operate production

Delivery, Kubernetes, secrets, observability and what happens when it breaks — the same system seen from five angles. Select one to open it.

From commit to cluster

One path to production, identical in every environment. Scanning is a gate rather than a report, and the artefact that passed the tests is the one that ships.

The pipeline

  1. Git push

  2. Pipeline

    GitLab CI / GitHub Actions

  3. Test

  4. Security scan

    SAST · secret scanning · Helm lint

  5. Docker build

    Tagged by commit

  6. Registry

    ECR

  7. Deploy

    Helm · approval-gated

  8. Health checks

    Probes before traffic

  9. Observability

    Traces confirm the change

What I hold it to

Repeatable
The same path in every environment
Auditable
Who shipped what, and when
Rollbackable
A previous artefact is always deployable
Automated
No hand-run steps in the release path
Secure
Scanning is a gate, not a report

Worked with

  • GitLab CI
  • GitHub Actions
  • Jenkins
  • Terraform
  • Ansible
  • Helm
  • GitOps
03 / Infrastructure

Infrastructure should be reproducible

Reviewed as a diff, applied from CI, and reconciled back to the file when it drifts — the same lifecycle whether the target is a cloud account or a rack with no internet.

The lifecycle

  1. 01

    Terraform

    Desired state in review

  2. 02

    Plan

    The diff, read before it runs

  3. 03

    Review

    A pull request, not a console click

  4. 04

    Apply

    From CI, with state locked

  5. 05

    Drift

    Detected, not discovered

  6. 06

    Reconcile

    Back to the file, never by hand

Worked with

  • Terraform
  • Ansible
  • Packer
  • Helm
  • Docker
  • Bash
  • Python

Infrastructure is code, not a sequence of console clicks. If an environment cannot be rebuilt from its source, it isn’t finished — which is why one reviewed script stands the whole thing up, whether it lands on a cloud account, bare metal or an air-gapped rack.

04 / Systems Lab

The things I build to reason about systems

Not production. Not a demo reel.Small systems I build to test ideas.

  1. 01

    When a system fails

    Failure → telemetry → mitigation → recovery

  2. 02

    When infrastructure drifts

    Desired state → drift → plan → reconcile

  3. 03

    From requirements to architecture

    Requirements → architecture → validation

Small, working models of the problems I spend my time thinking about.

Enter the lab