When it comes to integration, we have some docker-compose files we will be releasing later today for launching gaia on localhost for any operating system running docker for the develop branch.
This will run gaia on the localhost os. Thus, gaia hubs can be hosted on any vm that runs any operating system that supports docker, and can be tested per the docs running:
curl https://hub.example.com/hub_info | jq with a successful response per the docs (jq isnt required obviously)
the gaia hub will be listening on port 80
The localhost or, in these docs above, hub dot example dot com, will be replaced with you FQDN, and your configuration of ssl, usually passing 443 to port 80 that will be launched per the docker files. The new docker files support the develop branch with a reader and sidecar configuration.
The develop branch is designed to be enable to rconfiguring the config files to change drivers, ports etc for easier configuration from a developer or user standpoint.
You can do the same with the master branch configuration while setting up your own ssl terminus with your FQDN.
We will be releasing images that can be then deployed on vms for various clouds, but the docker-compose files are made to support local host from any os, so they by design support users hosting gaia hubs locally, or any os running on any vm. These same docker-compose files will run on the images we release.
There are many good cloud providers out there, but ultimately the image would have a default os running gaia. Explicitly, we are unopinionated about what os and vm you should run gaia on, and providing image wrappers around gaia would be to accelerate pre configured options for various cloud configurations, but the docker-compose will always support allowing the user to choose what os, and therefore what vm and what cloud, etc.