Work
How it’s built.
Five systems. For each one: the problem, the design, what I built, and the decision that mattered.
No public IP. Still public.
A public game server, run from home.
Public traffic
Admin only
The problem
The server had to be reachable from the internet without exposing anything on the home network.
The design
A dedicated DMZ-style VLAN holds the service plane. Players arrive through a playit tunnel; administration happens only over Tailscale.
What I built
A Minecraft VM on VMware ESXi, hardened with systemd and a restricted service user, with scheduled backups.
Key decision
Public ingress and admin access never share a path.
Trade-off — public reachability depends on playit's relay. In exchange, nothing on the home network accepts an inbound connection.
- Network
- Dedicated DMZ-style VLAN
- Public ingress
- playit tunnel
- Admin access
- Tailscale only
- Host
- VM on VMware ESXi
- Hardening
- systemd, restricted service user
- Backups
- Scheduled
One network. Four zones.
A wireless-first home network, segmented the way a small office would be.
The problem
On a flat network, any device can reach any other, including a server that is open to the internet.
The design
Four VLANs — trusted, IoT, guest, and the MC-DMZ service plane — with restrictive east-west rules between them.
What I built
A UniFi Cloud Gateway Max and a U7 Pro Max access point, with per-SSID VLAN tagging and WPA3 where devices support it.
Key decision
Nothing crosses between zones unless a rule allows it.
Trade-off — every cross-zone need has to be allowed rule by rule, which takes more upkeep than a flat network.
- Gateway
- UniFi Cloud Gateway Max
- Wireless
- U7 Pro Max
- Segments
- Trusted, IoT, guest, MC-DMZ
- Policy
- Restrictive east-west rules
- Wi-Fi
- Per-SSID VLANs, WPA3 where supported
- Public exposure
- Tunnel only
Three nodes. One platform.
A small Kubernetes platform on Oracle Cloud's Always Free ARM tier.
The problem
Every public service needed a hostname and TLS, without hand-built port forwards for each one.
The design
One control-plane node and two workers. Ingress-NGINX routes by hostname, and cert-manager issues and renews certificates.
What I built
K3s on OCI ARM instances, behind tightened VCN security lists.
Key decision
Every public service gets a clean ingress and certificate — never an ad-hoc port.
Trade-off — one control-plane node keeps the cluster on the free tier, but that node is a single point of failure.
- Cloud
- OCI Always Free, ARM
- Cluster
- K3s, 1 control plane + 2 workers
- Ingress
- Ingress-NGINX
- Certificates
- cert-manager
- Network
- Tightened VCN security lists
- Admin access
- Tailscale
Everything, written down.
A self-hosted wiki for runbooks, architecture notes, and lab write-ups.
The problem
Every system here needed one place for runbooks, decisions, and lab write-ups.
The design
BookStack runs as a Kubernetes workload with persistent storage, ingress, and certificates from cert-manager.
What I built
A read-only guest account for visitors, sign-in to edit, and backups that cover the database and uploaded files.
Key decision
Guests can read, edits need sign-in, and the data is backed up.
Trade-off — the wiki runs on the cluster it documents, so an outage takes the docs down too. The database and uploads are backed up for exactly that case.
- Application
- BookStack
- Platform
- K3s on Oracle Cloud
- Storage
- Persistent volumes
- Access
- Guest read-only, sign-in to edit
- Guest account
- guest / guest, read-only
- Backups
- Database and uploads
Incident response, on demand.
IRLab is a training platform for incident-response decisions, live at irlab.hyuntae.net.
The problem
Incident-response judgment is hard to practice without a real incident in front of you.
The design
Choose a track and difficulty, read a realistic alert, write a plan, and get scored against an explainable rubric.
What I built
70 scenarios across 4 tracks and 4 difficulty levels, each mapped to a framework, with every attempt saved for review.
Key decision
No LLM in the score, so every point is explainable.
Trade-off — a rule-based rubric can miss a good answer phrased in an unexpected way. In exchange, the same answer always gets the same score.
- Scenarios
- 70, each framework-mapped
- Tracks
- 4
- Difficulty
- Easy to Extremely Hard
- Scoring
- Deterministic rubric
- Progress
- History and dashboard
- Hosting
- K3s, HTTPS
From the lab notebook
- Linux server hardening (opens in a new tab)
- Firewall and IDS (opens in a new tab)
- Routing and switching (opens in a new tab)
- Self-hosted services (opens in a new tab)
Guest read-only access: guest / guest
Let’s talk.
Questions about any of these systems are welcome. Email is the fastest way to reach me.