TechHutTV/homelab: A Two-Server Docker Compose Reference Stack

What TechHutTV/homelab actually is, and who it is for

TechHutTV/homelab is a personal infrastructure repository, not a distributable tool. The README describes it as Docker Compose stacks, configuration templates, and documentation for everything running in the author's homelab, spread across two machines: an Unraid NAS for media and a Proxmox node for everything else. The top level of the repository is organised by function rather than by software: apps/, cloud/, homeassistant/, media/, monitoring/, netbird/, proxy/, storage/, surveillance/, plus a glance.yml dashboard file, an old_hardware.md, and a timezones.properties file.

The audience is narrow and specific. Someone building a Servarr media setup behind a VPN, a Frigate NVR with a Coral TPU, or a Grafana view over Unraid and Proxmox will find a worked example here. Someone who wants a single command that stands up a homelab will not. The repository has no packaging, no release artefacts, and no installer. Its value is that the Compose files and templates are readable and can be copied piecemeal, which the README invites directly: "feel free to dig around and use whatever is helpful."

One thing to weigh before treating this as a template: the hardware section is full of affiliate links and sponsored equipment. The author states plainly that Ubiquiti sent the networking gear and that the setup is "crazy overpowered for what I need." That does not make the Compose files wrong, but it does mean the reference architecture is shaped by hardware most readers will not have. Copy the service definitions, not the topology.

How the repository is organised across Unraid and Proxmox

The split is the core design decision. Media workloads live on the Unraid box, which also runs a NextCloud VM. Everything else, described in the README as Grafana, NPM and other services, runs on a Proxmox node. The directory names map onto that division: media/ and cloud/ belong to the NAS side, while monitoring/, proxy/ and netbird/ sit on the Proxmox side. surveillance/ and homeassistant/ could plausibly land on either.

This is a two-host layout connected by Ubiquiti switching, with a 10G aggregation switch between the devices. For a reader, the practical consequence is that the Compose files are written for a multi-host environment. Volume paths, network names and service discovery assume a particular arrangement of mounts and bridges that the README does not fully document host by host. The repository layout shows where each stack lives, but the README does not state which host each directory is deployed on.

There is a glance.yml at the top level, which points at a dashboard configuration, and a timezones.properties file, which suggests at least one stack consumes timezone data from a shared file rather than hardcoding it per container. Those two files are the clearest signal that the repository is meant to be read as a coherent system rather than as isolated snippets. The README does not explain either file, so you are left to infer their role from their names and their position in the tree.

Installing nothing: how to take a first useful piece

There are no install steps in the README, because there is nothing to install. The repository is consumed by cloning it and reading the directory that matches your need. The README lists each directory with a one-line description, so the first step is choosing one.

If you want the media stack, clone the repository and look inside media/:

git clone https://github.com/TechHutTV/homelab.git
cd homelab/media
ls

The listing shows the Compose files and supporting configuration for Plex, Jellyfin and the *arr stack. From there you copy the relevant file into your own deployment and adjust the paths, because the volume mounts in the original point at the author's Unraid shares.

For the surveillance stack, the same pattern applies, with the README naming Frigate NVR plus a Coral TPU as the target:

cd ../surveillance
ls

What you should expect to see is a Compose file plus whatever Frigate configuration the author committed. The README does not document the Frigate version, the TPU model, or the camera configuration, so treat the file as a starting point and verify the image tag before you run it.

The monitoring directory follows the same shape, holding the graphs and visualisations the README mentions for Unraid and Proxmox. Nothing in the repository is executed for you. There is no Makefile, no bootstrap script and no documented environment file, so every stack you take needs its own variables supplied by you before it will start.

Where a copied stack breaks: paths, secrets and no rollback

The most predictable failure is the volume path. A Compose file written for an Unraid array references share names and mount points that exist on the author's server. Drop the same file onto a Proxmox host with a different storage layout and the container either fails to start or starts with an empty volume, which is worse because it looks like it worked. The README does not list the mount points, so you have to read each Compose file and reconcile it against your own filesystem.

