CSS Minecraft (benjaminaster.com)

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?

Comments (14)

krstak · 1h ago

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?

rmdes · 1d ago

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..

dschuessler · 1d ago

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.

ilkhan4 · 1d ago

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.

mmarian · 1d ago

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

jsbroks · 1d ago

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

verdverm · 1d ago

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?

dschuessler · 1d ago

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

verdverm · 1d ago

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

jsbroks · 1d ago

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.

JojoFatsani · 1d ago

They should just use Heroku then

JojoFatsani · 1d ago

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

dschuessler · 1d ago

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

- https://kvmpods.com/

- https://dockerdeploy.cloud/

JojoFatsani · 1d ago

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..