So sad. So the choice is closed source platform lock-in, a single Linux server with SQLite as database, or kubernetes?
-an old man yelling at the cloud.
-an old man yelling at the cloud.
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.
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.
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...
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)
My argument is not against innovation but against mindshare capture by platform capitalism.
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.
Writing a Dockerfile is not harder than deploying to a bare metal server anyway.