Ask HN: Would you use a platform that deploys Docker Compose apps? | Hacker News Reader

Ask HN: Would you use a platform that deploys Docker Compose apps?

5 pointsjsbroks14 comments

The idea is simple: you upload any docker-compose.yml, and the platform sets up a full production environment automatically including HTTPS, autoscaling, etc.

It would also work out of the box for open-source apps that use docker-compose so you can deploy tools like Ghost, Umami, or Plausible with minimal setup.

Would this be useful to you? What features would you want for your use case?

View on HN

I would be interested, would even help testing and contribute but the next problem that arise if users had such easy way to deploy apps is, how do you handle backups, migration to new versions, single sign on, there are projects similar to this idea that already go very far, such as https://cloudron.io but they are "limited" in the amounts of apps they can provide with support and quality path for upgrades.

Inevitably, if I had all the apps I want to spin at hands, I would need a very neat way to make sure path to upgrades are smooth, don't break things already in place and potentially used in "production" by either friends of family..

I don't think Cloudron is a good comparison for what the OP is suggesting.

They suggest a platform where "you upload any docker-compose.yml". Consequently, this makes SSO, updates, etc. the user's responsibility.

That's an interesting idea, I would definitely check it out. Personally, I use docker compose for my production business applications. These apps are built as internal business tools, and docker compose is a perfect solution for me.

I also wrote a simple script of how to deploy my apps and it works great. But I would, for sure, like to hear more about your idea. You plan to build someting like that?

I’ve always wondered why something like this isn’t a thing. AWS ECS had a half-hearted feature to deploy docker compose setups but they discontinued it awhile back. We use compose to run our app locally so it would be nice to just deploy that.

Like the other response, my concern would be reliability on a new service, but I’d use it after it was around for a year or two.

I wouldn't, mainly because I don't trust a new platform is secure enough. Chicken and egg situation, I know.

Very good point, building up trust, especially in PaaS its very important

Kubernetes is the standard now, why would I want to use something else?

I've not seen or used a docker-compose that was designed for production settings, it's primarily a dev time tool. Would we not have to maintain a second dc file with different settings?

For one, to use the same tool in local development and in production. For another, because docker-compose is simpler than Kubernetes.

Production is more complicated than development. How would I express rolling updates or ingress with docker-compose?

Why not use Kubernetes for local dev (kind or minikube) instead of trying to make docker compose hacks for production? Docker Swarm is rarely seen, I suspect industry has already settled on k8s as the standard

Working at a large scale I agree that using something like this doesn't make sense. But for indie hackers, small startups, or people wanting to deploy foss, they dont need all the complexities you are talking about. They have a app they want to deploy and generally, as cheap as possible.

They should just use Heroku then

You can run your Kube stack locally.. look into kind, minikube etc.. just exclude your LB configs and stuff from your helm charts and dial down the resourcing

For reference, services trying this (or having tried this):

- https://kvmpods.com/

- https://dockerdeploy.cloud/

You’re going to run into all the “death by a thousand cuts” problems that killed Mesos/Docker Swarm. Compliance, autoscaling, etc.. Then you’ll wish you went with Kobe or ECS..

Reply on news.ycombinator.com