Your web server (which likely also terminates TLS) has to have fastcgi support, you configure the fastcgi and database ports, maybe mount a directory with config files into the container, and that's it.
This would require you to run your containers on Windows servers right? Not much reason to do that anymore.
Instead should just containerize as part of deployment pipeline
I haven't used Docker with WSL2 yet, but in other uses I've found WSL2 extremely fast. As long as you stay within its vhd, file access is ext4-quick. And on my machine running the geekbench cli gave me almost identical results to a native linux install.
It's great for side projects without the limitations of Heroku's free tier. Lots of plugins (Postgres S3 backups, Lets Encrypt certificates) are icing on the cake.
I work on a selection of internal applications and services and we run everything with Dokku. I was skeptical at first because it made initial [legacy code] deployments a bit of a pain, but I’ve been converted. Not sure I’d run everything that way but for small-scale applications it’s a breeze. And because you have to do the sysadmin work yourself it’s a bit more flexible than Heroku.
Hardly seems like Heroku is in the wrong there
[0]: I know this is not best practice, but this is a small project and this is a hack that I fully know the tradeoffs for.
Unless you’re able to create an artifact like a single executable or a Jar but you still need to supervise those and keep them running.
Asyncio really makes a difference here. I also hate that PHP has to spin up with every single request. This is something I have never gotten used to (From my understanding, most Python web frameworks just give you a clear/fresh Request Object, which is so much better even with WSGI (unless you're using WSGI scripts) Much easier to maintain application state this way in my experience. PHP-FPM doesn't exactly solve this problem, I don't think).