These are really good observations and probably points to us needing to add some clarity.

I think the thing we could explain better is we take the docker-compose and use that as a starting point to define how an application will run in Kubernetes. We aren't just running Docker when environments deploy, we're running applications in K8's. We've debated long and hard about how much K8's we expose to customers. We tend to think it's complex and if we can abstract the complexity so our customers don't have to worry about it, that would be better. Interested to know what people think about how much K8's we should expose.

The reason we choose to create a new YAML file was we needed a way to define environments. docker-compose does have some stanzas for environments but they were meant for Swarm and the older versions of compose didn't map well to K8's. This file is automatically generated and attached to an application so you don't have to write it by hand, just update pieces that apply to environments. There is definitely duplication with docker-compose in this file, we may end up migrating towards just using docker-compose with the Swarm environments definitions but we haven't seen anyone using those yet.

We're working on a few solutions to seed data and database cloning. It's a really big request and will be added very soon. We do have a few ways to do it now, but they are more one-off solutions than products at the moment. Same goes for testing. We've purposefully not tried to be a CI/CD replacement at the moment. Most of our customers are already using Jenkins or Circle so we decided to integrate for now. We are going to add simple test running soon.