FAQ
Have a general question about Nanos? We answer the most common question below. Can’t find yours? Ask our community!
How does Nanos compare to Linux?
Linux is a general purpose operating system designed to run on actual hardware. Nanos is a single process operating system designed to run as a virtual machine and has no support to run on hardware. Linux is designed to run multiple processes with multiple users and has full interactivity support. Nanos has no support for users or running multiple processes. Nanos fulfills a portion of the Linux syscall interface to run linux applications natively.
How does Nanos compare to containers?
Containers are pieces of the linux kernel and share a common kernel when provisioned on the same system. This makes them widely insecure compared to a virtual machine. The biggest problem with containers is that gaining access to one usually means access to the entire infrastructure.
How does Nanos compare to other unikernels?
Glad you asked. We stole this quick table from https://github.com/cetic/unikernels:
| Unikernel | Language | Targets | Functions | Orchestration Avail? |
| ClickOS | C++ | Xen | Network Function Virtualization | |
| HalVM | Haskell | Xen | ||
| IncludeOS | C++ | KVM, VirtualBox, ESXi, Google Cloud, OpenStack | yes | |
| MirageOS | OCaml | KVM, Xen | RTOS/MCU | |
| Nanos | C, C++, Go, Java, Node.js, Python, Rust, Ruby, PHP, any, etc | QEMU/KVM, XEN, ESXi, Amazon EC2, Google Cloud, HyperV, Oracle, RPI4 | cloud, edge | yes |
| OSv | Java, C, C++, Node, Ruby | VirtualBox, ESXi, KVM, Amazon EC2, Google Cloud | Cloud and IoT (ARM) | yes |
| Rumprun | C, C++, Erlang, Go, Java, JavaScript, Node.js, Python, Ruby, Rust | Xen, KVM | ||
| ToroKernel | FreePascal | VirtualBox, KVM, XEN, HyperV | dedicated to run microservices | |
| Unikraft | C, C++, Rust, GO, Python etc. | KVM, XEN, Linux | Yes |
Another big difference is that Nanos keeps the kernel/user boundary. In our testing removing the large process to process context switching that general purpose operating systems still removes quite a lot of the pereived cost in other systems. We keep the internal kernel <> user switch for security purposes. Without it page protections are basically useless as an attacker can adjust the permissions themselves with privileged instructions.
Why don't I get the same benchmarks as you?
Benchmarks can vary widely depending on a variety of factors. For some platforms and some languages we are much faster than Linux while for others we have work to do. For instance KVM via Google Cloud works great for Go applications but the JVM on AWS is currently slower. Likewise just because networking throughput might be good doesn't necessarily mean I/O writes are as good. Different hypervisors utilize different drivers and we can have varrying support for those. Additionally certain languages utilize certain features we might have gotten to run but not have fully hashed out. Most of our tests are currently targeting 1 vCPU but we plan on having more SMP targets in the future. To be as transparent as possible we plan on including automated test results in the near future. When running your own benchmarks it is necessary to be precise on what you are testing. Be careful to use the same instance size tested from the same class c network and same region for instance.
Does this work under Kubernetes?
Yes, but we caution users to evaluate if you really need kubernetes. Chances are you don't and you will experience severe performance and security problems if you choose to run under k8s. If you still find you must here are instructions for running Nanos under k8s.
Doesn't this require the same complexity as Kubernetes or other platforms?
Great question - no! The complexity that comes with kubernetes is that it requires you to re-invent all the layers of a cloud platform that already exists. If you run a vanilla linux instance on AWS you get out of the box: networking, storage, security, routing, etc all for free. Compare that to the cloud native world where every layer has to be replicated. It's a common misconception that Nanos needs to be provisioned on top of a linux instance. The underlying hypervisor might be running linux but if you are running on something like AWS or Google Cloud we provision the unikernel as it's own ami/disk image with no linux in it. So you get to reap all the same benefits that you get of running normal linux instances with the isolation, performance and security of Nanos unikernels.
Does this Work for My Mac M1 or M2?
The Apple M1 and M2 are ARM based. OPS is built for users primarily deploying to x86 based servers. We now have full support for running native ARM applications (ELFs) on M1 and M2s natively. That means without relying on Rosetta and with full hardware acceleration.
Be aware that if you wish to deploy your applications to x86 servers you'll need to re-build your images as x86 versus the default of arm64.
Why Doesn't Nanos Have Users?
Nanos is not Linux. Nanos has no users because it only can run one single program. Users make a lot of sense on Linux because Linux is designed to run many different programs by many different users. This prevents one program running by a different user from interfering with another program from another user. Instead of having a general purpose operating system such as Linux handle users and programs Nanos opts to shift that burden onto the hypervisor/cloud itself. This also means that you can't SSH into a Nanos instance or run any commands in a shell. You can code this functionality into your unikernel if you so desire but you still won't be able to 'shell out'. To further drill into this, it also means there is no 'interactivity' with the unikernel other than what you expose it to over the network. While some cloud providers can have their serial console exposed there is no TTY or way to send it commands. The program is running or it isn't.