Production or development repository?

[TimoGlastra]

When this repository was created my assumption was this repository would focus on production deployments of an ACA-Py mediator.

The readme currently mentions:

This repository provides a simple process for a developer to run an Aries mediator agent.

This leads me to believe the repo is more focused on launching a mediator quickly for development purposes. The usage of Ngrok also seems focused on a developer setup rather than a production mediator deployment.

So my question is mainly, is this repository focused on production deployments, or should we create another repository?

[TimoGlastra]

cc @ianco @swcurran @jleach @reflectivedevelopment

[swcurran]

IHMO it's intended for production deployments. That part should be updated, and while there can be some docs about development usage, there definitely should be a primary focus on production.

[KimEbert42]

I have a pending pull request to split out ngrok vs non ngrok use https://github.com/hyperledger/aries-mediator-service/pull/34

[jleach]

Outside of scrappy startups docker-compose isn't how one would deploy production infrastructure. That battle was won by Kubernets. I don't know if modifying the docker-compose stack for this purpose will be helpful for production deployments. If we want to take it in that direction then I propose we add a Helm chart, OpenShift deployments (since BC, ON, and QC all use OCP) and k8s manifests but keep the docker-stack super simple for developers to get something running that just works.

EDIT: There are also some interesting firewalls rules that need to be axed on Azure that would be useful to document for production use.