Inside my home lab

Three layers, one environment

I split my home infrastructure by workload. The router provides connectivity, the NAS keeps everyday services running, and the PC supplies compute for AI. This website is itself hosted on the NAS.

Network, remote access and HTTPS

I upgraded RouterOS from version 6 to 7 after creating configuration backups and exports. I updated RouterBOARD firmware too, checked connectivity and DNS, then replaced the unused PPTP service with WireGuard.

• WireGuard provides access to private home services from my phone. Full-tunnel operation routes the phone’s Internet traffic through home as well.
• Separate input and forward firewall rules handle VPN handshakes, DNS, access to the LAN and Internet routing.
• MikroTik IP Cloud provides DDNS. OVH hosts my public DNS zone; mail records are independent of web hosting.
• Public HTTP/HTTPS traffic reaches Caddy on the NAS through NAT. Caddy serves static pages and proxies the music service; the chat and administration interfaces remain private.

For local names, I account for split DNS and hairpin NAT. Resolving a hostname and receiving a ping reply only confirms part of the path: the destination port must still provide the correct HTTP or TLS service.

Services on the NAS

I keep service data in persistent directories, separate from container lifetimes. Compose defines restart policies and resource limits. On this NAS, a CPU quota caused a CFS compatibility error, so I retained memory limits without that quota.

Monitoring is evidence for diagnosis, not a certified ISP measurement. Throughput also depends on concurrent traffic, the NAS and the selected test server. Battery-powered or sleeping devices need checks appropriate to their normal behaviour.

Docker and AI on the PC

My main chat runs on the PC. Open WebUI connects to Ollama through host.docker.internal; Ollama runs on Windows and uses the GPU. A Docker network connects the WebUI with search, the Google bridge, SSH Operator and ComfyUI.

A Windows logon script starts Docker Desktop, Ollama and the observer, waits for Docker to become ready and starts the Compose services. This is logon startup, not guaranteed unattended startup before a user signs in. Starting the services does not preload a large model into VRAM.

What the agent can do

The model selects a function and its arguments. Python tools execute the request, return structured results and let the model write a human-readable response. I explicitly assign those tools to the model and enable native function calling in Open WebUI.

Sharing the GPU

My PC is also used for gaming, so retaining every model in VRAM is not useful. Ollama is configured for one loaded model and five minutes of keep-alive. Before image generation, the image tool requests that running language models unload. It submits a workflow to ComfyUI, then requests memory release after the result is saved.

Question → Ollama → tool call
Image request → unload LLM → ComfyUI → save result → unload image model
Next question → load LLM again

This is sequential resource management, not a guarantee that all 16 GB will be available. Windows, the display and other GPU applications use memory too. Host RAM and the RAM assigned to WSL are separate limits; filesystem caching may accelerate reloads but does not guarantee a permanently resident model.

Privacy and practical boundaries

• Local model inference; web search and Google integrations still communicate with external services.
• Selected PC data is read-only. Draft files have a separate write directory. SSH permissions are distinct and may allow real configuration changes.
• Secrets stay outside public website files. Certificates and application data need their own protected backup.
• I treat webpages and emails as untrusted input. The model may still misinterpret content, omit details or produce an incorrect answer.

The lab is an evolving personal project. Voice, a family document knowledge base, automatic PC wake-up and broader media generation are planned extensions, not claims about finished features.