Ayush Pande writes about how his Proxmox server became more useful after he stopped treating LXCs as Docker containers. Coming from a Docker-only background, he initially tried to manage LXCs as ephemeral, single-app environments, but realized they are fundamentally system containers that run a full userland (systemd, SSH, cron) and require managing the underlying OS just like a lightweight VM. Once he shifted his approach, his home lab's utility improved significantly.
- LXCs are system containers running a full userland, unlike Docker's single-process application containers
- Proxmox developers do not recommend Docker-in-LXC; live migration can break nested container environments
- VMs are the preferred Docker hosts from a security standpoint
- On low-spec hardware (e.g., a decade-old laptop), Docker-in-LXC can still make the box usable for experimental services
- LXCs are system containers running a full userland, unlike Docker's single-process application containers
- Proxmox developers do not recommend Docker-in-LXC; live migration can break nested container environments
- VMs are the preferred Docker hosts from a security standpoint
- On low-spec hardware (e.g., a decade-old laptop), Docker-in-LXC can still make the box usable for experimental services
Joe Rice-Jones writes about replacing Nginx Proxy Manager with Caddy as a reverse proxy in his Proxmox home lab. The entire config lives in a single Caddyfile, making it readable and diffable. He uses DNS-01 challenges via Cloudflare to get Let's Encrypt certificates behind CGNAT without opening any ports, and opts for a single wildcard certificate rather than per-service certs to avoid broadcasting his setup in Certificate Transparency logs.
- Eero mesh router hijacked all DNS packets on port 53, blocking Caddy's DNS-01 lookups; fixed with `propagation_timeout -1` and a fixed `propagation_delay 30s`
- Technitium (his authoritative DNS) interfered with Caddy's zone discovery, requiring a public resolver for that lookup
- Caddy's internal CA (`tls internal`) works for quick local testing but mobile apps often reject user-installed certificates
- New Caddy package updates overwrite `/usr/bin/caddy`, so `dpkg-divert` is needed to protect custom builds
- Eero mesh router hijacked all DNS packets on port 53, blocking Caddy's DNS-01 lookups; fixed with `propagation_timeout -1` and a fixed `propagation_delay 30s`
- Technitium (his authoritative DNS) interfered with Caddy's zone discovery, requiring a public resolver for that lookup
- Caddy's internal CA (`tls internal`) works for quick local testing but mobile apps often reject user-installed certificates
- New Caddy package updates overwrite `/usr/bin/caddy`, so `dpkg-divert` is needed to protect custom builds
Anurag Singh replaced his home lab cron scripts with Qwen3.5 9B using an agent harness with shell access. He expected contextual reasoning to be superior to rigid automation. The local model succeeded in identifying ballooned directories or judging if a container restart was needed, but it failed more often, sometimes stalling or silently skipping checks.He concluded that deterministic scripts remain the more dependable choice for routine tasks and pointed to n8n as a sensible middle ground when the friction is writing and maintaining code rather than the logic itself.
- A 9-billion-parameter local model needs several GB of RAM just to load weights, which is painful on a home server already running Docker, DNS, and other services.
- Singh's specific hardware ceiling: roughly 14B parameters on a 16 GB MacBook, maybe 32B on an M5 Pro, beyond which you need a dedicated rig.
- His suggested hybrid: let the local model read an error log and draft a short explanation, then have n8n relay that summary without granting the model permission to restart or modify anything.
The model's failure mode was not wrong commands but an inconsistent process—the same prompt and the same system state, yet different execution paths on successive runs.
- A 9-billion-parameter local model needs several GB of RAM just to load weights, which is painful on a home server already running Docker, DNS, and other services.
- Singh's specific hardware ceiling: roughly 14B parameters on a 16 GB MacBook, maybe 32B on an M5 Pro, beyond which you need a dedicated rig.
- His suggested hybrid: let the local model read an error log and draft a short explanation, then have n8n relay that summary without granting the model permission to restart or modify anything.
The model's failure mode was not wrong commands but an inconsistent process—the same prompt and the same system state, yet different execution paths on successive runs.
An experiment exploring whether a local large language model can manage a home server without strict guardrails. By using the Pi agent harness and the Qwen3.6-35B-A3B model, the author successfully enabled an LLM to control a Proxmox VE node. The setup demonstrated impressive capabilities in managing LXC containers, checking system metrics, creating snapshots, and provisioning new virtual machines. Despite these successes, the system encountered difficulties with guest terminal command execution, persistent configuration management, and multi-node scaling.
- Implementation of the Pi agent harness with local models
- Autonomous creation of custom Proxmox extensions by the LLM
- Successful management of LXC containers and VM provisioning
- Challenges with terminal command execution and credential persistence
- Implementation of the Pi agent harness with local models
- Autonomous creation of custom Proxmox extensions by the LLM
- Successful management of LXC containers and VM provisioning
- Challenges with terminal command execution and credential persistence
An exploration of Technitium DNS Server, a powerful free and open-source tool that serves as an all-in-one solution for home network management. Unlike traditional setups that require multiple separate tools like Pi-hole for ad-blocking, Unbound for recursive resolution, and a dedicated DHCP server, Technitium integrates these functions into a single, easy-to-manage platform. It offers advanced features such as encrypted DNS, internal DNS zone creation for local devices, split horizon support, and native clustering for redundancy.
An exploration of transitioning from Docker to Podman within a home lab environment. The author details a weekend project setting up an Ubuntu-based Podman server on Proxmox, highlighting the key architectural differences such as the absence of a central daemon and the benefits of rootless container execution for enhanced security.
Key topics include:
- Comparison between Docker's daemon-based model and Podman's daemonless architecture.
- The advantages of rootless containers for improved host security.
- Utilizing systemd integration through Quadlets for more native Linux service management.
- Practical steps for installation on Ubuntu and Rocky Linux.
- Maintaining compatibility with tools like Portainer via the Podman API socket.
Key topics include:
- Comparison between Docker's daemon-based model and Podman's daemonless architecture.
- The advantages of rootless containers for improved host security.
- Utilizing systemd integration through Quadlets for more native Linux service management.
- Practical steps for installation on Ubuntu and Rocky Linux.
- Maintaining compatibility with tools like Portainer via the Podman API socket.
Koffan is a self-hosted grocery list application designed for simplicity and real-time updates, ideal for families. It's lightweight enough to run on a Raspberry Pi Zero W, offering a private and efficient alternative to subscription-based grocery list apps.
Logward is an open-source log collector and viewer designed for small environments like home labs. It offers a modern interface and supports Sigma rules for log detection and alerting.
This article details how the author uses a local LLM to summarize Docker logs and other home lab logs, providing proactive insights into their self-hosted setup and improving maintenance.
The article explores how Canonical's MicroCloud works well with Raspberry Pi, particularly the Raspberry Pi 5, for home lab setups. It discusses the compatibility, performance, and features of running MicroCloud on ARM-based SBCs, highlighting its ability to run both VMs and containers.
