# The cookbook's honest marker is a plain link where there is no recipe > The Self-hosted Cookbook is a directory of docker-compose recipes for self-hosted applications, grouped into category directories with one markdown page each, and it keeps a strict line between what it has tested and what it merely points at. The most useful pages are the ones with a verdict attached, since several entries carry a blunt note about what breaks. **tborychowski/self-hosted-cookbook** — A cookbook, for docker-compose based recipes, for self-hosted applications and services. - Repository: https://github.com/tborychowski/self-hosted-cookbook - Stars: 1,246 · Forks: 64 - Language: Unknown - License: GPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/tborychowski-self-hosted-cookbook ## One link mark separates a recipe from a pointer The index draws a line through its own typography. Applications that have been tested and described get their own page in the repository, and those that have not are marked with an external link instead, pointing at the project's own documentation. That is stated once in the usage notes and then applied consistently, which is why the bookmarks category reads as a mixture: Linkding, LinkAce, Shaarli, Shiori, Cherry, Hoarder, Shaark and Wallabag all have recipes, while Benotes and linkwarden are links with a one line opinion attached. The same split runs through dashboards, where Homarr and Organizr differ in exactly this way, and through the download managers, where all four entries have recipes. A reader can tell in one glance which entries carry the author's own testing. ## Placeholders are left in on purpose, so paste is only half the job The stated aim is recipes you can copy, paste and run, and the usage notes then explain the three things every reader has to fix first. A domain placeholder has to be replaced with your own, credentials such as a username and password have to be filled in, and keys, named in the notes as an application key and a secret, have to be regenerated, with openssl rand -base64 32 given as the way to do it. The reasoning is stated too: those values cannot be filled in for security reasons. That makes the recipes honest rather than convenient, since a compose file pasted verbatim with a shared example domain or an unrotated secret is exactly the configuration nobody should deploy, and the cookbook's own framing, that not every image author documents as well as the best-known one, is really a complaint about documentation quality rather than about images. ## One markdown file per app, filed by category The layout is the navigation. The apps directory holds one subdirectory per category, ad blockers and local DNS, analytics, backup, blogging and content management, bookmarks and read later, cloud and file sharing, contacts and calendars, cookbook, dashboard, database, Docker managers, document managers and download managers, and further categories below. Each application inside gets a single markdown file containing its compose file and notes, so there is no code to build and no compose file at the root of the repository. Two general pages sit outside the apps tree, a getting-started note for docker and compose and a troubleshooting page, which is where a reader is meant to go when a recipe does not behave. The repository also names four other sources it considers worth reading, including a community list of self-hosted software and a subreddit, which is a quiet admission that one index cannot be complete. ## The one line verdicts are the reason to read the index at all Several entries carry an opinion rather than a description, and those are the ones worth the click. A bookmarking alternative to Wallabag is marked as similar but not as good, with more complexity, less usability and no mobile apps. Another bookmark tool is described as clean and simple with a do-it-yourself Docker image, and then as buggy, because archiving fails half the time. The NextCloud cookbook app is called quite good and able to import from a URL for some pages, with longer recipes painful to edit one ingredient at a time. A standalone recipes application is called feature rich and a bit complex, with importing that does not seem to work as well. The email section carries the most concrete warning of all: a mail server that cannot send from Roundcube as an external address such as a Gmail one. ## One database recipe lives in a directory called other Small inconsistencies are the kind of thing a directory-shaped repository accumulates, and this one is visible in the database section. Baserow, SeaTable and NocoDB all have recipes in the database directory, but Budibase is listed under the same heading while its page sits in the other directory. For a human reader that is a harmless detour. For anyone who generates a link, a menu or a script from the index and assumes the category determines the path, one entry in four will break. The same looseness shows in file naming inside categories, where the qBittorrent recipe is called qbit.md and the WatchTower recipe is called watch-tower.md, so filenames abbreviate or change case rather than following the application's own name. ## Email is split into clients and servers, and the pairing matters The email category is the one place where the index is organised by role rather than by application, with a clients group for webmail and a servers group underneath. Roundcube is the only webmail client with a recipe in the repository, while Rainloop, Mailpile, WebMail Lite and Cypht are links, plus two narrower pointers, one to a discussion about running Rainloop inside Mailcow and one to a community Docker image for Cypht. On the server side Mailcow has a recipe and Mailu and Mail-in-a-Box do not. Reading the two groups as a set is the useful move, because the Mailu note about being unable to send from Roundcube as an external address is a client and server interaction, not a property of either project alone, and it is exactly the kind of thing a recipe page would catch and an upstream readme would not. ## Markdown only, with no releases and an empty language field What is in the repository is an editor configuration file, a workflows directory, the licence, the readme and two directories, one for the recipes and one for the general docker notes. There is no package manifest, no build step, no compose file at the root and no test suite, which is exactly right for a repository whose entire unit of value is a page of text. The language recorded on the repository is empty, which is more honest than guessing Markdown, and there are no releases at all, so a recipe cannot be pinned to a tag. What it can be pinned to is a commit, and the last push here is dated 18 August 2026. For a document set that people copy from, that is the versioning model: read the page, note the commit, regenerate your own keys. ## Conclusion The cookbook suits someone self-hosting on compose who wants a known-good starting point for an app before reading its own documentation, and its per-app verdicts are worth more than the recipes themselves. Two things to know before you paste anything: the placeholders are deliberate, so domains, credentials and any key such as a secret or an application key must be regenerated before a recipe runs, and roughly half the index is untested external links rather than recipes. It is not a package, there are no releases, and there is no compose file at the repository root, so what you copy is documentation you read at a given commit. ## FAQ ### What is the Self-hosted Cookbook? A collection of ready-to-run docker-compose recipes for self-hosted applications and services, grouped by category with one markdown page per application, plus general getting-started and troubleshooting notes for docker and compose. ### How do I know whether a cookbook entry was tested? Applications that have been tested and described have their own page in the repository, and the ones that have not are marked as external links instead. Both kinds appear in the same index, so the mark is the only thing telling them apart. ### What do I have to change before running a cookbook recipe? Replace the example domain with your own, fill in your own username and password, and regenerate keys such as the application key and the secret, with openssl rand -base64 32 suggested for the last two. Those values are deliberately left as placeholders for security reasons. ### Does the Self-hosted Cookbook cover every self-hosted app? No, and the index says so by pointing at other sources, including a community list of self-hosted software, the r/selfhosted community, Homelab OS and a curated tools directory. Many entries are external links rather than recipes. ## Sources - [Issues](https://github.com/tborychowski/self-hosted-cookbook/issues) - [License: GPL-3.0](https://github.com/tborychowski/self-hosted-cookbook/blob/master/LICENSE) - [README](https://github.com/tborychowski/self-hosted-cookbook/blob/master/README.md) - [tborychowski/self-hosted-cookbook on GitHub](https://github.com/tborychowski/self-hosted-cookbook) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tborychowski-self-hosted-cookbook