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

The cloud has made people forget how far you can get with a single machine.

Hosting staging envs in pricey cloud envs seems crazy to me but I understand why you would want to because modern clouds can have a lot of moving parts.

The cloud has made people afraid of linux servers. The markup is essentially just the price business has to pay because of developer insecurity. The irony is that self hosting is relatively simple, and alot of fun. Personally never got the appeal of Heroku, Vercel and similar, because theres nothing better than spinning up a server and setting it up from scratch. Every developer should try it.

> The irony is that self hosting is relatively simple, and alot of fun. Personally never got the appeal of Heroku, Vercel and similar, because theres nothing better than spinning up a server and setting it up from scratch.

It's fun the first time, but becomes an annoying faff when it has to be repeated constantly.

In Heroku, Vercel and similar you git push and you're running. On a linux server you set up the OS, the server authentication, the application itself, the systemctl jobs, the reverse proxy, the code deployment, the ssl key management, the monitoring etc etc.

I still do prefer a linux server due to the flexibility, but the UX could be a lot better.

> It's fun the first time, but becomes an annoying faff when it has to be repeated constantly.

I have to ask - do scripts not work for you?

When I had to do this back in 2005 it was automated with 3 main steps:

1. A preseed (IIRC) debian installation disc (all the packages I needed where installed at install time), and

2. Which included a first-boot bash script that retrieved pre-compiled binaries from our internal ftp site, and

3. A final script that applied changes to the default config files and ran a small test to ensure everything started.

Zero human interaction after powering a machine on with the disc in the drive.

These days I would do it even better (system-d configs, Nix perhaps, text files (such as systemd units) can be retrieved automagically after boot, etc).

Your example only covers basic provisioning. The additional items mentioned by the parent comment can be a significant investment, both initially and over time.

> Your example only covers basic provisioning.

No. It covered setting up all the applications needed as well (nginx, monitoring agent, etc), installing keys/credentials.

What did parent mention that can't be covered by the approach I used?

I guess I read your comment as OS, the app, and configs, while the parent mentions auxiliary items, ending with "etc etc". The point is, all the extra things that aren't the app take knowledge and resources to set up and maintain.

Sure you can script all the things into 3 steps, just like you can draw an owl with a couple circles.