Building a Turing Pi 2 Compute Module Cluster: Mini-ITX Carrier Board for Raspberry Pi CM4/CM5 Nodes

This site's Raspberry Pi cluster content (the Beowulf-style MPI cluster and the K3s Kubernetes cluster guides) both assume you're networking together several standalone Pi boards with individual power supplies, SD cards, and a rat's nest of Ethernet cables. The Turing Pi 2 takes a different approach: it's a Mini-ITX carrier board that hosts up to four Compute Modules (CM4 or CM5, mixed and matched if you want) on a single board with shared power, a built-in Gigabit switch, and BMC (baseboard management controller) functionality for remote power cycling and flashing each node independently. If you've outgrown the "four Pis and a power strip" phase, this is the natural next step.

Why a Carrier Board Instead of Standalone Pis

A standalone Pi cluster needs one power supply per board, individual network cables into a switch, and no way to remotely power-cycle a hung node without physically pulling its plug. The Turing Pi 2 solves all three: a single ATX or DC power input feeds all four node slots, an onboard managed switch handles inter-node networking without an external switch, and the BMC — accessible over its own network connection — lets you power cycle, monitor, and even reflash individual nodes remotely, which matters a lot once the board is buried in a rack or closet rather than sitting on your bench.

Difficulty and Time Expectations

This is a moderate-difficulty build if you're comfortable with basic Linux administration and SSH — the physical assembly is straightforward (it's a Mini-ITX board, so it mounts like a PC motherboard), and most of the real time investment is in flashing and configuring each Compute Module's OS image and getting your chosen cluster software (K3s, as covered in this site's K3s guide, is a natural fit here) running across all four nodes. Budget an evening for physical assembly and power-on, and a second session for OS provisioning and cluster software.

Choosing Your Compute Modules

The Turing Pi 2 accepts Raspberry Pi Compute Module 4 or CM5 boards (check current board revision compatibility before buying, since CM5 support was added later than CM4 and requires a specific board revision), and you can mix RAM and eMMC/lite configurations across the four slots — a common pattern is running one node with more RAM as a control-plane node and three lighter nodes as workers. You do not need the Pi Foundation's official CM4 IO board at all; the Turing Pi 2 replaces its entire function (power, networking breakout, and more) for four modules at once.

Physical Assembly

1. Mount the Turing Pi 2 board into a Mini-ITX case (or an open test bench frame while you're still configuring it) using standard motherboard standoffs.
2. Seat each Compute Module into its slot, making sure it's fully engaged in the connector before applying any retention hardware — a partially-seated CM4 is a common cause of a node that won't power on at all.
3. Install a heatsink or the board's compatible cooling solution on each module — four CM4s in close proximity in a case generate meaningfully more heat than a single Pi in open air, and thermal throttling under sustained cluster load is a real concern without adequate cooling.
4. Connect your Gigabit Ethernet uplink to the board's WAN/uplink port, and connect the BMC's management port to your network if it's wired separately from the main uplink on your board revision.
5. Connect power (ATX PSU or a DC barrel/terminal input, depending on board revision) and power on.

Flashing and First Boot

The Turing Pi 2's BMC exposes a web interface (reachable at its own DHCP-assigned or statically configured address) that lets you flash an OS image to each node's eMMC or manage boot from an inserted SD card, without needing to physically remove modules from the board — this is the single biggest quality-of-life improvement over a standalone Pi cluster, where reflashing means pulling a card, writing it on another machine, and reseating it. Flash Raspberry Pi OS Lite or Ubuntu Server (see this site's Raspberry Pi OS comparison guide for tradeoffs) to each node through the BMC interface, and confirm each node boots and is reachable over SSH before moving on to cluster software.

Node roleSuggested OSNotes Control plane / masterUbuntu Server or Raspberry Pi OS LiteGive this node a static IP and slightly more headroom if using mixed RAM modules Worker nodes (x3)Same OS as control plane for consistencyKeep OS versions matched across nodes to avoid subtle Kubernetes compatibility issues

Networking Setup

Assign static IPs (or DHCP reservations at your router) to all four nodes and to the BMC's own management interface, and keep a simple naming scheme (node1-node4 plus bmc) in your local DNS or hosts file so you're not tracking raw IP addresses during setup. If your board revision has a separate BMC network port, connect it to your management network even if that's the same physical switch as your main LAN — having BMC access survive even if a node's own OS has crashed is the entire point of the feature.

Bringing Up the Cluster

Follow this site's K3s Kubernetes cluster guide for the actual cluster software bring-up — install K3s server on your designated control-plane node first, grab the join token, and install K3s agent on the remaining three nodes pointed at the control-plane's address. Confirm all four nodes show as Ready with kubectl get nodes before deploying anything real. From here, the Turing Pi 2 functions exactly like any other Kubernetes cluster for workload purposes — the hardware consolidation is the whole benefit, not a different software experience.

Remote Management via the BMC

Beyond flashing, the BMC lets you power cycle individual nodes, monitor basic health telemetry, and in some board revisions, access a serial console per node for debugging boot issues without a monitor and keyboard — genuinely useful once this board is in a closet or rack rather than on your desk. Set a strong password on the BMC's web interface immediately; it's a real management plane with real power over your hardware and shouldn't be left on defaults, especially if it's reachable from a broader network segment.

Safety and Practical Notes

Four Compute Modules under sustained load in a compact case draw more current and generate more heat than most makers expect from "just a few Raspberry Pis" — size your power supply with headroom above the nameplate sum of all four modules' typical draw, ensure adequate case airflow, and don't tuck this into a closed, unventilated cabinet without active cooling. As with any always-on network-connected device, keep the BMC and each node's OS patched, since a compute cluster running exposed management interfaces is a more attractive target than a single hobby Pi.

The Turing Pi 2 doesn't do anything a rack of standalone Pis couldn't do — it just makes the physical and remote-management side of running several nodes dramatically less annoying, which is exactly the friction that keeps most hobby clusters at "two Pis on a shelf" instead of a genuinely useful home lab.