01
Compute and virtualization
A separated compute environment for studying workload placement, resource allocation, isolation, lifecycle decisions, and recovery planning.
View related projectTechnology lab
Learning by Building
The lab is where I test architectural ideas, evaluate emerging technologies, and validate operational assumptions without confusing a demonstration with an operable service.
It keeps my technical fluency current and gives me firsthand evidence for better questions about security, reliability, recovery, cost, integration, and organizational readiness.
Why it exists
Practice reveals operational consequences.
Continuous learning matters most when it is risk-contained, documented, and tested against failure.
The environment supports architecture validation, security evaluation, automation, emerging-technology analysis, and recovery practice. Building and operating systems exposes dependencies that vendor diagrams and isolated demos often leave out—and turns experimentation into reusable knowledge.
Public-safe architecture
A conceptual view, deliberately stripped of operational detail.
The diagram explains functional relationships without publishing addresses, hostnames, identifiers, trust rules, or administrative paths.
Remote visitors pass through a secure edge and access layer to public services, then to isolated compute and application platforms. AI workloads connect to compute and storage. Storage and recovery, monitoring and automation, and a management plane support the environment.
01Internet and remote accessPublic visitors and authorized administration
02Secure edge and accessIdentity-aware access, tunnels, VPN, reverse proxy
03Public servicesDeliberately published application endpoints
04Compute and applicationsSeparated containers, virtual machines, and platforms
AIAI workloadsLocal inference, retrieval, agents, and evaluation
Storage and recoveryData, backup, restoration
Monitoring and automationHealth, alerts, repeatability
Management planeControlled administration
Core platforms
Six connected disciplines.
Products are representative tools; the focus is the architectural question each area makes possible.
02
Networking and secure access
A public-safe model for testing trust boundaries, controlled publishing, and remote administration without exposing the underlying topology.
View related project03
Storage and data protection
A tiered storage and recovery practice focused on data lifecycle, capacity, backup behavior, and restoration—not storage capacity for its own sake.
View related project04
AI and data systems
A practical environment for comparing local and cloud inference while studying model selection, retrieval, context, privacy, and GPU capacity.
View related project05
Self-hosted platforms
A service-delivery environment for understanding deployment, identity, integration, availability, upgrades, and the operational ownership behind user-facing platforms.
View related project06
Monitoring and automation
An operating layer that turns service health, hardware signals, alerts, and repeated actions into useful evidence and repeatable response.
View related projectSelected projects
Architecture made tangible.
These public-safe profiles describe purpose, tradeoffs, and professional relevance without exposing the live environment.
Compute and virtualization
Multi-node virtualization environment
A separated compute environment for studying workload placement, resource allocation, isolation, lifecycle decisions, and recovery planning.
- Architectural approach
- Use a multi-node platform with Linux containers and virtual machines, selecting placement and isolation according to each workload's needs rather than treating every service alike.
- What I evaluate
- Workload placement and resource allocation
- Container and virtual-machine tradeoffs
- Hardware lifecycle and recovery planning
- Professional relevance
- Infrastructure architecture
- Capacity planning
- Platform standardization
- Resilience
Representative technologies: Proxmox · Linux containers · Virtual machines
Networking and secure access
Segmented networking and secure remote access
A public-safe model for testing trust boundaries, controlled publishing, and remote administration without exposing the underlying topology.
- Architectural approach
- Separate workload classes, publish services through controlled edge paths, and layer identity-aware access and VPN services around management traffic.
- What I evaluate
- Segmentation and trust boundaries
- Reverse-proxy and tunnel behavior
- Secure remote access and failure modes
- Professional relevance
- Zero-trust concepts
- Risk reduction
- Layered security
- Secure administration
Representative technologies: UniFi · VLANs · Reverse proxies · Cloudflare Tunnel and Access · VPNs
Storage and data protection
Storage and data protection
A tiered storage and recovery practice focused on data lifecycle, capacity, backup behavior, and restoration—not storage capacity for its own sake.
- Architectural approach
- Match SSD and HDD pools to workload behavior, provide shared application storage where appropriate, and treat recoverability as a tested operating requirement.
- What I evaluate
- Performance and capacity tradeoffs
- NFS-backed application behavior
- Backup, restoration, and data lifecycle
- Professional relevance
- Storage architecture
- Recovery planning
- Capacity management
- Resilience
Representative technologies: TrueNAS · QNAP · SSD and HDD pools · NFS
AI and data systems
Local artificial-intelligence platform
A practical environment for comparing local and cloud inference while studying model selection, retrieval, context, privacy, and GPU capacity.
- Architectural approach
- Host selected models locally, connect knowledge bases through retrieval patterns, and compare data control, cost, performance, and operational complexity with cloud providers.
- What I evaluate
- Model and context-window fit
- Retrieval-augmented generation
- Agent platforms and GPU capacity
- Data retention and privacy
- Professional relevance
- AI governance
- Vendor-claim evaluation
- Cost and performance analysis
- Operational feasibility
Representative technologies: Ollama · OpenWebUI · Local language models · Knowledge bases · Agent frameworks
Self-hosted platforms
Self-hosted collaboration and applications
A service-delivery environment for understanding deployment, identity, integration, availability, upgrades, and the operational ownership behind user-facing platforms.
- Architectural approach
- Operate representative collaboration, productivity, media, home-automation, and personal applications behind common access and lifecycle patterns.
- What I evaluate
- Deployment and upgrade behavior
- Identity, access, and integration
- Availability and user experience
- Operational ownership
- Professional relevance
- Application lifecycle
- Service delivery
- Integration
- User experience
Representative technologies: Nextcloud · Linux application platforms · Reverse proxies · Identity services
Monitoring and automation
Monitoring, automation and observability
An operating layer that turns service health, hardware signals, alerts, and repeated actions into useful evidence and repeatable response.
- Architectural approach
- Combine service and hardware health signals with dashboards, alerting, home automation, and small scripts that remove error-prone repetition.
- What I evaluate
- Signal quality and alert usefulness
- Service and hardware health
- Automation boundaries
- Operational visibility
- Professional relevance
- Proactive operations
- Incident prevention
- Decision support
- Repeatability
Representative technologies: Monitoring platforms · Dashboards · Home automation · Scripting
Applied artificial intelligence
Evaluate the architecture behind the claim.
My role is not model research. It is understanding AI well enough to evaluate where it is useful, govern it responsibly, and recognize what it takes to operate.
I work directly with local model hosting, Ollama, OpenWebUI, knowledge bases, retrieval-augmented generation, context limits, agent platforms, local and cloud inference, and GPU capacity planning.
That work keeps distinct concepts distinct: training is not inference; prompting is not retrieval; context is not permanent knowledge; and a compelling demonstration says little by itself about data retention, integration, security, cost, reliability, or adoption.
The practical goal is to challenge vendor claims constructively and assess governance, data handling, risk, operational feasibility, and user value with evidence.
Operating principles
How I work in the lab.
Professional relevance
Technical fluency in service of better leadership.
The lab helps me ask better architecture questions, communicate credibly with engineers, and distinguish a prototype from a dependable service.
It provides firsthand context for evaluating emerging technology, vendor claims, risk, hidden complexity, operational consequences, and investment decisions. The scale is intentionally personal; the learning strengthens—but does not replace—professional experience.