Hi @NobbZ , thanks for your feedback.
Looking back at what you wrote here, I’m starting to think that excontainers may actually not be a perfect fit for your needs.
Excontainers is mostly useful to spawn short-lived containers to allow running integration tests asynchronously and with good test isolation.
Using it to spawn long-running containers is possible, but not very straightforward.
Of course any suggestion to make it more suitable for your scenario is very appreciated 
Some potential problems I see are:
- we’d need a way to start containers and run migrations (if any) before the application starts, otherwise other processes that depend on these containers could start to break. This may not be a big deal in some cases, as everything could go back to normal once migrations are done, but even then it would still be ugly.
- if you need the container to listen on a specific port on the host (eg. postgres on 5432) then it would be hard to handle multiple instances of your application (eg. one for your local server and the other to run tests / run a REPL). New instances of your app would try to spawn the container and fail due to the port being already taken.
In case of a long-running container shared by the whole test suite, you could start the container and run migrations in your test_helper.exs.
If you have containers under your supervision tree then it could be a little more tricky, as you’d need some way to execute migrations once the process (and hence the container) is started.
This is something that I’ll consider to add.
For now the easiest ways to start a permanent container are either to start it manually in your test_helper.exs or to place {Excontainer.Container, your_container_configuration} under the supervision tree of your app.
