@statik, we have several deployments of osquery of the order of 1000's of nodes. We deploy osquery itself using chef/puppet/ansible/casper, and then those osquery connects to a remote server over TLS. The remote server api and osquery's particular thread model creates a very responsive system at scale - we can typically distribute a new config to 10's of thousands of nodes in about a minute, and distribute queries/get responses in the order of seconds, usually sub-second. Depending on how responsive you need it to be, and how much data you collect on schedule, main trick is in horizontally scaling the TLS server - the flip side of a responsive remote-server-api is that it creates/tears-down a lot of HTTPS sockets, leaving the backend with tons of sockets in TIMED_WAIT state. Nevertheless, standing up a backend is fairly straightforward to get started - just 5 endpoints (/enroll, /config, /log, /distributed_read, /distributed_write). Hope this helps, and inspires confidence in osquery. Full Disclosure, I work for a commercial venture based on osquery as well (www.uptycs.com)