# ChristianLempa/homelab: a homelab published as thirty directory names and no index > This repository is one person's home infrastructure, split into a directory per technology and described by a readme that is mostly a disclaimer. There is no table of contents, no per-directory explanation and no accepted contributions, which makes it an archaeological record of one stack rather than a guide, and that is both its value and its limitation. **ChristianLempa/homelab** — This is my entire homelab documentation files. Here you'll find notes, setups, and configurations for infrastructure, applications, networking, and more. - Repository: https://github.com/ChristianLempa/homelab - Stars: 2,135 · Forks: 294 - Language: HCL - License: MIT - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/christianlempa-homelab ## The readme is a disclaimer, and the directory listing is the documentation Almost everything in this readme is an apology. There is a warning, placed near the top, that products change over time and that the author does his best to keep up with the latest changes and releases but that this will not always be the case. There is a redirect, telling you that if you are looking for in-depth tutorials on a particular tool or technology, there is a video channel instead. There is a contribution section that refuses contributions. And there is a request to become a fan. What is not there is any description of the infrastructure itself. The entire map of the project is the top level listing, which is thirty entries after the housekeeping files. There is no table of contents, no architecture diagram, no explanation of which service runs where, no notes on hardware, no record of why a choice was made over an alternative. A reader arriving cold gets a set of names and has to work out the shape of the stack from the names alone. That is a real limitation and it is worth being blunt about, because a directory named after a product is not documentation of a deployment. A committed configuration tells you what someone ran; it does not tell you whether it works, whether the defaults were changed, whether the author abandoned it last year and left the files, or whether the version pinned in the file is one that has since been superseded. Combined with the drift warning, the correct way to read this repository is as an archaeological record: a dated snapshot of a working system, kept for reference, with no promise that it still runs. The author is clear-eyed about that, which is a point in the project's favour. The alternative would be a readme that described a homelab as a production-grade reference architecture, and that would be worse in every way a reader could detect. ## What the selection tells you, and what the names let you infer With no prose to work from, the only evidence available is the choice of names, and the choice is more informative than it first appears. Thirty directories is not an arbitrary number, and the set is not a generic list of popular self hosted software. Grouping them by what the names denote produces a recognisable layered structure. At the bottom there is a hypervisor named for a specific virtualisation platform, and beside it a network-attached storage product and a load balancer for allocating addresses on a bare metal network. Those three together imply a virtualisation substrate with storage and addressing handled inside it rather than by the host, which is a specific and deliberate architecture rather than a common one. Sitting alongside them are a container orchestration product, an ingress product, a general web server, a certificate manager, and a continuous delivery tool. That cluster is the shape of a container platform: something schedules, something routes, something terminates certificates, something applies desired state. Above that sit the stateful pieces. Two relational databases and a time series database, which is a reasonable split for an application database, a reporting database, and metrics. A secrets manager, an identity provider, and a remote access tool, which is a trio that together cover the three things you actually need to keep out of a configuration file: credentials, users, and the ability to reach a machine that has no public address. Two overlay networking products appear as well, one of them a commercial service, which suggests the author is running a private access path alongside whatever the internal network already provides. Then the operational layer. A metrics system, a dashboard tool, a container metrics collector, an uptime monitor, and a host security platform. The last of those is the unusual entry: a full security monitoring product is not a standard homelab component, and its presence suggests the author treats the home lab as something worth defending rather than experimenting on. Two names do not fit the pattern and are worth noting. One is a home automation platform, which is the one consumer-facing piece in an otherwise server-shaped list. The other is a workflow orchestration product, which is the kind of tool that normally shows up in a business deployment and is a sign that some real automation runs here rather than a scheduled script. The language statistic backs up the reading. The repository's primary language is recorded as infrastructure-as-code, which means a substantial part of what is committed is declarative configuration for a provisioning tool rather than hand-edited files. That is the difference between a configuration snapshot you can read and one you can apply, and it is the most consequential fact about the repository that the readme does not mention. ## Why contributions are refused, and why the licence is permissive anyway The contribution section is four sentences and they are unambiguous. This is personal homelab documentation, contributions are not accepted, and anyone who wants it is invited to fork the repository and use it for their own documentation. Read in isolation that looks unfriendly. Read alongside the presence of a permissive licence file it becomes the most coherent decision in the repository. A restrictive licence plus no contributions would be a dead end: you could look but not use and not share. A permissive licence plus no contributions is a clean contract. You get an explicit right to copy, modify and redistribute, including commercially, and the author keeps the right to decline patches. Those are not in tension, they are two halves of the same statement about who is responsible for the content. There is also a security file at the root, which is a signal that the project takes the hosting of a public repository seriously even though the content is personal. For a repository with no releases, no packaged artefacts and no published site, that is a reasonable thing to have and an unusual one to see. What the refusal costs is straightforward. A homelab breaks. Tools change default paths, image names move, configuration formats are rewritten, and a reverse proxy gets a new annotation syntax. The author has anticipated this and disclaimed it in the warning at the top. But a refusal policy means nobody else's breakage gets fixed in place, so the drift compounds silently: a fork made in 2026 and never revisited will be quietly wrong within a year, and the only signal will be that something stopped starting. That is why the sibling repositories matter more than this one for anyone who wants something they can maintain. The templates repository is where reusable starting points live, the command reference is where the operational knowledge lives, and the dotfiles repository is the personal machine configuration. This repository is the deployed state, and deployed state is by definition the thing that rots fastest. ## A single topic tag, no releases, and a homepage that does not exist The contribution section is four sentences and they are unambiguous. This is personal homelab documentation, contributions are not accepted, and anyone who wants it is invited to fork the repository and use it for their own documentation. Read in isolation that looks unfriendly. Read alongside the presence of a permissive licence file it becomes the most coherent decision in the repository. A restrictive licence plus no contributions would be a dead end: you could look but not use and not share. A permissive licence plus no contributions is a clean contract. You get an explicit right to copy, modify and redistribute, including commercially, and the author keeps the right to decline patches. Those are not in tension, they are two halves of the same statement about who is responsible for the content. There is also a security file at the root, which is a signal that the project takes the hosting of a public repository seriously even though the content is personal. For a repository with no releases, no packaged artefacts and no published site, that is a reasonable thing to have and an unusual one to see. ## Drift is the one failure mode nobody else can fix for you What the refusal costs is straightforward. A homelab breaks. Tools change default paths, image names move, configuration formats are rewritten, and a reverse proxy gets a new annotation syntax. The author has anticipated this and disclaimed it in the warning at the top. But a refusal policy means nobody else’s breakage gets fixed in place, so the drift compounds silently: a fork made in 2026 and never revisited will be quietly wrong within a year, and the only signal will be that something stopped starting. That is why the sibling repositories matter more than this one for anyone who wants something they can maintain. The templates repository is where reusable starting points live, the command reference is where the operational knowledge lives, and the dotfiles repository is the personal machine configuration. This repository is the deployed state, and deployed state is by definition the thing that rots fastest. ## Conclusion ChristianLempa/homelab is worth reading as a worked example of scope rather than as a template to copy, and it is most useful to someone deciding which layer of a home infrastructure goes on which virtual machine, because the selection is the argument. It is not usable as documentation, since nothing in it explains what any directory contains, and it will not accept your fix if a tool changes underneath it, since contributions are refused and forks are the intended route. Treat the whole thing as a snapshot with a date on it, apply that scepticism to any product named in it, and use the three sibling repositories for the parts that are meant to be reusable, because the boilerplate templates and the command reference are where maintained content actually lives. ## FAQ ### What is in ChristianLempa/homelab? It is one person's self hosted infrastructure documentation, split into a top level directory per technology covering hypervisor and storage, container orchestration and ingress, databases, secrets, identity, remote access, monitoring, deployment interfaces, home automation and host security. The readme does not describe what any individual directory contains. ### Can I contribute to ChristianLempa/homelab? No. The readme states that this is personal homelab documentation, that contributions are not accepted, and that anyone who wants to use it is invited to fork the repository for their own documentation. The repository is MIT licensed, so forking and modifying are explicitly permitted. ### How current is the configuration in ChristianLempa/homelab? The readme carries a warning that products change over time and that the author does his best to keep up with changes and releases but that this will not always be the case. There are no releases, so there is no version to check against, and the last commit to the default branch is dated 2026-08-31. ### What other resources does the author maintain alongside this homelab? Three separate repositories: personal dotfiles for macOS, boilerplate templates for projects such as Docker, Kubernetes and Ansible, and a cheat sheet repository described as a command reference for various tools and technologies. ## Sources - [ChristianLempa/homelab on GitHub](https://github.com/ChristianLempa/homelab) - [Issues](https://github.com/ChristianLempa/homelab/issues) - [License: MIT](https://github.com/ChristianLempa/homelab/blob/main/LICENSE) - [README](https://github.com/ChristianLempa/homelab/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/christianlempa-homelab