Looking at the feedback in the questionare, there are several requests to make provisioning and configuration of KC deployments easier. I was also thinking about this in relation to our testsuite for a while, and whether there should be a separate module for this. Either inside the testsuite module, or possibly even in the projecr root - in case we want it to be usable both by the testsuite (via API) and manually, by people who want to deploy Keycloak and other interacting sevices somewhere in their cloud or kubernetes/openshift cluster. Another option would be to create an entirely separate project (akin to jboss-dockerfiles/keycloak [1] or the Kubernetes Helm project [2]) which could even support multiple versions of Keycloak and other components. Perhaps some install/upgrade wizzards and examples could be put there. Not sure how an external project would be usable with the testsuite though. The question is to what extent these two use cases are even compatible (devops/maintenance vs extensive integration testing). Benefit of combining both use cases would be reusing common stuff (DRY). In the testsuite we currently use 2 different solutions: 1) Integration testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and then manages lifecycle of all components through Arquillian. Additionally there are testsuite-specific server extensions and custom test apps. 2) Performance testsuite uses Maven/Ant/JBossCLI to prepare configurations on local FS and then uses Docker Compose to build and orchestrate the services. The tests then run against a "remote" provisioned system. There is also a PR from Radim Vansa who created a provisioning solution for OpenShift a while ago, which I have yet to review and merge. And we need to add some bare-metal provisioning option for testing in bare-metal labs (probably ansible). I think all of these different solutions could be put under one roof. Maybe something like this: keycloak/ ... core/ adapters/ model/ examples/ ... distribution/ provisioning/ provisioning-api/ provisioner-local/ provisioner-docker/ provisioner-openshift/ provisioner-ansible/ ... testsuite/ integration/ performance/ Or like this, if just inside the testsuite: keycloak/ ... testsuite/ provisioning/ integration/ performance/ The provisioning API would have a simple interface: interface Provisioner { List<String> getConfiguredServices(); void buildService(String service); void startService(String service); void stopService(String service); } Particular provisioner module would the look something like this: provisioner-X/ src/main/ java/.../ProvisionerX.java (wrapper for external provisioning tool or API) resources/... (for exmple jboss-cli scripts, dockerfiles, ansible playbooks, etc.) pom.xml/<profiles>/ server server-db-vendor-1 server-db-vendor-2 ... server-ldap-vendor-1 server-ldap-vendor-2 ... server-cache server-load-balancer client-set-1 client-set-2 client-set-3 ... webdriver-vendor-1/ webdriver-vendor-2/ ... The process would consist of: 1) Configuring required provisioner modules: - user provides connection parameters and credentials if needed (kubernetes/openshift, ssh keys for anisble, etc.) - user provides configuration parameters for services 2) Building required provisioner modules: - building provisioning module will prepare all local artifacts which will be needed for running methods of the Provisioner interface - after module is built the provisioner implementation/wrapper will be runnable directly with Java or indirectly from script (this would be useful the dev-ops scenario) - also the external provisioning tool (such as docker-compose or ansible) will be runnable directly at this point 3) Running the testsuite. The testsuite delegates to the API to spin up or tear down the services as needed. The integration testsuite would default to the `provisioner-local` module which would just contain stuff which is now located in: testsuite/integration-arquillian/servers. But it could be instructed to use a different provisioning module(s). It would be nice if individual services or sets of services could be combined across different provisioners, and if this would also allow for integration of externally provided services such as existing DB servers. That's the general idea. I've brought this up once before but it was never a priority. Maybe it's time to consider it again and let everyone chip in with their ideas. I think this consolidation would be useful at least within the testsuite. It is also kind of related to the microservice-oriented testing approach which I mentioned in my previous post. Regards, Tomas [1] https://github.com/jboss-dockerfiles/keycloak [2] https://github.com/helm/charts/tree/master/stable/keycloak