# MicroShift: one systemd service, one binary, an OpenShift control plane at the edge

> MicroShift is Red Hat's small form factor build of OpenShift, packaging kube-apiserver, the controllers, kubelet, and the scheduler into a single binary that runs as one systemd service. It targets edge devices and constrained machines with 2 CPU cores and 2GB of RAM, at the cost of a platform that only runs on Red Hat Enterprise Linux.

**openshift/microshift** — A small form factor OpenShift/Kubernetes optimized for edge computing

- Repository: https://github.com/openshift/microshift
- Website: https://microshift.io
- Stars: 848 · Forks: 233
- Language: Go
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/openshift-microshift

## Everything OpenShift runs as goroutines inside one binary

The architecture section of the repository describes MicroShift as a single systemd service that embeds a minimal OpenShift control plane and worker node. A single binary packages kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and the OpenShift controllers as goroutines. That is the whole trick behind the small footprint. Instead of a fleet of separate containers and static pod manifests that a full OpenShift control plane relies on, the components become goroutines inside one process, scheduled by the Go runtime rather than by a container orchestrator. Etcd is the exception and it is worth knowing about: it runs as a separate process managed by the main binary, not as a goroutine. The Go module file confirms the shape of the implementation. The module path is github.com/openshift/microshift, it requires Go 1.26.3, and the dependency list shows the usual control plane scaffolding, including github.com/openshift/api, github.com/openshift/client-go, github.com/openshift/library-go, k8s.io/api at v1.37.1, and the etcd client at v3.7.0. The build also pulls in the OpenShift cluster policy controller and the route controller manager, plus OVN-Kubernetes libraries for the CNI, and sigs.k8s.io/knftables, which points to a netfilter based path inside the networking stack.

## Cluster services land after the control plane, and optional pieces arrive as RPMs

MicroShift is layered in two stages, and the split matters for anyone planning a deployment. Infrastructure services including DNS, the ingress router, the service CA, OVN-Kubernetes as the CNI, and LVMS storage are deployed onto the cluster after the control plane starts. In other words, the cluster does not come up with networking in place; it comes up as a control plane and then installs its own infrastructure. Optional components, specifically OLM, Gateway API, cert-manager, and SR-IOV, are delivered as separate RPM packages and discovered automatically through the manifest path system. This is a deliberate trade-off. Bundling everything would make the footprint larger and the update path heavier, while splitting it means an operator who needs cert-manager has to install that package and accept the discovery mechanism as the way it becomes active. It also means the difference between a working MicroShift node and a fully equipped one is not visible from the base install, which is a genuine source of confusion during troubleshooting.

## The versioning scheme ties each build to an OpenShift release

MicroShift vendors OpenShift source code without modification, and a given MicroShift release is built from the same content as the corresponding OpenShift release, following the same versioning scheme. This is the most important operational fact in the repository for anyone thinking about upgrade cost. You are not picking up a bespoke distribution with its own compatibility matrix. You are running OpenShift code, assembled differently, and the version you pin tells you which OpenShift content is inside. The recent release list shows how that plays out in practice: 5.0.0-rc.7 and 5.0.0-rc.6, both dated in October 2026, sit alongside 4.22.18 from the same month. Two streams are moving at once, a release candidate line and a patch line on the previous minor. The Makefile shows how the version string is assembled during a source build, combining the OpenShift version, the source commit timestamp, the commit hash, and the tree state into MICROSHIFT_VERSION, with a separate definition for each CPU architecture through Makefile.version.x86_64.var and Makefile.version.aarch64.var. The build also propagates a single BIN_TIMESTAMP so that every artifact shares one build timestamp, which matters when you later correlate a binary with the images it pulled.

## The resource floor is 2 cores and 2GB of RAM, on RHEL only

The stated minimum system requirements are narrow, and one line in them narrows the whole product. MicroShift needs an x86_64 or aarch64 CPU, Red Hat Enterprise Linux with Extended Update Support, 2 CPU cores, 2GB of RAM, and 2GB of free system root storage for MicroShift and its container images. The README also notes that those figures exclude the resources the operating system itself needs. On top of that, the guidance is that workload requirements may force more CPU and RAM, more disk space in the root partition for container images, and an LVM group for container storage. The operating system constraint is the one that decides adoption for many teams. This is not a distribution that runs on Ubuntu or on a generic Kubernetes node, and the production deployment guidance points to bare metal hardware or hypervisors that are supported and certified for Red Hat Enterprise Linux 9. If your fleet has mixed operating systems, the resource frugality story does not rescue you, because the platform requirement is not negotiable in the same way as the memory budget.

## The edge-first design goals, and the other uses the project admits to

