Myrmic Launch Series – Part 1 of 3

Why we’re building a stateful runtime, from Linux hosts down to microcontrollers

Today, a cloud team developing a new application starts with mature building blocks and, just as importantly, with settled answers about how those blocks fit together. They can assemble a platform from well-established integration patterns, or pick an environment where compute, storage, messaging, deployment, observability, and lifecycle management already come integrated.

The edge has powerful building blocks as well: operating systems, message brokers, device frameworks, databases, WebAssembly runtimes, orchestration, and a large embedded ecosystem. What we kept having to design ourselves, project after project, was the contract between them.

The same questions came up every time: Who owns a machine’s state? How do you address a workflow after its process restarts? Where should a computation run? How do several AI cameras add up to one local digital twin of a site? And where do you draw the line between logic that runs anywhere and code that is bound to specific hardware?

That inspired us to build Myrmic.

We do not need one more building block for the edge. We need a shared contract between the application model and the runtime.

Myrmic is our open-source approach to crafting such a contract – for stateful applications spanning Linux-based edge systems and supported microcontrollers.

The Edge Is Not a Small Cloud

Many cloud technologies can be adapted to the edge. But several of the basic assumptions change.

A connection may be slow, intermittent, or completely absent. A site may run unattended. Storage, power, and compute differ by orders of magnitude. Hardware is heterogeneous. Some decisions must be made where signals originate and where actuators can be reached; an extra round trip through a central control plane is then too slow, or not possible at all.

As a result, integration itself becomes product architecture. Teams decide what runs locally and what runs centrally, where state lives and how messages reach it, what happens during the hours a link is down, which workloads are pinned to which hardware, and which logic must stay portable.

A vibration monitor on a pump is a small example. It has to keep judging its own signal while the uplink is gone, hold what it recorded until the link returns, and still appear in the central system as one machine rather than as a gap in the data.

We are not the only ones building this. Teams keep rebuilding the same connection between application, runtime, and hardware.

Addressing Is Only Part of the Contract

Before we look at what such a contract could be, it is worth naming the part that already works. One piece is largely solved: addressing — giving something a stable name even though the process behind it keeps being replaced.

Kubernetes can hide dynamic pods behind services and provide stateful workloads more stable identities. Kafka can address events for machine/8 through topics and keys, and store them persistently. Actor and durable entity systems decouple a logical identity from its current activation.

If a stable reference for machine/8 were the whole problem, it would already be solved.

A stable name tells the system where to send a message. It says nothing about who owns the state behind that name.

What we want from machine/8 is not just a name, key, or endpoint, but a single entity that carries identity, state, behavior, lifecycle, and its execution requirements together.

What components make up machine/8 today?

Using established tools, a machine can be effectively modeled as a distributed application:

The application concept machine/8 is thus composed of several infrastructure primitives. The relationship between them exists within architecture diagrams, code, and the team’s knowledge.

We aim to transform this relationship into an explicit runtime concept.

The Cell

In Myrmic, a long-lived application concept is modeled as a Cell.

Other parts of the system address machine/8 as a complete entity, not the process, endpoint, or host where its logic happens to be running.

A command reaches the Cell, which applies its domain rules to its state and then returns a response or emits an event. Cells talk to each other by message, and a remote interaction is never disguised as a local function call.

This is where a Cell goes beyond a stable address: identity, state, and behavior are one thing rather than three.

The application model owns identity, state, and behavior. The runtime owns where they run.

Isn’t that just an actor?

The approach described shares parallels with actor models and durable entities — specifically, a logical, stateful unit whose identity is not tied to a specific location.

Myrmic adapts these concepts for the edge and the associated requirements:

• edge and offline assumptions rather than a permanently accessible central environment,
• capability-based placement,
• a unified cell model spanning Linux-based hosts and supported microcontrollers,
• portable cell logic implemented in WebAssembly,
• native Rust for low-level hardware processing,
• and a runtime contract governing messaging, state, lifecycle, and execution.

What the developer defines – and what the runtime handles

The Cell boundary is also a responsibility boundary.

The application developer defines identity, state, behavior, commands, events, timers, lifecycle, and the capabilities a Cell requires.

The runtime manages execution, messaging, persistence, and placement for these elements. In the current preview, all data belonging to a Cell exists as a single authoritative copy by default. State can be configured to persist locally, so that it survives a crash and restart of its host, and replication can be set up manually.

Continuity — the runtime keeping a Cell’s data available when a host is lost, without manual setup — is one of the next steps in Myrmic’s development. We’ll cover the mechanisms behind it in a dedicated post.

Capabilities Instead of Hostnames

A cell does not encode the specific machine on which it must execute; it describes what it requires.

Hosts specify which capabilities they provide. The placement process matches requirements with available capabilities.

This does not promise arbitrary mobility. A cell requiring a unique local hardware capability can only run where that capability actually exists. Hardware-bound cells remain hardware-bound.

The advantage lies in the language of the application model: the cell requests vibration_monitoring. It does not carry edge-node-17 around as part of its functional definition.

The Execution Model: WebAssembly + Native Rust

Myrmic uses WebAssembly for portable cell logic, allowing the same application logic to execute on any suitable host.

However, low-level signal processing is performed natively in Rust. Embedded hardware is often chosen precisely for its specific characteristics; interrupts, timers, DMA, buses, and device-specific data paths are not merely details to be hidden by abstraction — they may well be the reason that specific target was selected in the first place.

We therefore draw a semantic boundary:

A cell should understand the concept of a VibrationAnomaly. It should not need to know which sensor, bus, register access, or DMA channel generated the observation.

Native signal processing takes place in Rust, using Embassy for asynchronous execution, together with reusable peripheral interfaces and drivers. Developers do not necessarily have to write the required modules themselves; instead, they can assemble their own processing pipeline from a set of standard building blocks.

Initial modules for common sensors and processing steps are already available. Given that Rust has a vast ecosystem of crates for sampling, calibration, filtering, and other processing tasks, we anticipate rapid library growth. We hope that lowering the barrier to entry will attract new developers to embedded Rust.

Why this matters now

We are facing a massive shift in software development – in what we build, and in how we build it. AI enables us to make far more intelligent (and sometimes not-so-intelligent) decisions; local inference, robotics, and sensor fusion are becoming increasingly important. At the same time, much of the code is now generated, which makes an explicit and compact application model matter more, not less: it keeps the system reviewable by a person, and it lets a model work more efficiently.

AI raises the stakes here, but it did not create these problems. Teams still have to solve state, messaging, local execution, hardware access, and placement themselves, and not only on standard edge computers but on much less powerful bare-metal devices.

Myrmic is our attempt to answer these questions once, in the runtime, instead of once per project. If this approach interests you, take a look at our repository.

Build a Cell. Try out the model. See how messaging, state, capabilities, and placement work together. Bring your own use cases. Open issues, join the discussion, and let us know what you’re missing.