Geek Cookbook: A Guide Series for Docker Swarm and Kubernetes Self-Hosting
The "Geek's Cookbook" is a collection of guides for establishing your own highly-available "private cloud" and using it to run self-hosted services such as GitLab, Plex, NextCloud, etc.
At a glance
- What is it?
- Geek Cookbook is a documentation collection, not a tool you install. It walks you through building a container-based self-hosting platform on Docker Swarm or Kubernetes, with recipes for Plex, NextCloud, GitLab and similar services. The judgement: useful as a structured learning path for people who already know Docker basics, but the repository itself is HTML content, and its value depends on how current the recipes are.
- Who is it for?
- Adopt Geek Cookbook if you already understand containers and want a guided path through the operational layer (reverse proxy, SSO, backups, monitoring) rather than a pile of disconnected compose files. Skip it if you want a single installable artifact or a production support contract.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 39 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Geek Cookbook Actually Is (and Is Not)
The repository is a documentation site. The primary language listed is HTML, the licence is MIT, and the README describes it as a collection of how-to guides. There is no daemon, no CLI, no package to install. That distinction matters because the first question an engineer asks about a self-hosting project is usually "what do I run", and here the answer is "you read, then you run Docker or Kubernetes commands yourself". The problem it solves is the gap between a working single-container setup and a platform that stays up. The README frames the motivation directly: once you go from playing with a tool to actually using it, having to quickly SSH into the basement server and restart Plex does not cut it. Geek Cookbook targets that operational layer. It is for people who already have familiarity with virtual machines, Docker containers, LetsEncrypt certificates, databases and command-line interfaces, and who have self-hosted something mainstream before. It is not an introduction to containers, and it is not a managed service.
Two Tracks: Docker Swarm and Kubernetes
The cookbook splits into two parallel design tracks, linked from the README as docker-swarm/design and kubernetes/. The Docker Swarm track is the lighter one. The Kubernetes track is the heavier one, and the README lists upskilling with container orchestration, Prometheus, Grafana and Kubernetes as a reason to read on. This is a real fork in the road, not a cosmetic one. A Swarm recipe and a Kubernetes recipe for the same application will differ in manifest format, service discovery, ingress configuration and secret handling. If you have not chosen an orchestrator, the cookbook will not choose for you. The recipes are described as progressive and easy-to-follow, which in practice means each guide builds on the platform elements established earlier rather than being a standalone snippet. That ordering is a constraint: skipping the platform layer and jumping to an application recipe leaves you without the reverse proxy, auth and backup pieces those recipes assume.
The Platform Layer: Traefik, Forward Auth, Backups, Metrics
The README enumerates four elements that make up the platform itself. Automatic SSL-secured access to all services with LetsEncrypt, documented under the Docker Swarm Traefik path. An SSO and authentication layer via traefik-forward-auth, described as protecting unsecured or vulnerable services. Automated backup of configuration and data, with ElkarBackup named as the recipe. Monitoring and metrics collection, graphing and alerting, with Swarmprom named. This is the part of the project with the most substance, because it addresses the failure modes that bite self-hosters after the initial setup works: certificates expiring, an internal tool exposed without auth, no backup until the disk dies, no visibility until something is slow. The recipes for applications (AutoPirate, Plex, NextCloud) sit on top of these. Note that the SSO layer is specifically a forward-auth proxy in front of services that lack their own authentication, which is a different approach from configuring each application's native login. That choice centralises access control but also means the proxy becomes a dependency for reaching those services.
Getting Started: Where the Commands Live
The README does not contain installation commands. It contains links. The entry points are the Docker Swarm design page at geek-cookbook.funkypenguin.co.nz/docker-swarm/design and the Kubernetes section at geek-cookbook.funkypenguin.co.nz/kubernetes/. Individual recipes are addressed under /recipes/, for example /recipes/autopirate/. Configuration specifics such as Traefik labels, forward-auth middleware settings or ElkarBackup job definitions are inside those pages, not in the repository README. If you are evaluating the project before reading the site, the honest position is that this review cannot quote the exact config keys because the supplied material does not include them. What the README does establish is the reading order: platform design first, then platform components, then applications. Anyone who starts by copying an application recipe will be missing the ingress and auth context that recipe depends on.
Where the Cookbook Model Breaks Down
Documentation rots faster than code. A recipe that shows a compose file or a set of manifests pins an image tag, a set of environment variables and an assumed network layout at the time of writing. Upstream projects rename variables, change default ports and drop deprecated options. The cookbook has a changelog and a blog, which is the mechanism for tracking this, but a reader has no way to know from a single recipe page whether it was updated last week or two years ago without checking. A second limitation is the coupling to a specific orchestrator. If your infrastructure is Nomad, plain systemd units, or a managed container service, the recipes do not transfer. A third is the support model: the README routes questions to Discord and Discourse forums, which are community channels, not an SLA. For a homelab that is fine. For anything with an uptime commitment, the cookbook gives you the shape of a solution and none of the guarantees.
How It Compares to a Compose File Collection
The obvious alternative is a curated list of docker-compose files, of which there are many under the awesome-selfhosted umbrella. The difference is in what each one optimises for. A compose collection gives you a working service in isolation and leaves the surrounding concerns to you. Geek Cookbook inverts that: it treats SSL termination, SSO, backup and monitoring as the platform, and the applications as things that plug into it. That is a heavier commitment up front and a lighter one later, because adding the tenth self-hosted service means following the same ingress and auth pattern rather than inventing a new one. It also means the cookbook is a poor fit if you only ever want one service. Standing up Traefik, forward-auth, ElkarBackup and Swarmprom to run a single Plex instance is more moving parts than the problem requires.
Licence, Maintenance and What It Costs You
The repository is MIT licensed, which permits reuse and modification of the content with attribution and without warranty. That covers the guides themselves; the container images the guides reference carry their own licences, and some self-hosted applications have terms that restrict commercial or multi-user use. The MIT grant here is not a statement about those. On maintenance, the README points to a changelog and blog for recent updates, and the repository's last push is recorded as 2026-08-07, which indicates the content is still being touched. There are no releases listed for the repository, which is consistent with a docs-only project where changes land as commits to main rather than tagged versions. The practical upgrade cost is your reading time each time an upstream image changes, plus the effort of re-validating a recipe against your own environment. The project asks for financial support via GitHub Sponsors or Patreon, and notes that sponsors get access to a pre-mix repository. That is a funding model, not a licence restriction: the MIT content remains available without sponsoring.
Editorial conclusion
Adopt Geek Cookbook if you already understand containers and want a guided path through the operational layer (reverse proxy, SSO, backups, monitoring) rather than a pile of disconnected compose files. Skip it if you want a single installable artifact or a production support contract. Before committing, verify that the specific recipe you need still matches the current upstream image tags and that the Docker Swarm or Kubernetes track you pick is the one still receiving updates.
Community notes