Blog

Bert Varias and Jon Choi
October 19, 2026

Middle Management: Concepts for Management Module Implementations

Introduction

OpenSFF Management Module concepts
Variants of the Management Module. Concepts by OpenSFF.

OpenSFF is a nonprofit organization developing an open hardware standard for vendor-agnostic, serviceable, and modular small form factor systems. Our hardware specifications define Compute Nodes that slot into an Enclosure, which provide power, cooling, and networking to the nodes. Finally, the Management Module provides administrators standardized access to the infrastructure of compatible Enclosures. That includes node power control, node monitoring, KVM, and management networking. Similar to the Compute Node, the Management Module can be replaced or migrated to another compatible Enclosure, and all three components will work together regardless of their vendors.

The Management Module Specification defines two reference designs: Pass-through and Full-featured. We created them to establish a common baseline for interoperability while offering an affordable local management solution in the Pass-through device. We explicitly state in the specification that vendors can implement Management Modules with capabilities between or beyond the reference designs, as long as they still meet the interoperability requirements. In this article, we will explore what that middle ground may look like and lay out two illustrative concepts alongside the reference designs.

The Pass-through Management Module

OpenSFF Pass-through Management Module concept
A Pass-through Management Module. Concept by OpenSFF.

This reference design has no CPU and no operating system. It routes DisplayPort and USB signals from the selected Compute Node to its external ports, so that administrators can plug in a display and peripherals into the I/O shield for local access.

All implementations of the Management Module provide KVM access and power control to only one Compute Node at a time (those functions can be done on two different nodes at any given time, e.g. an admin can turn off the node in slot 1 while in an active console session with the node in slot 7). In the case of the Pass-through design, physical controls let the administrator select the active node. A hardware indicator will show the node slot of the active node. Finally, there is an Ethernet port that is connected directly to the Private Enclosure Network (PEN), the Enclosure’s dedicated internal management network.

Because it has no processor and no software to maintain, the Pass-through Management Module will be the most inexpensive variant of the module. It will also consume the least amount of power. It is a great fit for test benches, simple home servers, and any environment where the administrator is always on-site. It can also be stocked as an emergency spare in deployments that do run more advanced Management Modules.

The Full-featured Management Module

OpenSFF Full-featured Management Module concept
A Full-featured Management Module. Concept by OpenSFF.

This reference design is based on the Raspberry Pi Compute Module 5 (CM5) and runs the Management Module OS, a custom version of Raspberry Pi OS that includes the management software. On top of everything that the Pass-through Management Module provides, a Full-featured Management Module supports a variety of remote management features:

  • IP-KVM
  • Node power control
  • Node monitoring
  • OS installation
  • Network configuration
  • Administrator account management
OpenSFF web interface IP-KVM session
Opening a remote console session on the management web interface (work in progress). Image by OpenSFF.

A Full-featured Management Module will also synchronize with the Enclosure microSD Card (ESDC), allowing both to hold Enclosure metadata and the module’s configuration. This lets the data stay in the Enclosure when the module is replaced and then copied over to the replacement module.

As we mentioned, vendors do not have to choose between a Management Module that has no processor and a full remote management tool based on the CM5. We came up with two concepts to illustrate how a vendor could implement Management Modules with intermediate capabilities.

Local access Management Module with a status display

OpenSFF Management Module concept with status display
A Management Module with a status display. Concept by OpenSFF.

This concept is a step up from the pass-through design. The main difference is that it has a microcontroller driving a small OLED or dot-matrix display on its I/O shield. As its name suggests, this Management Module still provides only local access. The microcontroller will need only firmware instead of a full operating system.

Aside from indicating the selected node, the display can also show:

  • Which node slots are occupied
  • Whether each node is Core or Enterprise class
  • The power status of each node slot
  • Power control feedback, e.g. “Powering on…”, “Powering off…”, “Resetting…”

Management Modules with an SoC or CPU can also incorporate similar hardware and functionality.

This variant can also display network status, but it may require additional hardware and firmware since the PEN connects nodes to the Management Module through USB-to-Ethernet bridges.

Alternative smart Management Module

OpenSFF alternative smart Management Module concept
An alternative smart Management Module. Concept by OpenSFF.

In contrast to the previous concept, this one can be equivalent to or a step down from the Full-featured reference design. It uses a different CPU or SoC instead of the CM5 and runs a vendor’s own management software to provide everything that the Pass-through design has, along with some or all of the Full-featured Management Module’s capabilities.

For instance, an OEM may want to build a streamlined management solution that provides only remote power control and monitoring, as those are the only functions needed to manage their OpenSFF-compatible appliance.

While the hardware components of this design may be cheaper to source compared to that of the Full-featured design in some cases, vendors must account for the impact of developing their own management software instead of adopting or extending the default management software that we are developing. Vendors must also ensure that their software still meets the interoperability requirements in the upcoming Management Module OS specification so that their implementation will still work with any compatible Enclosure and any Compute Node.

OpenSFF 2U two-slot Enclosure concept with Management Module
A 2U, two-slot managed Enclosure with a Management Module below its power supplies. Concept by OpenSFF.

Build with OpenSFF

Like the Compute Node and Enclosure Specifications, the Management Module Specification does not dictate components for most implementations. The only exception is the CM5 in the Full-featured reference design. As long as they meet the interoperability requirements, vendors can use a microcontroller, an SoC, and their own firmware. That flexibility allows vendors to offer Management Modules at different price points and complexities, ultimately making out-of-band management more accessible and scalable.

We encourage you to read our specifications, and we would be grateful if you help spread the word about OpenSFF. For technical clarifications, partnerships, and other inquiries, reach out to our development team at [email protected].

Category
Specification

Other Articles