My HomeLab did not begin as a carefully planned platform. It started with a few machines, a need to reach them remotely, and the familiar thought: I could host that myself. Over the years it has grown into a network spanning my home in Croatia, my apartment in Germany, hosted systems in German data centers, and an Austrian location. Some services are useful every day; other systems exist so I can learn, break things, and rebuild them properly.
I work with networks and infrastructure professionally, but this is my own place to experiment. It lets me test routing, virtualization, storage, automation, monitoring, and recovery as parts of one system. The interesting challenge is no longer getting one server online. It is making all the locations work together without losing track of what runs where or how to recover when something fails.
This is a tour of the HomeLab as it stands in 2026, including the decisions that shaped it and the parts I am still improving.
One lab, several locations
Each location has a different job. The homes give me physical hardware and local storage; hosted machines provide an internet-facing entry point and services that need better availability. The Austrian equipment remains part of the wider environment. I use names from mythology and the Marvel universe because server-01 stops being useful surprisingly quickly.
| Location | Main systems | Role |
|---|---|---|
| Home in Croatia | BIFROST, ODIN, ASGARD | MikroTik routing, Proxmox workloads, and QNAP storage and backups. |
| Apartment in Germany | HEIMDALL, TESSERACT, VAULTOR, MICRO1–3 | Site routing, Docker services, QNAP storage, and a small cluster for MicroCloud experiments. |
| Hosted systems in Germany | ENTERPRISE, JARVIS, STRANGE, ULTRON, FRIDAY Proxmox hosts | Public-facing services, mail, network connectivity, virtualization, and backup targets. These systems do not all have the same role or sit in the same facility. |
| Austria | NEXUSHUB and systems including LORE | The routing environment and an additional Proxmox and storage location. |
That table is a map of responsibilities, not a promise that every experimental workload runs around the clock. I try to keep the things I rely on understandable and treat the rest as a place to test ideas.
Connecting the sites with WireGuard
The network is the foundation. The sites have their own local networks, with MikroTik routers such as BIFROST and HEIMDALL at the edge. WireGuard connects the locations, while NEXUSHUB is central to how I organize the routes between them. The design has evolved from my earlier setup with a public WireGuard server on ENTERPRISE: as the number of locations and subnets grew, simply connecting peers was no longer enough. I needed a clear view of where each network lives and which gateway should carry its traffic.
I use separate networks for different sites and purposes, such as management, services, storage, and experiments. Routing makes resources reachable across the tunnels without pretending that every device belongs to one giant LAN. When I connect from my laptop, I can work on a system in another country much as I would at home, subject to the routes and firewall rules for that destination.
The practical lesson has been that a working tunnel is only the beginning. Traffic must have a valid route and a return route; the host firewall must allow it; and the service must listen on the expected interface. I have spent enough time troubleshooting all four to know that “WireGuard is up” does not necessarily mean an application is reachable.
I wrote about an earlier version of this setup in my WireGuard installation and configuration post. The current lab has more locations and more deliberate routing, but the original goal is the same: reach my systems securely wherever I am.
NEXUSHUB: a project born from my HomeLab
NEXUSHUB is more than a name for a machine in the diagram. It is my own open-source project, built around the problems I encountered while connecting and managing several locations with WireGuard. As the lab grew, I wanted a better way to manage interfaces, peers, and access rules, with one place to see what was happening across the network.
I am developing NEXUSHUB as a self-hosted WireGuard control plane with a web dashboard, API, and CLI. The project uses a Go backend and a React frontend, and includes work on eBPF-based traffic rules and monitoring. It is under active development, so I treat the software’s features and deployment options as evolving rather than presenting it as a finished product.
You can follow the code and progress on GitHub, or visit nexushub.tools for the project overview and documentation.
Compute: Proxmox, containers, and a small cluster
Proxmox is the main virtualization platform in the lab. ODIN at home and FRIDAY in Germany are examples of how I use physical hosts to run separate services and test infrastructure changes. I also work with Proxmox systems in Germany. Virtual machines give me isolation when I need a full operating system; LXC containers are useful for lighter workloads.
Docker handles many of the application services. TESSERACT is one of the Docker hosts, while other containers run on hosted systems where public access or proximity to a particular service makes more sense. I do not insist that every workload use the same packaging method. I choose between a VM, an LXC container, and a Docker container according to what I need to operate, update, and back up.
The three Lenovo thin clients, MICRO1, MICRO2, and MICRO3, are another part of the story. They give me a compact cluster for working with Canonical MicroCloud and its networking. Small machines are enough to learn about cluster behavior, node placement, and storage decisions without needing a rack of enterprise hardware at home.
Storage is a design decision, not an afterthought
ASGARD in Croatia and VAULTOR in Germany are my QNAP storage systems. I also use storage and backup targets in the other locations. This lets me keep data close to the workloads that need it while copying backups beyond the machine, and in some cases beyond the site, where they were created.
Storage has also taught me to be precise about what a backup actually covers. A VM disk, an LXC mount point, an application database, and a directory on an NFS share can have different backup behavior. I have had to investigate skipped container backups, storage connectivity, and sync jobs instead of assuming that a green dashboard represents every piece of data I care about.
Proxmox Backup Server is a significant part of my current backup workflow. I use it with datastores backed by dedicated storage, including an NFS-backed datastore in Germany, and I configure sync and pruning jobs for backup copies. My next measure of success is not the number of scheduled jobs: it is whether I can identify the correct backup and restore a service when I need it.
The services behind the infrastructure
The lab supports real services, not just test VMs. My Nextcloud gives me a personal cloud, Collabora provides document editing, and JARVIS runs my mail stack. Traefik sits in front of web services and sends requests to the appropriate backend. The website you are reading, tomeksdev.com, is where I document some of the work.
These applications demonstrate why the underlying network matters. A browser may reach a public hostname, but the reverse proxy still has to reach the right service across the internal network. The application then has to trust the correct URL and return its response through the expected path. I have troubleshot that full chain with Nextcloud and Collabora; a reachable container alone does not prove the integration works.
I also run smaller internal tools and experiments. Some stay because they solve a daily problem. Others teach me something useful and are eventually replaced. That is one of the freedoms of a HomeLab: it can be both infrastructure and a workshop.
Managing changes with Ansible and Git
The more machines I added, the less I wanted to configure each one by hand. I keep my Ansible work in a private Git repository and use roles and playbooks for the repeatable parts of a server build: users, common packages, SSH security, monitoring, Docker, WireGuard, and application deployment.
My baseline includes key-based SSH access, limited login methods, host firewall rules, and monitoring agents. Application-specific rules are narrower. For example, a reverse proxy should reach the service it fronts; that does not mean an entire private network needs access to the service port.
Automation is useful precisely because I still make mistakes. I have had to correct a service that did not come up after a reboot and refine firewall rules that were broader than intended. Keeping the desired configuration in Git makes those changes easier to review and repeat. I also use n8n for operational workflows, including reporting around Proxmox backups. It complements Ansible: one helps apply configuration, while the other helps connect events and routine checks.
Monitoring what matters
Monitoring in my lab has several layers. Uptime Kuma gives me service availability checks and status views. Checkmk covers host and network monitoring, including devices reached through the routed network. Wazuh adds security visibility, such as vulnerability findings and changes on monitored servers. I have written separately about what Wazuh showed me during real tests.
No single green check tells the whole story. A host can answer a ping while a web port is closed; a website can load while its document editor cannot reach its backend; a backup job can finish while a particular guest was skipped. I want monitoring to answer specific questions: Is the service usable? Is the host healthy? Did the backup include what I expected?
I am also working toward a more consistent way to collect and explore logs from servers and network devices. That work is still evolving, so it deserves its own post once I have lived with the resulting setup.
What I have learned, and what comes next
The biggest lesson from a multi-site HomeLab is that complexity accumulates quietly. Adding one VM is easy. Documenting its network, securing its access, monitoring it, updating it, and knowing how to restore it are the parts that take discipline.
My priorities now are to keep the routing understandable, make configuration more repeatable, improve backup verification, and continue building useful observability. I also have longer-term ideas for identity and certificate management, including FreeIPA, Authentik, and a private CA. Those are plans, not components I want to claim are fully deployed today.
This lab will keep changing. That is the point. I want a place where I can learn with real systems, run services I value, and turn failures into a better design. Future posts can go deeper into NEXUSHUB routing, Proxmox Backup Server, the Ansible repository structure, and the monitoring stack. For now, this is the view from above: several locations, many different machines, and one infrastructure I can keep improving.