I may be at a place where this would be useful, so I signed up! That being said...
At this point, one-click (or one command or one PR open) pre-production environments are almost table stakes for PaaS offerings. This kind of functionality was the primary reason we moved from self-hosted to PaaS (Pantheon) back in 2012/13 at a prior gig. Heroku (as mentioned in other comments) offers similar functionality these days.
Given you probably won't have much traction with teams who are happy on PaaS offerings like the aforementioned, am I right in thinking your market is either people doing completely bespoke docker stuff (how many of those are there), or people whose apps don't neatly fit (either due to size or complexity) into an existing PaaS offering?
If that's the case, I wonder if docker is the wrong abstraction-point. Perhaps it'd be better to be a glue layer between a VCS and something like a Terraform configuration or a Pulumi project.
I also wonder an open source model could be a winner here, too.
Many PaaS offerings do some version of this, but we're targeting companies who aren't using PaaS. Specifically companies that are in AWS natively (other could providers coming soon). The reason for this is they are the ones who tend to need to build this from scratch and the market for companies in the cloud is... well... huge. They tend to want PaaS features but have to build it themselves. That's where we are headed. There is also a market for those that need to move off of PaaS due to complexity or technical needs that those PaaS offerings don't support. We think this is a sweet spot.
As for Docker, we choose that because it's kind of table stakes now. We didn't initially start here, we were thinking more inline with what you were saying initially about Glue between VCS and Terraform. But as we started engaging with users, it was clear that Docker, and more specifically docker-compose was the starting point because what we lacked was a good definition of the services people wanted to run and we didn't want to invent something new for this. We do see a place for Terraform in the near future in our offering.
We also had the good fortune of running into Ben Firshman (founder of Fig/docker-compose) recently and he told us what we're building is what they had envisioned in the early days building Fig. We just brought Ben on as an advisor to help us think through that vision and to also help us with our open source strategy. Because, as you mentioned, we believe that open source is going to play a critical role in how we evolve this business.
Thanks for the detailed response! It all makes sense, and it sounds like y'all are getting good advice.
My gut take on docker vs. config management came from the trend of IaaS providers moving higher up the chain in the services they offer (it ain't just compute anymore). So spinning up an ephemeral environment that also, for example, had its own SQS instance, or an Aurora DB, or (across clouds) had a Firebase DB or Cloud Scheduler configuration, seems like a very common use-case.
Gotta start somewhere though, and docker's probably a good place to do so.
At this point, one-click (or one command or one PR open) pre-production environments are almost table stakes for PaaS offerings. This kind of functionality was the primary reason we moved from self-hosted to PaaS (Pantheon) back in 2012/13 at a prior gig. Heroku (as mentioned in other comments) offers similar functionality these days.
Given you probably won't have much traction with teams who are happy on PaaS offerings like the aforementioned, am I right in thinking your market is either people doing completely bespoke docker stuff (how many of those are there), or people whose apps don't neatly fit (either due to size or complexity) into an existing PaaS offering?
If that's the case, I wonder if docker is the wrong abstraction-point. Perhaps it'd be better to be a glue layer between a VCS and something like a Terraform configuration or a Pulumi project.
I also wonder an open source model could be a winner here, too.