That shows nginx is, in fact, enabled (i.e. configured to start on boot), which is what I wanted to be certain of.
It is much smaller. Apache has been around longer, does more, and the performance impact of switching is negligible for the vast majority of users.
But, it is not known to be any less reliable (though less testing is inevitable when there are far fewer users).
Virtualmin isn’t the thing that went wrong, though, right? nginx isn’t provided by us, it’s a package provided by your OS, we’re just managing it. Virtualmin didn’t have any trouble starting on boot, right? We’re not trying to troubleshoot a Virtualmin problem here, as far as I know…it’s an nginx issue, maybe something in the nginx systemd unit file (again, Virtualmin does not start nginx on boot…systemd does). Virtualmin does not replace your system components, we manage the ones provided by your OS; it’s a fundamental feature of our products, one of the main reasons Virtualmin exists.
But, it’s quite common for folks to install other application environments on a system with Virtualmin, including NodeJS and Mongo. The way nginx works should not allow those kinds of things to break it, though; one of the features of Apache that nginx is missing, by design, is the ability to run applications in the core of the webserver (e.g. no mod_cgi, no mod_php, no mod_perl, in nginx). Everything gets proxied to. This should mean that problems in NodeJS cannot possibly interfere with nginx.
Look in the journal for the boot where it failed. You can list boots that are in the journal with journalctl --list-boots and then the -b# flag to choose which one to look at. There will presumably be some clues about why nginx didn’t start.