The stated design goals explain why MicroShift is not simply a small OpenShift. Edge devices in the field pose operational, environmental, and business challenges that differ from cloud, and those produce different engineering trade-offs. The goals listed are frugal use of system resources, tolerance of severe networking constraints, updating securely and speedily without disrupting workloads, integration with edge-optimized operating systems such as RHEL for Edge, and a consistent development and management experience with standard OpenShift. The interesting one is the third, because a control plane that cannot be updated while workloads keep running is a liability on a device you may not reach easily. The repository also names secondary use cases rather than pretending the target is narrow: Kubernetes application development on resource constrained systems, scale testing, and provisioning of lightweight Kubernetes control planes. The scale testing case is worth a second look for platform teams, since a small binary that can be stood up quickly is useful for load experiments. The design goals and principles live in the contributor documentation, and the technical detail in the architecture document, both linked from the repository root.

## Where MicroShift stops, and what a full OpenShift gives up instead

The honest limit is scope. MicroShift embeds a minimal control plane, and the optional components most people associate with a complete platform are not present by default: OLM, Gateway API, cert-manager, and SR-IOV all need separate RPM packages, and the manifest path system is what brings them in. A full OpenShift installation gives you those pieces in the base product, with the operator, console, and build pipelines that come with it, and it also gives up the small footprint that makes MicroShift possible in the first place. The comparison is therefore not which one is better. It is footprint against breadth. MicroShift also depends on etcd surviving as a separate process, and on the control plane starting before infrastructure services can be applied, which shapes both startup behaviour and failure analysis. The community and build setup is also split across repositories, with community build and CI sources in github.com/microshift-io/microshift, documentation sources in github.com/redhat-et/microshift-documentation, and the published site at microshift.io, so an engineer debugging a build issue needs to know which tree owns what.

## Licence, sources of truth, and what a first deployment needs

The project is under the Apache-2.0 licence, with the licence text in the LICENSE file at the root of the repository. That is a permissive licence with an explicit patent grant, and the vendor directory plus the presence of a cbom-microshift.json file and an sbom-microshift-crypto.spdx.json file show a project that takes supply chain metadata seriously enough to publish it. The repository layout is consistent with that: a cockpit-plugin directory, a dashboards directory, an observability directory, ansible content, packaging, and a hack directory. For a first deployment, the README routes you to the user documentation in the docs/user folder for installation, configuration, and running, and the Getting Started section on microshift.io for the first steps. For a source build, the Makefile at the root drives the build, and CONTRIBUTING.md covers how to build, test, and submit changes, with the contributor folder covering development environment setup, CI, and rebase procedures. The last push was on 2026-10-20 and the repository is not archived, so the development activity is current.

## Conclusion

Adopt MicroShift when you have a fixed RHEL footprint, a small number of nodes, and workloads that benefit from the OpenShift management experience without a full cluster's resource appetite. Do not adopt it for a heterogeneous fleet, for a platform other than Red Hat Enterprise Linux, or as a full OpenShift replacement, since the minimum requirements already assume a specific operating system and certified hardware. Before committing, check the minimum requirements listed for your machine, confirm that the optional components you need such as Gateway API or SR-IOV are packaged separately, and plan your upgrades around the release stream, since a 5.0 release candidate and a 4.22 patch were published in the same week.

## FAQ

### What are the minimum system requirements for MicroShift?

An x86_64 or aarch64 CPU, Red Hat Enterprise Linux with Extended Update Support, 2 CPU cores, 2GB of RAM, and 2GB of free system root storage for MicroShift and its container images. Those figures exclude the resources the operating system needs.

### What is the difference between MicroShift and a full OpenShift installation?

MicroShift packages kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and the OpenShift controllers as goroutines in a single binary that runs as one systemd service, with etcd as a separate process. A full OpenShift installation ships a broader platform, including components that in MicroShift arrive as separate RPM packages such as OLM, Gateway API, cert-manager, and SR-IOV.

### Does MicroShift run on operating systems other than Red Hat Enterprise Linux?

The stated minimum requirements name Red Hat Enterprise Linux with Extended Update Support, and the deployment guidance points to hardware and hypervisors certified for Red Hat Enterprise Linux 9. The repository also lists integration with edge-optimized operating systems such as RHEL for Edge as a design goal.

### How does MicroShift versioning relate to OpenShift?

MicroShift vendors OpenShift source code without modification, and a given MicroShift release is built from the same content as the corresponding OpenShift release while following the same versioning scheme.

### Which optional components can I add to MicroShift?

OLM, Gateway API, cert-manager, and SR-IOV are delivered as separate RPM packages and auto-discovered through the manifest path system.

## Sources

- [License: Apache-2.0](https://github.com/openshift/microshift/blob/main/LICENSE)
- [openshift/microshift on GitHub](https://github.com/openshift/microshift)
- [Project website](https://microshift.io)
- [README](https://github.com/openshift/microshift/blob/main/README.md)
- [Releases](https://github.com/openshift/microshift/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openshift-microshift