Replacing a $3000/mo Heroku bill with a $55/mo server

The longest is to adapt your app to a Dockerfile-based deployment, if it isn't already containerized. We have examples for most languages - for Flask, for example, the whole file is 10 lines long [0]

But to provision a new server, as these are "stateless" (per 12 Factor) servers, it's just 1) get a VPS 2) install Docker+Disco using our curl|sh install script 3) authorize github 4) deploy a "project" (what we call an app), setting the env vars.

All in all ~10 minutes for a new machine.

[0] https://github.com/gregsadetsky/example-flask-site/blob/main...

Is this really all it takes? I’m curious because for me the value of heroku etc is not the PaaS itself but the infra: hardening the server, load balancing, redundancy, monitoring, alerting, connectivity, storage… and that’s always the hole in the selfhosted PaaS story for me. I’d love to solve it but it’s handwaved every time whenever these topics come up. Any pointers?

It's a good point. I'd say that generally, there are answers to most of these points that either get you 80% of the way there, or are functionally equivalent.

Re Load balancing for example, Disco is built on top of Docker Swarm, so you can add nodes (ie machines) to scale horizontally - `disco nodes:add root@<ip>`

For monitoring/alerting, we offer some real time cpu/memory metrics (ie `docker stats`) and integrate with external syslog services.

Do you have specific use cases in mind which current PaaS providers satisfy? Would you say that these kinds of concerns are what's holding you back from leaving Heroku or others (and are you considering leaving because of price, support, etc.)? Cheers

Yes, I'm missing the part between "spin up a bare metal server with a fresh OS" and "run the PaaS for prod".

How do I harden the server, back it up, etc? Basically the layer below Disco, to go beyond running it as a "toy"

This is not a dig at Disco, I run into the same issue with virtually any other self-hosted PaaS I could find.

No, all good, this is super useful - if you're thinking about this, then it matters to us!

Our philosophy is built on the "cattle, not pets" [0] and 12-factor [1] app methodologies. To some extent, the Disco server itself should be treated as disposable.

Disco runs your applications, which are just deployments of your code (ie git pulls). There's nothing on the server itself to back up. If a server were to die, you'd spin up a new one, run the install.sh script, and redeploy your apps in about 15 minutes.

For application data, our stance is that we believe you should use a dedicated, managed database provider for prod workloads. While we can run a "good enough" postgres as noted, we treat that as a dev/staging tool. Disco handles the stateless application layer, you should entrust your critical stateful data to a service that specializes in that.

Finally, re: security, we recommend a fresh Ubuntu 24.04 LTS server, which handles its own OS security updates. Disco only exposes the necessary web and SSH ports, so the attack surface is minimal by default.

[0] https://cloudscaling.com/blog/cloud-computing/the-history-of...

[1] https://12factor.net/