[exceptione]

It seems you are right. The OPS documentation mentions that you can deploy it on bare metal, but this is a recent comment [0] that contradicts that .

    right now we don't have any plans to support bare metal
    installs like this as that would imply a bunch of other
    mgmt related tooling that would not be present 
    (eg: start/stop the server, configure networking, 
    deploy a new one, access rights, etc.) it also breaks 
    the assumptions we have that it is only being deployed 
    as a vm which means having to support a ton of random 
    hardware drivers, nanos is intended to always be ran on
    top of a hypervisor of some kind - whether it's public
    cloud or something under your own control 
    (eg: proxmox/vsphere/etc.)

It seems like they make some distinction between true bare metal and somewhat bare metal, which is highly confusing.

___

[0]: https://github.com/nanovms/ops/issues/1522

[sweetjuly]

It's bare metal in the sense that it's self-bootstrapping but the "metal" it supports is only a paravirtualized system. This is what they mean when they say that they don't want to support tons of random hardware drivers: they've written support for KVM paravirt devices (which are nearly universally available on VMs), and that allows the kernel to run on most hosting providers.

[RetroTechie]

So (if I understand correctly):

It minimizes the software stack (and with that: attack surface) that application sits on, inside a VM.

It does not (nor is it expected to) help to minimize said application.

And it does not minimize the software stack that runs the VM.

[convolvatron]

exactly. its an adpater that provides a short path between the applications expectations and what the VM provides.