Core systems
Virtualization and recovery
Multi-node Proxmox, ZFS, Windows Server, Active Directory, Linux containers, virtual machines, network bridges, Docker Swarm, Proxmox Backup Server, and restore testing.
My lab
Socket23 is where I learn by building.
I use the lab to operate infrastructure, investigate security telemetry, rehearse recovery, serve local models, and test bounded agent systems myself.
It gives me room to observe failure modes, compare approaches, rebuild safely, and turn useful lessons into projects and notes.
Hybrid infrastructure lab
A small environment with a wide surface area
Network security
Detection and forensics
Security Onion, Zeek, Elastic, DShield telemetry, SiLK flows, Wireshark, IDS correlation, PCAP exercises, and CVE research.
Private AI
Inference and agents
high-memory NVIDIA GPU hardware, vLLM, llama.cpp, LM Studio, Ollama, OpenAI-compatible APIs, OpenClaw, Hermes, model routing, retrieval, and memory.
Security research
Following one event through several evidence sources
I use the monitoring lab to move between packet capture, Zeek metadata, IDS alerts, network flows, endpoint context, honeypot activity, and CVE research.
The goal is not to collect more dashboards. It is to build a repeatable way to ask what happened, whether it matters, and what evidence supports the answer.
Tools I work with
- Security Onion and Elastic
- Zeek and zeek-cut
- Wireshark and PCAPs
- SiLK flow analysis
- DShield honeypot data
- IDS and threat intelligence
Local AI engineering
Models are only one part of the system
I use local AI to study GPU capacity, model behavior, context, quantization, inference engines, API compatibility, authentication, agent integration, and remote access.
The lab lets me compare vLLM, llama.cpp, LM Studio, and Ollama while connecting real clients and agent platforms through controlled LAN and Tailscale paths.
What I validate
- VRAM and context constraints
- API and client compatibility
- Authentication and network scope
- Model-specific task behavior
- Service startup and recovery
- Logs, storage, and operational boundaries
Current build
A read-only Network Assistant architecture
I’m building an assistant that can hold a source-of-truth view of infrastructure, correlate telemetry and prior incidents, explain likely failure paths, recommend fixes with evidence, and verify recovery.
I’m designing it around read-only source access, bounded observations, source-backed knowledge, and human-controlled remediation. This public portfolio has no connection to the assistant or its data.
The boundary I care about
- Read-only access to production systems
- Write access only to its own observations and knowledge
- No production credentials capable of remediation
- Evidence and confidence attached to recommendations
- Independent detection when the AI layer fails
How I use the lab
Experiment, verify, keep the lesson
Build enough of the real system
I assemble the components needed to test integration, behavior, and recovery directly.
Break the assumption
I look for weak boundaries, failure behavior, recovery gaps, and the parts that are harder to operate than the diagram suggests.
Keep an honest record
I document the decision, evidence, limits, and next experiment so the work can compound.
I intentionally leave credentials, internal addresses, administrative entry points, private data, and sensitive operational details out of public lab material.