I agree 100% in your approach. Specially when we have access to VM with 48 dedicated cores and almost 200GB of RAM for less than €500/month.
If you go beyond that, you have really into something.
[0]: https://www.hetzner.com/dedicated-rootserver/matrix-dell-mob...
You could run your own vm solution like proxmox as well on the bare metal, takes 10 minutes to install locally.
VM's are quite scalable, especially if you can scale vertically, and they massively reduce complexity.
How do you make use of all the 48 cores and the RAM available to you? (I’m genuinely interested so please ignore any snarky tone if any)
In my case, I use Ruby on Rails, so I configure Puma based on the number of cores that I have to set the workers (threats). Not yet, but I will use Redis for caching. It is also an "in-memory" database.
Best practices are a funny thing, understanding where they come from and who they were intended for an go a long way in having a better context.
The first is the broad question of "how will any app (regardless of the technology) saturate that much hardware", and to that I simply say it won't; it will saturate -something- first (with enough load), be it RAM, CPU, network I/O, disk I/O, etc, which will limit utilization of the rest. If this was your own datacenter you might try and "right size" to that, to try and have as little unused hardware capacity as possible, but in the cloud you don't (can't) do that.
The second is maybe more what you're trying to ask, which is given that node is single threaded, you would only be using one core, and that would implicitly also limit how much of the other resources you can use. To that, you'd use something like PM2, a node native utility which essentially spins up multiple instances of your app locally, and load balances across them, or the cluster lib, a less feature rich solution to the same problem, but supplied as part of the standard library.
The point I take from gp’s comment is, there’s a lot of room to scale within a single instance when the nano-sized VM you started with is overwhelmed. Focus on the things that cause growth first, then add complexities of distributed computing when it is actually needed.
Boring answer: use a pool of threads (or subprocesses, like Apache) to deal with web requests. Without stupid locking, many concurrent requests can be handled for each core. If you don't know your QoS targets, how many threads you need to meet them, and how much memory each thread requires it's a serious red flag.
Pragmatic answer: do you want to invest in fault tolerance and being able to upgrade your application? Then you need a load balancer to route traffic to multiple instances and switch them on and off properly, and a good load balancer is going to be outside your VM and probably a specific piece of hardware, irrespective of clever techniques in your application.
That said, one place I worked had a legacy Python service on 16+ core machines. We happened to deploy with dpkg, apt, and docker (I wouldn't necessarily recommend this), and the start script spun up cpu count - 1 instances with CPU affinity set. There was something like nginx for routing out in front.
--Edit also node.js now has Workers e.g for instances where you need to do CPU bound work. Remember node.js is really fast. most apps out there won't be able to use it to the max.