Not sure why the author insists on "exactly one" server. You can easily also host a SQL server in the same datacenter (or even run a SQL server on the same server!). This was how most web apps were built before the other options existed.

It is trendy nowadays to just use SQLite for a single server claiming speed advantages, but there are disadvantages as well. In my last startup, our SQL server was not directly connected to the Internet, isolating it from potential hackers.

> Not sure why the author insists on "exactly one" server.

I believe the assumption is, if you need more than one server, using containers (option #4) is a better solution in general. Obviously this is not exactly true for your 1 server for app, 1 server for SQL server scenario, but might make sense for most setups.

In my experience this is pretty common for databases only to be accessed via local host. We had our office ip whitelisted, but now some database clients (datgrip, dbeaver…) can ssh tunnel to access. Plus phpmyadmin is still no uncommon..

Cloudflare open sourced workerd, the workers runtime. [0]

Of course there is more to the platform than just that, but your code isn’t exactly unportable anyway.

[0]: https://blog.cloudflare.com/workerd-open-source-workers-runt...

Option #4 will give you autoscaling without having to deal with k8s.

IIRC all of the options listed still involve writing a Dockerfile, though. Render.com, Cyclic.sh, and Railway.app are also in that category(ish) but will automate the build more like Heroku. (this is off the top of my head, please correct if I misremembered anything)

I quite like Docker. It solves the "it works on my machine" problem by being reproducible-enough. And I can still run it locally.

My argument is not against innovation but against mindshare capture by platform capitalism.

The problem with deploying using Docker is that you no longer have any of the advantages of Docker, unless you count a Dockerfile as an advantage. But it’s really just a non-standard way to write shell scripts to configure a system.

Deploying using Docker containers means hosting multiple nested operating systems on multiple separate hardware, and then trying to coordinate them, when you most likely actually want them living on the same machine sharing the same loop back interface (like you have during development) or on the same physical or at least logical network with a hardware firewall between them. Instead, when you deploy Docker containers to the cloud, they are on different machines (often in different data centers) connected only by a VPC with only primitive software firewalling and no way to monitor the traffic.

Docker is meant to run isolated systems together, to share resources. You get none of that benefit. But the hosting provider does, at your cost.

fly.io can construct the dockerfile and shenanigans for your source code tree, last i saw.

Yes, it can autodetect your framework and generate a basic Dockerfile.

Writing a Dockerfile is not harder than deploying to a bare metal server anyway.