Do you want your ad here?

Contact us to get your ad seen by thousands of users every day!

[email protected]

The Cloud Evolves and Meets Unikernels: Quarkus superfast on Nanos Unikernel

  • April 10, 2026
  • 4 min read
Likes ...
Comments ...
Table of Contents
The Cloud Evolves and Meets Unikernels: Java and Quarkus on ARM64 AWS Graviton with Nanos UnikernelJava and Jakarta EE Truly Meet UnikernelsFrom Virtual Machines and Containers to UnikernelsProof of Concept OverviewArchitectural Diagram of the PoCContainers vs Unikernels: A Stack ComparisonQuarkus, Semeru, and Nanos on AWS Nitro GravitonAWS Nitro: Cloud-Native Capabilities Without KubernetesHypervisor IndependenceWhy This Matters for Java and Jakarta EEConclusion

The Cloud Evolves and Meets Unikernels: Java and Quarkus on ARM64 AWS Graviton with Nanos Unikernel

image

Java and Jakarta EE Truly Meet Unikernels

The key message of this article is simple and strong:

any Java or Jakarta EE application is already ready to benefit from the advantages of unikernels.

Java and Jakarta EE, including modern frameworks such as Quarkus, can immediately take advantage of the unikernel model without waiting for new languages, new runtimes, or radical rewrites.

With Nanos Unikernel, Java applications run unchanged: the JVM is not modified, the application is not rewritten, and the well-known Java promise of write once, run anywhere remains fully valid — even in a unikernel environment.

This represents a major shift: unikernels are no longer a research topic or a niche experiment, but a first-class deployment target for enterprise Java workloads.


From Virtual Machines and Containers to Unikernels

Cloud-native Java applications have traditionally been deployed on virtual machines and, more recently, inside containers orchestrated by Kubernetes. While containers brought improvements in portability and density, they also introduced additional layers of software complexity.

Unikernels remove these layers by compiling the application and its required runtime components into a single-purpose, minimal image that runs directly on a hypervisor.

With Nanos Unikernel, this model becomes practical for Java and Jakarta EE workloads.


Proof of Concept Overview

Reproducibility and Artifacts

For this Proof of Concept, all the build and deployment steps are fully reproducible.

The artifacts used are publicly available and were generated by the GitHub Actions workflow:

These artifacts include the packaged Quarkus application and the IBM Semeru Runtime bundled for execution on Nanos Unikernel (ARM64).

Local Build and Image Creation

In the local environment, the Nanos unikernel image for AWS ARM64 was created using the following command:

ops image create \
  --imagename quarkusNanosArm64 \
  --package AngeloRubens/SemeruJREarm64Linux:25.0.1 \
  --arch arm64 \
  --nightly \
  -c configAws.json \
  -t aws

This step produces a bootable Nanos unikernel image containing:

  • the Quarkus application
  • the unmodified IBM Semeru Runtime (OpenJ9)
  • the minimal Nanos kernel required to run on ARM64

Instance Creation on AWS

Once the image was created and uploaded, the EC2 instance was launched directly from the unikernel image using:

ops instance create \
  quarkusNanosArm64 \
  --arch arm64 \
  -c configAws.json \
  -t aws

This workflow highlights a key point of the article: Java applications can be deployed as unikernels without introducing container images, container runtimes, or orchestration layers.

This article builds on the original Foojay article, where the application image was executed on Oracle Cloud Infrastructure (OCI). The goal of this Proof of Concept is to demonstrate that the same Nanos Unikernel image can be deployed on a different cloud provider and hypervisor without modification.

PoC Environment

  • Cloud provider: AWS
  • Instance type: t4g.small (ARM64)
  • CPU: AWS Graviton2
  • Hypervisor: AWS Nitro
  • Unikernel: Nanos (ARM64)
  • Runtime JAVA: IBM Semeru Runtime 25 for Arm64
  • Framework: Quarkus

This demonstrates that Nanos unikernels are hypervisor-agnostic and cloud-independent.


Architectural Diagram of the PoC

image

The application runs as a single unikernel image directly on top of the AWS Nitro hypervisor, without a guest operating system, container runtime, or Kubernetes node.


Containers vs Unikernels: A Stack Comparison

image

Container Stack

  • Hardware
  • Hypervisor
  • Guest Operating System
  • Container Runtime
  • Container Image
  • Java Runtime
  • Application

Unikernel Stack

  • Hardware
  • Hypervisor
  • Unikernel (Application + Runtime)

By removing unnecessary layers, unikernels reduce boot time, memory footprint, and attack surface.


Quarkus, Semeru, and Nanos on AWS Nitro Graviton

image

Quarkus is particularly well suited for this model thanks to its fast startup and low memory usage, while IBM Semeru provides a production-grade OpenJDK runtime. Combined with Nanos, the result is a highly efficient Java unikernel.


AWS Nitro: Cloud-Native Capabilities Without Kubernetes

AWS Nitro, like all modern hypervisors, already provides many of the foundational capabilities often associated with Kubernetes:

  • Strong isolation and security boundaries
  • Elastic scaling at the VM level
  • High-performance networking and storage
  • Hardware offloading for I/O and virtualization
  • Integrated observability and telemetry
  • Native IAM integration

Because these features are built directly into the cloud infrastructure, there is no technical requirement to add additional orchestration layers for many workloads.

Running Java applications as unikernels allows teams to:

  • Exploit hardware more efficiently
  • Reduce operational complexity
  • Lower infrastructure and operational costs

Hypervisor Independence

In the original article, the application image runs on the Oracle OCI hypervisor. In this Proof of Concept, the same image runs on AWS Nitro.

This confirms that Nanos unikernels are not tied to a specific cloud provider or hypervisor. The same Java application can be deployed consistently across environments.


Why This Matters for Java and Jakarta EE

Java and Jakarta EE can benefit today from unikernel advantages:

  • Faster boot times
  • Smaller memory footprint
  • Reduced attack surface
  • Simpler deployment model

Most importantly, this comes without changing existing applications or the JVM.

Unikernels with Nanos represent an evolutionary step, not a disruptive rewrite, for the Java ecosystem.


Conclusion

The cloud is evolving, and unikernels are becoming a practical deployment option for real-world workloads.

With Nanos Unikernel, Java, Jakarta EE, Quarkus, and IBM Semeru Runtime can fully exploit modern ARM64 cloud platforms such as AWS Graviton2 and the Nitro hypervisor — today, without compromise.

Reference:

The poc on aws Free Tier t4g.small until 31-Dec-2026: http://3.127.237.11:8080/index.xhtml

FooJay Link: https://foojay.io/today/java-jakarta-ee-and-the-evolution-of-the-cloud-with-nanos-unikernel/

Nanovms Link: https://nanovms.com/

Semeru JRE Repo ops nanos package https://repo.ops.city/v2/packages/AngeloRubens/SemeruJREarm64Linux/25.0.1/arm64/show

  • April 10, 2026
  • 4 min read
Likes ...
Comments ...

Do you want your ad here?

Contact us to get your ad seen by thousands of users every day!

[email protected]

Comments (0)

Highlight your code snippets using [code lang="language name"] shortcode. Just insert your code between opening and closing tag: [code lang="java"] code [/code]. Or specify another language.

No comments yet. Be the first.

Mastodon

Subscribe to foojay updates:

https://foojay.io/feed/
Copied to the clipboard