AYRON JINS / LAB
SYSTEM: ONLINE
← HOME01 / HOME LAB
Environment / Homelab

Ayron Jins homelab.
Build it. Break it.
Understand what moves.

My environment for building, deploying, breaking, fixing and understanding systems: virtualization, Linux, containers, networking, self-hosting, and some local AI thrown in.

TYPE / SELF-HOSTEDVIRTUALIZATION / ACTIVECONTAINERS / ACTIVENETWORK / MANAGED
02 / 05
CONCEPTUAL SYSTEM PATHINTERNET → PROXMOX VE
MOVING SIGNAL · SELECT A NODE
Infrastructure layers

A stack with boundaries.

02A / 05
LAYER 01

Virtualization

Proxmox VE is the virtualization foundation. It's what lets workloads stay isolated, run as separate VMs, and get managed without everything living directly on bare metal.

PHYSICAL HOSTPROXMOXVM / VM
LAYER 02

Linux server

Ubuntu Server and Linux are the operating layer underneath everything: administration, services, networking, container workloads, all of it.

SSHCLILOGSPERMISSIONSSYSTEM SERVICESPACKAGES
LAYER 03

Containerization

Docker deploys and isolates self-hosted services. Portainer sits on top, giving centralized visibility into what those containers are actually doing.

CONTAINER / service ACONTAINER / service BCONTAINER / service C
Self-hosted services

Services as relationships.

Each service has a role in the environment. Select one to see what it is, why it belongs here, and what it connects to.

02B / 05
Service explorer

Choose a layer.

Nginx

WHAT IT IS / A web server and reverse-proxy layer. WHY I RUN IT / To route appropriate web requests and keep the edge understandable. CONNECTS TO / Public domains and backend applications.

System relationships

Nothing useful runs alone.

02C / 05

COMPUTE → SERVICES

PROXMOX VEUBUNTU SERVERDOCKERPORTAINERSELF-HOSTED SERVICES

LOCAL AI PATH

LOCAL COMPUTEOLLAMALOCAL LLMOPEN WEBUI

DNS REQUEST

CLIENTDNS REQUESTADGUARD HOMEFILTER / RESOLVENETWORK

PUBLIC EDGE

INTERNETROUTER / FIREWALLNGINX / PROXYAUTHORIZED WEB SERVICE
Why self-host?

Because the layers are the lesson.

Self-hosting is what makes the path visible: where an application actually runs, how it connects to everything else, what it needs to keep working, and what breaks when one assumption underneath it changes.

CONTROLUnderstand where applications and data run.
LEARNINGWork directly with systems, networks and services.
PRIVACYKeep appropriate services within infrastructure I control.
EXPERIMENTATIONDeploy, break, rebuild and modify the stack.
Operate / repeat

Operate → break → debug → improve.

01DEPLOY
02CONFIGURE
03MONITOR
04BREAK
05DEBUG
06FIX
07DOCUMENT
08IMPROVE

The real value of a lab is troubleshooting systems that actually break: configuration conflicts, networking problems, port collisions, dependency issues, container quirks, reverse-proxy misconfigurations, all the usual Linux headaches.

Local representation / not live telemetry

Operate from the command line.

Predefined responses demonstrate the interface; they do not report current machine state.
$ homelab status
virtualization active
linux active
containers active
dns active
storage active
ai-runtime active

$ explore --services
adguard-home · immich · nextcloud · ollama · openwebui · nginx · portainer
Practical knowledge

What this lab taught me.

02D / 05
AREA / 01

Linux administration

Operate servers through packages, permissions, services, logs, networking and the CLI.

AREA / 02

Containerization

Understand image, container, port and service boundaries when deploying applications.

AREA / 03

Virtualization

Reason about host, guest, resource boundaries and virtualized workloads.

AREA / 04

DNS & proxying

Trace resolution, routing, certificates and reverse-proxy behavior from request to service.

AREA / 05

Network troubleshooting

Investigate ports, paths, firewall rules, NAT, dependencies and logs without guessing.

AREA / 06

AI model hosting

Explore local model runtimes and interfaces as software systems with infrastructure around them.

SCENARIO / PORT CONFLICT

Find the process before changing the service.

INVESTIGATE
Identify which process or container owns the port.
DIAGNOSE
Determine whether the conflict is another container, proxy or system service.
RESOLVE
Reconfigure the path and validate connectivity.
LEARN
Understand how host ports, container ports and services interact.
SCENARIO / PUBLIC SERVICE UNREACHABLE

Separate local success from public reachability.

LOCAL
Check that the application responds correctly.
PROXY
Validate reverse-proxy behavior locally.
PATH
Inspect DNS, firewall, NAT, upstream and possible double-NAT.
LEARN
Trace the complete path instead of assuming the application is broken.
Condensed summary

My lab stack

VIRTUALIZATIONProxmox VE
OPERATING SYSTEMSLinux / Ubuntu Server
CONTAINERSDocker / Portainer
NETWORKAdGuard Home / DNS / Nginx
STORAGE & CLOUDNextcloud
MEDIAImmich
AIOllama / Open WebUI
SERVERSPaperMC / web services
Optional guided concept

Trace a request.

Educational path only. The exact route depends on the service.

Next layer / Part 3

The services are one side of the system.

Next: the network connecting everything together.

NETWORK →
Continue through the system

Trace the network

See how DNS, routing, proxies and service exposure connect the environment.

Open section →
Practical utility / Public edge

Inspect the domain path.

Use Domain Observatory to examine DNS, certificates, HTTPS and exposed security headers.

Open Domain Observatory →
References / Verified sources

Technology & official sources.

The systems vocabulary behind this environment, linked to the projects that maintain it.

SOURCES / 13

This homelab is built, broken and repaired by Ayron Jins. The dashboard that monitors it is open source: homelab-dashboard. The full build story is documented in the homelab and network case study, and it is the environment KHS AI is developed against.