As someone who's done cloud infrastructure professionally, this is the right way to make a project for setting up self-hosted applications. Not writing a bunch of bash scripts and putting them behind some web UI. We have well established infrastructure/config-as-code systems that are the gold standard which runs most clouds out there. Ansible is one of them. That's the right tool for this job and a ton of professionals understand it and therefore can easily contribute improvements for the ones who don't to use. I'm unfortunatrly invested in SaltStack but I wouldn't feel worried to deploy a (well reviewed) project built on Ansible. Then slap a web UI on it if you like but that should be another project that hooks uses this one.
this post was submitted on 15 Nov 2025
224 points (98.3% liked)
Selfhosted
53129 readers
703 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
I need to learn Ansible. Seems like an easy way to orchestrate server 'stuff'
This project was basically how I learned Ansible haha. It is incredibly powerful and this really only scratches the surface
For large server estates it makes things a breeze to manage, that and semaphore.
I used a similar project called Ansible NAS a while back and it’s been working beautifully. I had a problem and had to reinstall the OS on my NAS at some point and this made it a breeze. That project requires Ubuntu and I prefer Debian so I may try this out next time.
This is definitely inspired by ansible-nas! I'd also used it for awhile, and made my own fork to add/fix things since the project has gone a little dormant. I started making so many changes though that I started fresh and it turned it into a whole project of it's own. You can see a list of differences here: https://dylancyclone.github.io/ansible-homelab-orchestration/guides/introduction/
Or copy-pasted:
- Does not require root to run
- Runs containers with minimum privileges (no root unless absolutely necessary)
- Allow any application to have it's name, image name and version overridden (in case of version pinning or running forks)
- Does not modify existing system settings/configuration
- Separates DNS access from external access (for example, access
portainer.example.comon local network without exposing it to the internet) - Notifies the user of breaking changes in an application's ansible role before updating them
- Everything is optional, doesn't install anything except what's configured by the user
- Cleans up networks and containers more gracefully after disabling applications, and ensure nothing is left dangling
- Supports more OSs than just Ubuntu
- Includes suite of tests to ensure clean code and functionality
- All created containers and networks are removed when stopping applications
- Ensures all applications have consistent variable names and settings
- Ensures all applications properly implement DNS and external access settings
- Ensures no port conflicts between applications
- etc
Does it require docker installed and being in the docker group, with the docker daemon running?
Just an FYI, having the ability to create containers and do other docker is equivalent to root: https://docs.docker.com/engine/security/#docker-daemon-attack-surface
It's not really accurate to say that your playbooks don't require root to run when they basically do.
That is very true, I suppose a more accurate way to say it would be the playbook does not need to run as the root user, and can instead use the permissions of a regular user. This lets all the volume mounts be owned by your user, instead of root. I think it's still an important distinction to make though, since by not running the playbook as root, the playbook can't directly change any of your server's settings, and only has the access the user you're SSHing as has.
Yes, this playbook is intended to orchestrate an already set up environment. I know Ansible can easily install and set up docker (using something like the awesome https://github.com/geerlingguy/ansible-role-docker), but I decided against it (at least for now) for two main reasons: Firstly to avoid becoming the root user, and secondly to avoid the Ansible role installing a second version of Docker, causing things to break. I ran into that myself while testing this playbook, where I had set up a Ubuntu VM, told the installer to install Docker during setup not knowing it would install it through snap, then the Ansible playbook would install docker again through conventional means causing a lot of strange problems. So instead I opted to let the user install docker however they'd like and not have any gotchas like "Remember to add --skip-tags="docker" if you installed Docker during OS installation on Ubuntu" or uninstalling their version of docker for them
Awesome improvements! Really nice work. I’ll definitely be switching at some point when I have a reason to mess with it. Thanks for all the extra work you’ve done to improve the fork and gift the project to the commons.
This is probably my lack of Ansible experience here but how are multiple servers setup? Can I specify a different server per application?
You can use host_vars to set different variables per host. You'd still run the same playbook against both hosts, but each has different services activated.
- Make the folder host_vars in the repo root
- Make subfolders for every host with their hostname
- Enable services you want by writing the variables into a yaml file for your host (any file name as long as it ends with .yml
- Write an Ansible inventory for your hosts
- Run the playbook with your inventory
Slightly fancier would be using group_vars instead, you can add a host to multiple groups. Then deploying the same services on a new hosts would simply be adding it to the group
TL;DR: yes
Just from a quick view of the repo, the simplest way to do it would be to look at the playbook.yml and copy all roles you want for a host into a new playbook, say myhost.yaml. Copy not only the roles but all the other keywords as well. Then you go to the inventory and add your hosts where you to execute the playbook against. Then you change the hosts key value in the playbook you made from all to the hosts you added to the inventory.
That is, add your hosts to the inventory, create playbooks for for them and run. That is the easiest. Read up on how to do groups and organizing your inventory to improve it from there.
Great job, thanks for sharing.