Ansible support has build in Ansible support. This is a function that we will continuously improve and extend. Feedback for this (or any other part of qbee) is highly appreciated.

Using qbee and Ansible as complementary systems has state based automation and configuration management included. So why does it need Ansible support?

The answer is rather simple: Security functions such as system users and passwords, firewall settings and ssh keys profit a lot from being state based. If a device is added to a group later or a device is exchanged with a spare part it will automatically receive the latest user settings, ssh keys and firewall settings automatically. This will make it perfectly configured and secure. qbee allows also more advanced functions to be deployed thorugh its configuration engine. However, if a certain complexity is reached we agree that Ansible might be a simpler and more flexible alternative. Therefore we want to add the possibility to use Ansible playbooks in addition to the build-in qbee functionality. The value add qbee delivers here is that Ansible is dirstributed through the secure qbee communication channel that can work across firewalls and NAT settings (or even proxy servers).

So how does the architecture look like? The local qbee-connect application abstracts the ssh connection through the qbee server to a virtual port. This virtual port is mapped into the Ansible inventory tree.


Connecting devices with qbee-connect makes them accessible within the Ansible Inventory directory. Thus, qbee can play out playbooks to the remote hosts without needing any direct ssh connection.

For more information please see our use case example Ansible through