Note that both of the setups are quite different in how they boot unikernels. The EoX Zerg demo boots one unikernel per connection by having an HTTP proxy in t

Note that both of the setups are quite different in how they boot unikernels. The EoX Zerg demo boots one unikernel per connection by having an HTTP proxy in the frontend spin up the VM. Magnus' version builds a static set of unikernels whose total resource usage is known ahead of time, and boots them based on DNS lookups as necessary. Because there is a race between a DNS response, the first TCP SYN from the client, and the VM booting up to receive it, there is a helper unikernel called "Synjitsu" which terminates TCP connections and replays them to the MirageOS unikernel as soon as it boots up. This is very easy due to the OCaml TCP/IP stack in Synjitsu sharing its state via serialising it into an s-expression. More gory details in http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf Now, imagine a version of Synjitsu that did this handover with TLS connections rather than just TCP. The recipient unikernel wouldn't ever even have to know the private key, just the ephemeral session key...