There are a few ways to approach this. If you don't mind owning the orchestration layer this is precisely what firecracker does.
If you don't even want to pay for that though scheduling unikernels on something like ec2 gets you your full vm, is cheaper, has more resources than lambda and doesn't have the various limitations such as no gpu or timeouts or anything like that.
I agree with you that VMs would provide better isolation. But I do think containers (or other kernel techniques like SELinux) can still provide quite decent isolation with a very limited performance/ease-of-use cost. Much better than nothing I'd say?
I would kinda disagree with this. The whole 'better than nothing' is what gave a huge chunk of people a false sense of security wrt containers to begin with. The reality is that there is no singular create_container(2). Much of the 'security' is left up to the runtime of choice and the various flags they choose or don't choose to enable. Others in this thread have already mentioned both bubblewrap and podman. The fact that the underlying functionality is exposed very differently through different 'runtimes' with numerous optional flags and such is what leads to all sorts of issues because there simply was no thought to designing these things with security in mind. (We just saw CVE-2025-9074 last week). This is very different than something like the v8 sandbox or gvisor which was designed with certain properties.
This is also my impression. Containers aren't full-proof. There are ways to escape from them I guess? But surely it's more secure practically than not using them? Your project looks interesting I will take a look.
Access Control: There is none internally. We don't have the notion of users.
Logging: Keep using whatever you want be it elasticsearch, syslog, cloudwatch, etc. No opinions here.
Debugging: GDB works fine and in many cases since you can simply export the vm in it's entirety and then attach to it locally this becomes even easier to debug than the same application running on linux.
Profiling: We support things like ftrace and of course things like prometheus you can export.
Monitoring: Kinda in the same boat as logging - keep using whatever you are using today - datadog, victoria metrics, etc.
Throttling: This is traditionally an app-level concern that someone would implement at perhaps a load balancing layer - keep using whatever you are using.
Backup/Recovery: Running unikernels make it trivial to backup as you can clone running vms. In fact most cloud deploys involve making a snapshot that is already stored as a 'backup' and makes things like rollback much easier to do.
Command line. Packages. Mounts. File systems. Any standard anything. There's nothing unless you reinvent the wheel. Standardization and repeatability allow reuse of the work of many others. Unikernels throw 99.99% of it away.
Mounts also exist - in fact you can hotplug volumes on the fly on all the major clouds. People really like this cause they can do things like rotate ssl certs every few hours.
The file system exists - at the very least you need to load a program that sits on the filesystem but people are running webservers that write to temp files and load static assets and also databases.
Sorry - just now seeing this. This is a build of PVM that works with Nanos. We're also maintaining that patch set as I don't ever see it getting included into the kernel (not anytime soon anyways).
It doesn't necessarily mean that but yes you most definitely can run native images - another example showing that: https://github.com/nanovms/ops-examples/tree/master/java/07-... . Both of these pair very well with unikernels. Especially quarkus has excellent boot time and low mem usage.
Trivial to spin up a prisma postgres instance and see everything from busybox to a full blown proc including very specific linux flags.
They should clarify which workloads are actually using their kernel vs linux. I suspect most are the latter.