Personally, I wouldn&#x27;t use unikernels for my custom app-tier code† (unless my app-tier either <i>was</i> Erlang, or had a framework providing all the same <i>runtime infrastructure</i> that Erlang&#x27;s OTP does.)<p>Instead, unikernels seem to me to instead be a good way to <i>harden</i> high-quality, battle-tested server software. Of two main kinds:<p>• Long-running persistent-state servers that have their own management capabilities. For example, hardening Postgres (or Redis, or memcached) into a unikernel would be a great idea. A database server already cleans and maintains itself internally, and already offers &quot;administration&quot; facilities that completely moot OS-level interaction with the underlying hardware. (In fact, Postgres often requires you to <i>avoid</i> doing OS-level maintenance, because Postgres needs to manage changes on the box itself to be sure its own ACID guarantees are maintained. If the software has its own dedicated ops role—like a DBA—it&#x27;s likely a perfect fit for unikernel-ification.)<p>• Entirely stateless network servers. Nginx would make a great unikernel, as would Tor, as would Bind (in non-authoritative mode), as would OpenVPN. This kind of software can be harshly killed+restarted whenever it gets wedged; errors are almost never correlated&#x2F;clustered; and error rates are low enough (below the statistical noise-floor where the problem may as well have been a cosmic ray flipping bits of memory) that you can just dust your hands of the responsibility for the few bugs that do occur (unless you&#x27;re operating at Facebook&#x2F;Google scale.) This is the same sort of software that currently works great containerized.<p>---<p>† The best solution for your custom app-tier, if you really want to go the unikernels-for-everything route, might be a hybrid approach. If you run your app in both unikernel-image, <i>and</i> OS-process-on-a-Linux-VM-image setups, you&#x27;ll get automatic instrumentation &quot;for free&quot; from the Linux-process instances, and production-level performance+security from the unikernel instances. You could effectively think of the Linux-process images as being your &quot;debug build.&quot;<p>Two ways of deploying such hybrid releases come to mind:<p>• Create cluster-pools consisting of nodes from both builds and load-balance between them. Any problems that happen should eventually happen on an instrumented (OS-process) node. This still requires you to maintain Linux VMs in production, though.<p>• Create a beta program for your service. Run the Linux-process images on the &quot;beta production&quot; environment, and the unikernel-images on the &quot;stable production&quot; environment. Beta users (a self-selected group) will be interacting with your new code and hopefully making it fall down in a place where it&#x27;s still instrumented; paying customers will be working with a black-box system that—hopefully—most of the faults will have been worked out of. Weird things that happen in stable can be investigated (for a stateful app) by mirroring the state to the beta environment, or (for a stateless app) by accessing the data that causes the weird behavior through the beta frontend.