The biggest OJS I know is RACO, that holds 540 journals (and growing). But this is kind of tricky because only 10% (max) of this journals are real journals (I mean, doing full workflow in OJS) and most of them are just a copy of external journals. At the end RACO is more a repository than a real journal management system.
With the HW you mention, I’m quite sure you won’t have any bottlenecks.
Thinking in big journals… let’s do some rough numbers:
- Backend is usually managed by a group of 50 people max (editors, section editors, copyeditors, reviewers)… and, in case your journal becomes very popular, increase this with 150 authors… (but it won’t be a problem for 8GB and 4CPUs).
- Critical part with big journals would be the frontend… But ojs includes a caching system out-of-the-box that will let you deal with 500.000 visits daily without any trouble.
- About disk usage: As always it depends of the journals. If it comes with a lot of old numbers and big PDFs full of images you can reach 50GB but will be very strange. My biggest journal is 30GB and it includes galleys and all the documents submitted during the workflow (original, copyedited…). Regular journal is around 5-10GB.
- Most of the installations run over apache, but you can use nginx if you like. You can use any php flavor (php, php-cgi, php-fpm), but for ojs 3.x it need to be, at least, php 7.3 (and I recommend start thinking in php 7.4).
If you force me to tell where the problems would come (if any) I will point NFS… but I think it won’t happen any more with OJS 3.x… I mean, in old OJS versions it used to be DB-intensive but it was fixed in new 3.x branches.
So… I think you won’t have any problem with VM like this or, if you need it, you can reduce it a little based on the size of each journal:
- For big journals: 4 CPU + 4GB ram + 50GB disk
- For regular journals: 2 CPU + 2GB ram + 30GB disk
- For small journals: 1 CPU + 1GB ram + 10GB disk
As an example, I rebuild all our infrastructure with single-tenant ojs (based on docker) and I didn’t made any stress report (yet) but our biggest journals don’t ask for more than 2CPUs and don’t take more than 1GB ram.
About multi vs single-tenant, I like your “downtime” argument… that is also in my list, but I always forget. 
I will open a new post with a wiki page to create a table with the pro/cons of both approaches. Feel free to modify to enrich the conversation.
Cheers,
m.