The second failure is configuration drift. The README states the repository is a work in progress and that there is still a lot to update and add. There are no releases, so there is no version to pin, no changelog to read, and no way to tell whether a Compose file you copied six months ago matches what is in the repository now. If you fork it, you own the divergence.

The third is the absence of rollback guidance. The README does not document rollback for any stack, and with no release artefacts there is nothing to roll back to. If a copied stack breaks your running services, the recovery path is whatever you built yourself: your own backups, your own notes, your own git history of your own copy. The repository does not provide one, and nothing in it suggests it intends to.

Finally, this is the wrong tool entirely if you need support, a compatibility guarantee, or an upgrade path. It is also the wrong tool if your hosts are not Unraid and Proxmox, because the directory structure assumes that split even though the individual Compose files may port cleanly.

Compared with a maintained deployment project like CasaOS

The useful comparison is not another homelab repository but a deployment platform aimed at the same audience. CasaOS is a self-hosted dashboard and app manager that installs on a Linux host and presents a web interface for adding and running containerised apps. The difference in approach is the whole point.

CasaOS ships an installer, manages container lifecycle for you, and gives you a UI where apps are added from a catalogue. TechHutTV/homelab ships Compose files and templates that you read, copy and adapt. CasaOS decides how your services are wired and where their volumes live; this repository leaves every one of those decisions to you, which is exactly why its files are useful as examples and useless as a product. With CasaOS you get an upgrade path and a support surface. With this repository you get a worked reference and full responsibility.

A second comparison is a curated Compose collection such as the awesome-selfhosted style lists, which point at upstream projects and their own documented installation instructions. Those give you a maintained source per service. TechHutTV/homelab gives you one person's working configuration, which is more opinionated and more immediately usable, but carries no maintenance commitment from anyone but you. If you want to understand how a Servarr stack, a Frigate NVR and a monitoring layer fit together on real hardware, the repository is the more instructive read. If you want something running tonight with a rollback path, it is not.

Maintenance, licensing and what the repository leaves open

The repository is not archived, and the last push was on 2026-09-07. That is recent enough that the files reflect a current setup, but the README's own framing, "This is a work in progress - I still have a ton to update and add," is the honest description of what to expect. There are no releases, so there is no versioning to track and no upgrade notes to follow. Upgrading means pulling the latest commit and diffing it against your fork, then deciding service by service whether to take the change. For a repository of Compose files that is a manageable process, but it is manual and it is yours.

The licence is not stated anywhere in the repository. The README does not name one, and no LICENSE file appears in the top-level repository entries, which list .gitignore, README.md, the nine directories, glance.yml, old_hardware.md and timezones.properties. Without a licence, the default position under copyright is that no rights are granted beyond what the hosting platform's terms allow, which for a repository meant to be copied is a real gap. If you intend to reuse these files in your own project, particularly anything you publish, check the repository for a licence before you do. This is not legal advice, and the absence of a licence file is something to resolve with the author or your own counsel rather than assume away.

The affiliate links in the hardware section are worth noting for a different reason: they indicate the repository doubles as a companion to a video channel. That is fine, but it means the hardware choices documented here reflect what was sent for review, not what a budget build would use.

Editorial conclusion

Adopt this repo as a reading and copying reference if you run Unraid or Proxmox and want to see how Servarr behind a VPN, Frigate with a Coral TPU, or a monitoring stack is laid out in Compose files. Do not adopt it if you expect a supported product, a versioned release, or a licence that grants you rights, because the repository shows none of those. Before copying anything, open the directory for the service you want and check whether its Compose file still matches the hardware described in the README, since the author states the repo is a work in progress.

Frequently asked questions

Official sources

1. Issues
2. README
3. TechHutTV/homelab on GitHub