Anyone else just sick of trying to follow guides that cover 95% of the process, or maybe slightly miss a step and then spend hours troubleshooting setups just to get it to work?
I think I just have too much going in my “lab” the point that when something breaks (and my wife and/or kids complain) it’s more of a hassle to try and remember how to fix or troubleshoot stuff. I lightly document myself cuz I feel like I can remember well enough. But then it’s a style to find the time to fix, or stuff is tested and 80%completed but never fully used because life is busy and I don’t have loads of free time to pour into this stuff anymore. I hate giving all that data to big tech, but I also hate trying to manage 15 different containers or VMs, or other services. Some stuff is fine/easy or requires little effort, but others just don’t seem worth it.
I miss GUIs with stuff where I could fumble through settings to fix it as is easier for me to look through all that vs read a bunch of commands.
Idk, do you get lab burnout? Maybe cuz I do IT for work too it just feels like it’s never ending…
If you’ll let me self promote for a second, this was part of the inspiration for my Ansible Homelab Orchestration project. After dealing with a lot of those projects that practically force you to read through the code to get a working environment, I wanted a way to reproducably spin up my entire homelab should I need to move computers or if my computer dies (both of which have happened, and having a setup like this helped tremendously). So far the ansible playbook supports 117 applications, most of which can be enabled with a single configuration line:
immich_enabled: true nextcloud_enabled: trueAnd it will orchestrate all the containers, networks, directories, etc for you with reasonable defaults. All of which can be overwritten, for example to enable extra features like hardware acceleration:
immich_hardware_acceleration: "-cuda"Or to automatically get a letsencrypt cert and expose the application on a subdomain to the outside world:
immich_available_externally: trueIt also comes with scripts and tests to help add your own applications and ensure they work properly
I also spent a lot of time writing the documentation so no one else had to suffer through some of the more complicated applications haha (link)
Edit: I am personally running 74 containers through this setup, complete with backups, automatic ssl cert renewal, and monitoring
I hesitate to bring this up because you’ve clearly already done most of the hard work, but I’m planning on attending the following conference talk this weekend that might be of interest to you: https://fosdem.org/2026/schedule/event/VEQTLH-infrastructure-as-python/
No that’s totally fair! I’m a huge fan of making things reproducible since I’ve ran into too many situations where things need to be rebuilt, and always open to ways to improve it. At home I use ansible to configure everything, and at work we use ansible and declare our entire Jenkins instance as (real) code. I don’t really have the time for (and I’m low-key scared of the rabbit hole that is) Nix, and to me my homelab is something that is configured (idempotently) rather than something I wanted to handle with scripts.
I even wrote some
pytest-like scripts to test the playbooks to give more productive errors than their example errors, since I too know that pain well :DThat said, I’ve never heard of PyInfra, and am definitely interested in learning more and checking out that talk.
Do you know if the talk will be recorded? I’m not sure I can watch it live.Edit: Found a page of all the recordings of that room from last year’s event https://video.fosdem.org/2025/ua2220/ So I’m guessing it will be available. Thank you for sharing this! :DI love the “Warning: This talk may cause uncontrollable urges to refactor all your Ansible playbooks” lol I’m ready
Yeah, self promote away lol
That’s neat. I never gave ansible playbooks any thought because I thought it would just add a layer of abstraction and that containers couldn’t be easier but reading your post I think I have been wrong.
While it is true that Ansible is a different tool that you need to learn the basics of (if you want to edit/add applications), all of the docker stuff is pretty comparable. For example, this is the equivalent of a docker compose file for SilverBullet (note taking app): https://github.com/Dylancyclone/ansible-homelab-orchestration/blob/main/roles/silverbullet/tasks/main.yml
You can see it’s volumes, environment variables, ports, labels, etc just like a regular docker compose (just in a slightly different format, like environment variables are listed as
envinstead ofenvironment), but the most important thing is that everything is filled in with variables. So for SilverBullet, any of these variables can be overwritten, and you’d never have to look at/tweak the “docker compose.” Then, if any issue is found in the playbook, anyone can pull in the changes and get the fix without any work from themselves, and if manual intervention is needed (like an app updated and now requires a new key or something), the playbook can let you know to avoid breaking something: https://dylancyclone.github.io/ansible-homelab-orchestration/guides/updating/#handling-breaking-changes@Dylancyclone @selfhosted This looks very useful. I will study your docs and see if it’s right for me. Thanks for sharing!