> At the same time, I would argue that running a single monolithic service on a single (powerful) VPS is more than enough for more cases than people believe. T

> At the same time, I would argue that running a single monolithic service on a single (powerful) VPS is more than enough for more cases than people believe. This is very true and I'm in the same camp as you in that regard but a lot of popular web framework tech stacks include both a web server and a background worker to process tasks outside the request / response cycle. The background worker isn't exposed over an HTTP port. It's a process that uses the same code base / Dockerfile as your web server but runs a different command. It would need to be up during deployments and also get updated to the new version during your deploy. Even with a monolithic app a lot of apps using Flask, Django, Rails, Laravel and others will at least end up having a web + worker, and then you have the usual postgres / mysql + redis too. Then there's also certain frameworks like Rails where you may want to run a separate websocket service that also uses your same code base but runs in a dedicated process to handle broadcasting websocket events. This one would also want to be proxied since it's accessible over the internet in order for it to work. I'd be curious to see what your shell script and overall strategy looks like with the above set of requirements because IMO the above (minus the Rails websocket server) applies to a huge array of apps out there which use the web + worker + db + redis + maybe websocket server combo.