Robur's blog - Autoscaling MirageOS unikernels in Mollymawk
Back to index
Autoscaling MirageOS unikernels in Mollymawk
2026-07-28<br>OCaml<br>Mollymawk<br>Albatross<br>DNSvizor<br>Autoscaling<br>MirageOS<br>In our quest to build robust opensource tools that let users deploy their own infrastructure, we have recently tackled one of the most critical features for any modern hosting environment: Autoscaling .
It is now possible to automatically scale MirageOS unikernels up and down in response to real-time metrics, such as CPU load. In this article, we'll explore a little what that looks like in mollymawk.
1. Zero-Agent Metrics Collection via Albatross
Traditional autoscalers require running a heavy telemetry agent (like telegraf or prometheus-exporter) inside the guest OS. In a MirageOS unikernel, we want to keep the guest image as minimal, secure, and fast as possible.
The autoscaling process starts with Albatross, which collects resource usage metrics (e.g rusage counters, CPU time, and throughput counters from the virtual network devices assigned to the unikernel) directly from the host system for each running unikernel. Albatross then provides a continous stream of statistics which clients can subscribe to. Mollymawk is one of such clients. Mollymawk performs calculations (such as CPU load) from these statistics and keeps track of the data in-memory for each unikernel (and its clones).
Once these statistics arrive mollymawk, it calculates the cpu load of the unikernel to determine if to scale up, scale down or leave it be. Before mollymawk can act on the unikernel, the user has to setup a scaling policy for the unikernel. In this way, users have full control of how their infrastructure is handled.
2. Configuring Scaling Policies
Autoscaling behaviour is configured on a per-unikernel basis using Scaling Policies .
In mollymawk, users can configure:
if the unikernel should scale ; and if yes;
the maximum allowed clones mollymawk can create.
All unikernels (which are not clones) have a minimum instance of 1, unless the user explicitly destroys the unikernel themselves.
In the future, we plan to extend these policies to allow users to customize their scaling triggers rather than relying on fixed defaults:
Configurable CPU Thresholds: Allowing users to set custom CPU percentage limits for scaling up or down (e.g., triggering a scale-up at 80% load instead of 90%), as well as adjusting the consecutive check window.
Network Thresholds (Throughput & Bandwidth): Scaling based on network traffic volume (bytes/sec).
Multi-Metric Triggers: Combining CPU, network, and resource metrics so that a scale-up action is triggered whenever any monitored threshold is exceeded.
Note:<br>scaling policies are directly related to the users usage policy. if a users usage policy allocates them 15 unikernels in total, then they cannot configure a policy which allows any unikernel to scale more than 15 instances.
3. The Cluster Manager
At the heart of the system is the Cluster manager. The manager organizes unikernels into Groups consisting of:
A Primary unikernel : the main instance which has the scaling policy.
Zero or more Clones : spawned on-demand, following the naming scheme -clone-.
The manager evaluates the group's health as follows:
It calculates the average CPU usage across all active instances (primary + clones) in the group.
If the average CPU load exceeds 90% for a number of consecutive checks (currently 3), then a scale-up action is triggered and a new clone is deployed. We use consecutive checks so that mollymawk doesn't execute scaling decisions based on isolated spikes.
If the average CPU load falls below 40% for a number of consecutive checks (5), then a scale-down action is triggered and one of the clones is destroyed.
Ghost Clones: When Mollymawk restarts, its in-memory tracking is lost. To handle this, when statistics arrive for clones that already exist in Albatross but are missing in Mollymawk's cluster manager, the manager dynamically registers them on-the-fly ("ghost clone" tracking) so they immediately participate in scaling decisions.
4. Scaling operations
For the purpose of this article, we use the HTTP benchmarking tool called wrk to increase the cpu load of our test unikernel.
Usage: wrk<br>Options:<br>-c, --connections Connections to keep open<br>-d, --duration Duration of test<br>-t, --threads Number of threads to use<br>[truncated]
With this tool, we can for instance stress the url http://10.0.0.x with the command:
wrk -c400 -d300s -t4 http://10.0.0.x
We have deployed a unipi unikernel called blog. Unipi is a MirageOS unikernel that provides the contents of a git repository via HTTP and HTTPS.
We use DNSvizor for dynamic IP registrations. DNSvizor is a unikernel which listens for DNS requests and DHCP requests in a local network.<br>For this test, we have deployed DNSvizor (with IP 10.0.0.6) and the domain name .service, so any unikernel which requests for a DHCP lease will get the hostname: .service.
We...