My Raspberry Pi 5 with 16 GB of RAM had been sitting mostly idle for a few months — running the usual homelab suspects, nothing that really pushed it. Then MicroShift caught my eye. A single-binary OpenShift/Kubernetes distro built for edge devices, maintained by Red Hat, targeting exactly the kind of constrained ARM hardware I had on my desk. I decided to give it a proper shot.

Why MicroShift

I’ve been working with OpenShift professionally for a while, and the appeal of having a real OCP-compatible cluster at home — one that speaks the same APIs, uses the same RBAC model, and supports the same operator patterns — is hard to overstate. Alternatives like k3s or microk8s are fine, but they diverge enough that you’re always translating. MicroShift is a subset, not a fork. Anything I test locally maps directly to what runs in production.

The 16 GB variant of the Pi 5 matters here. MicroShift’s own docs list 2 CPU cores and 2 GB RAM as the floor. The Pi 5 has 4 cores and — in this configuration — 8x that memory. There’s actual headroom to run workloads, not just the control plane.

Hardware and OS

The setup:

  • Raspberry Pi 5, 16 GB RAM
  • 256 GB NVMe SSD via the official PCIe HAT (not SD card — don’t even try this on SD card)
  • Fedora IoT for aarch64

The NVMe is non-negotiable. MicroShift writes a lot of etcd data and the SD card latency will cause spurious timeouts in the control plane. With the NVMe I’m seeing sustained reads around 900 MB/s and writes around 600 MB/s. The Pi 5 PCIe interface is gen 2 x1, so that’s the ceiling, but it’s more than enough.

Fedora IoT is a natural fit here — it’s built for exactly this kind of single-purpose edge device, ships as an immutable OS image, and has solid aarch64 suport. Flash the image to a USB stick, boot, install to NVMe. The Pi 5’s UEFI firmware handles the rest cleanly.

Installing MicroShift

The community build of MicroShift is available as a COPR — no subscription needed. Add the repo and install:

sudo dnf copr enable -y @redhat-et/microshift
sudo dnf install -y microshift

MicroShift pulls in CRI-O as its container runtime — there’s nothing to configure there, it’s all wired together in the package dependencies.

The community build doesn’t require a pull secret for the core components, so you can skip straight to the firewall setup:

Then open the firewall ports and start it up:

sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16
sudo firewall-cmd --permanent --zone=trusted --add-source=169.254.169.1
sudo firewall-cmd --reload

sudo systemctl enable --now microshift

The first boot takes a few minutes as it pulls images and bootstraps the control plane. After that, grab the kubeconfig:

mkdir -p ~/.kube
sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config

And verify:

oc get nodes

NAME        STATUS   ROLES                         AGE   VERSION
rpi5-edge   Ready    control-plane,master,worker   4m    v1.30.x

Single node, all roles — that’s exactly what MicroShift is.

What’s Actually Running

The core components that MicroShift brings up out of the box:

  • OVN-Kubernetes for networking (the same CNI OpenShift uses at scale)
  • CSI driver backed by LVM, with a volume group carved out of the NVMe
  • OpenShift DNS (CoreDNS under the hood)
  • OpenShift Router (HAProxy-based ingress)
  • Service CA operator for in-cluster TLS

That’s it — deliberately lean. No cluster monitoring stack, no image registry, no console. You add what you need.

Storage: LVM Configuration

MicroShift manages persistent volumes through its LVM CSI driver. By default it expects a volume group named microshift. I created one during OS install by leaving unallocated space on the NVMe, then after boot:

sudo pvcreate /dev/nvme0n1p4
sudo vgcreate microshift /dev/nvme0n1p4

MicroShift picks this up automatically. PVCs now work as you’d expect:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: topolvm-provisioner

Memory Reality

With the control plane stable and nothing else running, I’m sitting at about 1.1 GB used. That leaves nearly 15 GB for actual workloads on a system that costs a fraction of any cloud instance.

In practice, the main things I’m running on it are Home Assistant and a handful of scheduled jobs. One of those jobs pulls my Oura ring history into a local Postgres database on a nightly CronJob — I’d rather own that data than depend on Oura’s API stayin the way it is. Total memory pressure stays well under 4 GB. The 16 GB variant was probably overkill, but overkill is comfortable.

CPU sits at essentially zero between requests. The Pi 5’s Cortex-A76 cores are legitimately quick for ARM — this doesn’t feel like a hobbled device.

One Rough Edge: Image Architecture

A few container images I tried to run didn’t have linux/arm64 variants. This is less common than it used to be — most actively maintained projects publish multi-arch images — but it still happens with older or niche tools. MicroShift doesn’t do any emulation, so if there’s no arm64 image, the pod won’t start. The error is clear (exec format error in the events), so it’s not mysterious, just occasionally annoying.

Is It Worth It

Yes, with one caveat: MicroShift is explicitly not designed to be a general-purpose Kubernetes distribution. It’s for edge deployments where you want OpenShift compatibility in a small footprint, with the assumption that management happens from a central hub (like Red Hat Advanced Cluster Management). Running it standalone as a homelab cluster works, but you’re slightly outside the intended use case — there’s no multi-node support, no cluster upgrades via the console, and the monitoring story is DIY.

For my purposes — testing workloads before they go to a real cluster, running a few persistent services at home, getting familiar with OCP primitives outside of work — it hits exactly the right point. The Pi 5 with 16 GB is more than adequate, and Fedora IoT on aarch64 is rock solid.

If you have a Pi 5 collecting dust, the community build is a zero-friction way to get a proper OCP-compatible cluster running at home.