Qubernetes

An attempt at building the world’s smallest data center out of microcontrollers.

Project submission for uOttaHack 8, hosted January 16-18, 2026 at the University of Ottawa.

Inspiration

As our demands for computing skyrocket with the explosion of AI/ML workloads in the cloud, so does the impact on our planet.

While AI/ML may be all the rage nowadays, statistics show that we’re destroying our planet at an alarming rate.

According to The Web unpacked: a quantitative analysis of global Web usage by Cornell University, the overwhelming majority of the modern internet is made up static websites that get very little consistent traffic.

Canada is also projected to fall short of its legislated emissions target set for 2030 by at least 40%.

All is not lost however. Throughout tinkering with firmware development on little ESP32s, we discovered that they’re capable of:

hosting full-blown web servers
serve various HTTP requests (with sane tradeoffs)
running real-time operating systems
orchestrate small workloads
and much more…

We wondered, what if you followed the same best practices and architectures as large-scale data centers, and applied them to microcontrollers?

The high demand for compute paired with the heavy constraints of embedded systems presented a challenge for us that was both hilarious and technically ludicrous.

So we tried applying “data center thinking” (service discovery, health checks, observability, staging vs prod parity) to hardware that has no business doing any of that.

What it does

Qubernetes’ name is inspired by the combination of the names ’QNX’ and ’Kubernetes’. It aims to be a tiny orchestrator / control plane for resource-constrained nodes (MCUs + small SBCs), designed for:

hosting static websites and small internal tools
exposing tiny API endpoints behind stable DNS
routing requests across a “fleet” of heterogeneous devices
keeping services up with health checks + restart policies
making “staging vs prod” less painful (even when prod is a pile of boards on your desk)

Think “baby Kubernetes,” except the cluster might have less storage than a single JPEG.

How we built it

We followed a first principles approach and began by addressing problems we faced ourselves, such as:

Hosting our own websites
Having API endpoints behind domains we could hit infinitely without incurring cloud costs, and closing the gap between production and staging environments
File conversion without the wait times and limited usages

We also

Reverse proxy + clean domains so we weren’t memorizing IPs
Raspberry Pis run the heavier stuff (dashboards, routing, infra glue), Container orchestration on SBCs
Docker Compose via Dokploy to ship faster
Worked on DNS + naming conventions so the fleet could scale without becoming a spreadsheet nightmare
Did firmware work targeting QNX RTOS for the embedded side
Treated MCU services as “deployable units” with strict budgets (RAM/flash/network)

QNX Metric Gathering

Running a custom C-based HTTP server on a QNX device that parses real-time system and buffers them in memory. This server exposes a Grafana-compatible JSON API, allowing the dashboard to visualize historical CPU and memory data directly without needing an external database or correct system time.

Minecraft on QNX Pi

Ported a Rust based Minecraft server into QNX and got it running to allow multiple people to join from within the same network

Challenges we ran into

We had the following hardware in stock:

Microcontrollers
- ESP32-S3-DevKitC-1
- Seeed Studio XIAO ESP32-S3
General-purpose Servers

These microcontrollers have a very limited amount of flash memory (8-16MB).

That “8–16MB flash” budget means:

you don’t “just add dependencies”
you don’t “just log everything”
you don’t “just ship a bigger binary”

You get one shot, and the MCU will absolutely humble you.

While the Raspberry Pi 4B and 5 series punch way above their weight in terms of how many containers they’re able to host, the Zero 2W series would regularly overheat to 65°C and shut down; thus requiring us to install heatsinks onto them with thermal paste.

Other issues we had:

Network debugging
Provisioning DNS locally
- Corrupted images due to human error while flashing SD cards
- Namespacing hosts on our fleet in a manner that allowed us to scale without having to memorize IP addresses

Accomplishments that we’re proud of

Using existing open-source tools to bring our idea to life with the least amount of effort for the most amount of impact.
Actually using it for our own needs.
- Curbing network architecture complexity with diagrams.
- Recognizing areas of high complexity early, and splitting up domains of ownership according to skillsets to de-risk uncertainties.

What we learned

How to program firmware on the QNX RTOS.
Working with Docker Compose for container orchestration using Dokploy.
- Provisioning Infrastructure-as-Code with Pulumi.
- Code is a liability, not an asset. You don’t have to build everything from scratch yourself to achieve your goals. Throwing configuration code at the problem instead of feature code for a bespoke system can be enormously effective during the early ideation phases of the product development cycle.