We used docker-compose as a starting point because we were thinking along the same lines. In order to orchestrate the deployment of a complicated app, docker-compose became a much smaller part of solution; docker-compose is helpful for getting some partial service definitions created, but there is so much more to deploying environments.

We are a full CI/CD platform with the ability to do static javascript builds, build-x builds, installing in our customers clusters, installing in their customers clusters, dealing with routing for ephemeral environments, creating pools of resources for ephemeral environments to attach to, deploying and monitoring production environments, a workflow engine and we are just getting started!

We do run into objections along the way like, "can't a couple of people do this pretty easily", but depending on what you want to do, it grows in complexity quickly. A lot of time teams don't realize that until they are way down the path of trying to create a system like this.

If you have any specific questions about how ReleaseHub works let me know, happy to answer anything!

I found that making the container was trivial, but deploying it using the AWS Container Orchestration Service or Fargate was not. Tons of configuration options, and security never seems to work right out of the box.

> that can't be easily solved by docker-compose?

Docker-compose only runs on my (your) laptop. What if you want to share that with someone else? I have to git stash, checkout a branch, tell someone else to do all that... I think you're on the right idea: it's "easy" to do with existing tooling, but there's a big gap between it's easy to do and then go and spend the time to do it.

> describing pretty trivial using docker containers

It is important to understand trivial doesn't always mean fast and easy. Also "easy" is a matter of perspective.