Had a similar thing at work not long ago.

A newly deployed version of a component in our system was only partially working, and the failures seemed to be random. It’s a distributed system, so the error could be in many places. After reading the logs for a while I realized that only some messages were coming through (via a message queue) to this component, which made no sense. The old version (on a different server) had been stopped, I had verified it myself days earlier.

Turns out that the server with the old version had been rebooted in the meantime, therefore the old component had started running again, and was listening to the same message queue! So it was fairly random which one actually received each message in the queue 😂

Problem solved by stopping the old container again and removing it completely so it wouldn’t start again at the next boot.

You can self-host Bitwarden, and sync your vault to your phone. Maybe not an option for everyone since it requires some technical skills, but very doable.

If you want to make your playbooks/roles more universal, there’s a generic package module which will figure out what package manager to use based on the detected OS.

Or, if that doesn’t fit your needs, you can add conditions to tasks (or blocks of tasks), like

when: ansible_os_family == "Debian"

and use that for tasks specific to a given Linux distro/family.

Ansible will detect a lot of info about each host and make it available as facts. See for example https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_vars_facts.html

No, you give the AIO container access to your docker daemon and it will create / handle / supervise all the other containers nextcloud needs.