$1

GillPad Engineering Platform

This environment is where I build, break, secure, automate, and operate infrastructure outside of production systems. The platform is developed in stages: establish a working capability, validate its behavior, document the result, then improve the architecture without pretending unfinished work is complete.

View Architecture View Projects GitHub

PURPOSE

A platform for practical engineering work.

The GillPad platform is a personal engineering environment designed to support infrastructure, security, automation, Kubernetes, isolated security ranges, and operational testing. The goal is not to accumulate tools. The goal is to build systems that work, understand why they work, document the decisions behind them, and improve them without destabilizing the rest of the environment.

Build

Deploy infrastructure and services in a controlled environment where architecture decisions can be tested before they are trusted.

Operate

Treat services as systems that must survive change, failure, maintenance, and recovery rather than one-time installation tasks.

Secure

Apply identity-aware access, firewall boundaries, isolated networks, least privilege, and controlled remote administration.

Document

Keep current-state records, engineering journals, case studies, runbooks, and architecture decisions so the environment does not depend on memory.

CURRENT ARCHITECTURE

Single-host today, designed to evolve.

The current platform runs on a Dell Precision 5820 using Proxmox VE. OPNsense provides routing and firewalling for the internal lab network, Cloudflare brokers external identity-aware access, and Guacamole provides controlled SSH and RDP access to selected systems.

REMOTE ACCESS PLANE

Remote User Internet
→
Cloudflare Access Identity + policy evaluation
→
Outbound Tunnel No direct inbound service exposure
→
Guacamole Controlled SSH / RDP

Tailscale provides an alternate administrative access path for troubleshooting and recovery.

INFRASTRUCTURE PLANE

Home Gateway Physical network edge
→
Home / Management Network Physical connectivity
Proxmox VE Compute + virtualization
↓
Local Platform Services Virtual machines + local storage
OPNsense Firewall + routing
↓
Internal Lab Network Firewall-routed trust zone

WORKLOAD PLANE

Kubernetes 1 control plane · 2 workers

Three logical nodes currently share one physical Proxmox failure domain.

Core Services DNS · Windows baseline · management services
Isolated Security Range GOAD and controlled security testing

Separate internal-only virtual trust zone.

Physical Platform

  • Dell Precision 5820
  • Proxmox VE
  • 2 TB NVMe
  • Local LVM-thin VM storage
  • Additional physical Ethernet interfaces available for segmentation

Network Roles

  • Physical home / management network
  • OPNsense-routed internal lab network
  • Physical uplink / management bridge
  • Internal virtual bridge
  • Isolated GOAD security range

RUNNING WORKLOADS

Core services stay active, heavier labs are powered as needed.

Core Infrastructure

  • OPNsense
  • Pi-hole
  • Windows 11 baseline VM

Kubernetes

  • One control-plane VM
  • Two worker VMs

The Kubernetes environment is logically multi-node but currently shares one physical Proxmox failure domain.

Security Lab

Kali, GOAD management, and other security-focused systems are powered on when required instead of consuming resources continuously.

Management

A dedicated management workstation exists as part of the developing administration path and is being refined alongside Guacamole, remote-access persistence, and firewall policy.

IDENTITY & REMOTE ACCESS

External access is identity-first.

Remote administration is designed around authenticated access rather than exposing internal services directly to the internet. Cloudflare Access evaluates identity before approved traffic reaches the environment, while Guacamole acts as a controlled remote administration layer for selected SSH and RDP destinations.

Cloudflare

  • Cloudflare Tunnel
  • Cloudflare Access
  • Reusable identity-based access policies
  • Federated authentication

Guacamole

  • Controlled SSH access
  • Controlled RDP access
  • Jump-host administration workflow
  • Per-user access model in development

Alternate Access

Tailscale provides a secondary remote-access path and reduces dependence on a single access chain during troubleshooting.

Security Direction

The next network phase moves from primarily logical isolation toward clearer firewall-enforced and physical trust boundaries using additional Ethernet interfaces available on the host.

STORAGE & FAILURE DOMAINS

Capacity is healthy. Resilience is not finished.

The platform currently uses a single NVMe device for Proxmox system and VM storage. Capacity remains sufficient for current workloads, but the host and local VM disks share the same storage failure domain.

Current State

  • Single local NVMe device
  • Proxmox LVM-thin storage
  • Significant local capacity remains available
  • No redundant local storage

Deliberate Gaps

  • No dedicated home-lab backup server
  • No Proxmox HA cluster
  • No distributed storage
  • Distributed storage deferred until additional hardware exists

OPERATIONS

The platform is becoming something that has to be operated.

As more services and users are added, the focus is shifting from installation toward repeatability, recovery, access control, and documentation.

Current Practices

  • Current-state documentation
  • Engineering journal entries
  • Architecture and case-study documentation
  • Snapshot-driven testing where appropriate
  • Controlled remote administration

Operational Work in Progress

  • Guacamole persistence validation
  • Tunnel recovery procedures
  • User onboarding and offboarding
  • Management workstation refinement
  • Firewall policy cleanup

KNOWN GAPS

What the platform does not claim to be.

Availability

  • Single physical Proxmox host
  • No physical Proxmox quorum
  • No HA failover

Storage

  • Single NVMe storage failure domain
  • No dedicated home-lab backup server
  • No Ceph or other distributed storage

Networking

  • Physical NIC segmentation is not yet implemented
  • Management-plane design is still being refined
  • Firewall policy cleanup remains active work

Operations

  • Remote-access persistence needs further validation
  • User lifecycle procedures are still being formalized
  • Automation is not yet the primary operational control plane

ROADMAP

Build the foundation before adding more weight.

Near Term

  • Dedicated management workstation
  • Guacamole persistence and recovery validation
  • Physical network segmentation
  • Firewall policy refinement
  • Proxmox API automation

Later

  • Additional Proxmox nodes
  • Dedicated backup infrastructure
  • High availability
  • Centralized log aggregation
  • Kubernetes CI/CD and GitOps expansion
  • Distributed storage when hardware supports it

RELATED WORK

Detailed engineering artifacts.

This page is the current-state overview. Individual implementation details, decisions, failures, and lessons learned are documented separately as project case studies and engineering journal entries.

View Projects Engineering Journal Return to GillPad