What the Margo Community Learned by Doing: A Standards Story from the Factory Floor

In May 2025, a Discord comment circulating inside the Margo community read: “not a single example of Margo.” Margo already had a substantial member roster (margo.org/about/members) and a published specification. Working groups had paused. Nothing ran against the spec.

Six months later, we — Belden, together with Red Hat and Rockwell Automation — put a live multi-vendor Margo demonstration on stage at SPS 2025 in Nuremberg, the world’s largest industrial automation trade fair.

This post is not a success story. It is an account of what the community discovered by doing, including the structural gap in the specification that the quadlet proposal is attempting to close. That proposal is still under community review. The question the community is working through is still open.

What Forced the Pivot#

The May 2025 TWG Shift in Operations document is frank. Armand Craig, from Rockwell, active in Margo’s Workload Fleet Management working group, summarized the situation plainly: membership had grown into the dozens of organizations with only a handful of active contributors, Discord frustration, working groups paused. The community had been building a specification without building anything to the specification. The pivot decision was to treat what the community was internally calling Preview Release 1 (the label Margo would publicly announce in January 2026) as a “Sandbox” — code-first, API-first, working implementations before further spec refinement.

This is a pattern in open standards work. The IEEE, the Linux Foundation, the IETF — all have seen the same dynamic: a specification produced without implementors in the loop tends to accumulate assumptions nobody has tested. Margo’s answer was to demand working code before claiming the spec was ready.

The pivot created pressure. If you were going to contribute to Preview Release 1, you needed to build something that ran. We decided to build something that ran.

The Three-Party Structure#

The invitation went out on July 18, 2025. The argument for a three-party structure — Belden, Red Hat, Rockwell — was deliberate: Margo defines several personas; the three most relevant to a deployment flow are Application Author, Application Platform Provider, and Orchestration Platform Provider, and we wanted each of those three represented by a different company. Red Hat brought Flight Control as the workload manager. Rockwell contributed the hardware — an edge device running k8s at the factory floor tier. Belden built the sample application: a data expert app publishing proximity sensor readings over MQTT to a live dashboard.

Red Hat was the critical missing piece. The middleware layer — the entity that accepts an application from one vendor and deploys it onto hardware from another — is where the Margo promise either holds or breaks. We needed a real middleware, not a mock.

The demo scenario was deliberately constrained: deploy one application, published by one vendor, via another vendor’s orchestration stack, onto a third vendor’s hardware. End-to-end import, deploy, operate, monitor. The application was simple — a sensor dashboard. The simplicity was the point. The goal was not to demonstrate a complex process. The goal was to demonstrate that the import-deploy-operate-monitor loop worked across organizational boundaries.

At the September 2025 Margo Sounding Board Workshop at the Capgemini campus near Paris, we submitted the prototype for community review. The Sounding Board — attended by Margo Steering Committee members — explicitly allowed non-commercial prototypes using what the community called “Margo Spirit” framing: demonstrating conceptual interoperability rather than claiming certified compliance with a specification still in preview.

This framing mattered. The Margo spec at that point was still working toward what the community internally called Preview Release 1 — the label itself would not become a public release until Margo announced it in January 2026. Claiming strict compliance would have been technically false regardless: there was no ratified spec state to be compliant with yet. Claiming the Kubernetes-and-Helm stack we used for the Rockwell device constituted a “Margo implementation” would have misrepresented what Margo actually specifies. “Margo Spirit” was the honest framing — and the Sounding Board accepted it.

The Gap the Demo Exposed#

Here is what the demonstration also made visible: the Rockwell device in our demo had 2.5 GB of free RAM, k8s pre-installed, and an x86 CPU. That is a capable device by industrial edge standards — it sits comfortably in the upper tier of what field deployments actually look like.

The lower tiers are different. Belden’s edge platform taxonomy runs from Heavy Edge (data center class) through Midsize, Mini, Micro, to Nano. Micro and Nano devices — 256 MB to 512 MB of RAM, ARM or MIPS processors, running unattended for a decade — represent a very large — and often invisible — share of the devices actually running on factory floors today.

The Margo specification, as written in Preview Release 1, defines two deployment profile types: helm and compose. Helm requires Kubernetes — and a k8s control plane commonly runs closer to 2 GB of RAM in practice than to the bare minimum documented for an agent-only node. Docker Compose requires a persistent daemon — on a Micro-class device (256–512 MB), that daemon alone can consume a large share of the available RAM budget, and the always-on root process is exactly what an SL2+ audit has to spend the most scrutiny on.

Neither profile fits the lower-tier device. This is not an edge case. It describes a very large share of field deployments.

The quadlet proposal is an attempt to close that gap. Podman Quadlets are systemd unit files generated from container definitions. Systemd is already present on virtually every Linux-based industrial device — it adds no persistent daemon process — no RAM overhead beyond the OCI runtime you’d need under any profile. The security model — rootless containers, native systemd directives like ProtectKernelModules and SystemCallFilter, auditable via a single systemd-analyze security command — gives an SL2+ audit a narrower, more legible surface to review than a persistent root daemon does. IEC 62443 compliance is a certification process, not a single technical mapping — but a smaller audit surface is a real head start.

The proposal adds quadlet as a third enum value alongside helm and compose. The schema change is additive — it does not alter the existing helm or compose definitions — but it is not a free addition for implementations: it requires a companion patch to the desired-state schema every Workload Fleet Manager consumes, and a reviewer flagged that, until a separate proposal on device capabilities lands, a WFM has no defined way to choose between compose and quadlet on a device that offers both. That gap is still open. The Margo Technical Working Group reviewed it in a session I sat in. Bart Nieuwborg, as Margo Chair, engaged directly with the argument and was supportive — but that is not the specification’s own approval gate. A SUP only clears that gate when the Technical Leads vote to approve it, and as of this writing, the Quadlet proposal has not reached that vote.

But a supportive hearing is not ratification by the community. The proposal is still under review. The deployment profile it describes has not been validated against a production Margo orchestration stack. That argument was carried to DevConf.CZ in Brno in June 2026.

The honest answer to “does quadlet belong in Margo?” is: we think so, and we have structured arguments for why. I put those arguments in front of the working group and they held up there. But open standards are not settled by arguments. They are settled by implementations, by practitioners who encounter the constraint in production and can speak to whether the proposed solution actually addresses it.

If you are deploying containerized workloads on devices below the 512 MB RAM threshold, the TWG wants to hear what you have encountered. The window for shaping this is open now, not after Preview Release 1 becomes GA.

The Margo Quadlets articles on this blog — the original quadlet proposal and the three-part “Why Quadlet Is Different” series — lay out the technical argument. The DevConf.CZ talk in June 2026 put that argument in front of upstream Podman, systemd, and RHEL contributors. Bringing it to that room was one step in the review; community review continues.

That is how open standards actually work. You build something, you show it, you bring the structural argument to a room full of people who will push back on it, and you find out where it holds and where it needs more work. We discovered that by doing it — which is exactly what the community asked for in May 2025.

The quadlet proposal is documented in the Margo TWG GitHub (PR #69, “Quadlet deployment type”). The technical implementation of the deployment profile — resource governance, security directives, production lifecycle — is detailed in the “Why Quadlet Is Different” series on this blog. I brought this argument to DevConf.CZ in Brno in June 2026, in the talk “The Triangle of Compromises: Podman Quadlets Solve the Industrial Edge Dilemma.”