StormHeart is the system that turns a device into a Stormer. It is the first process that runs, the one responsible for setting up the local runtime, receiving deployment plans, and enforcing them over time. Without it, a Stormer is just hardware.

This post defines StormHeart’s role in the StormFleet architecture. It outlines its responsibilities, execution scope, and design principles—and explains how it behaves under real-world conditions, including failure.

Purpose Link to heading

StormHeart is the deployment agent of a Stormer. It is responsible for turning a raw device into an operational Stormer by installing required system components and managing behavior deployments over time.

Once StormHeart is running, it:

• Bootstraps the Stormer by deploying essential system components

• Signals presence to StormTower via a heartbeat

• Receives deployment plans and realizes them by deploying, updating, or removing Flashes

• Maintains deployment integrity through reconciliation and basic health checks

StormHeart does not coordinate fleets, handle mission logic, or expose interfaces. Its sole job is to keep the Stormer’s runtime aligned with what StormTower expects.

Scope Link to heading

StormHeart operates in isolation, embedded in a single device. It manages what it can directly observe and control—nothing more. It has no awareness of the broader fleet. It does not know which mission it belongs to, how other Stormers are behaving, or why it is being instructed to deploy a particular Flash.

Its world consists of:

• A local container runtime (e.g., Docker)

• A set of system components it is responsible for keeping alive

• A message channel through which deployment plans arrive and heartbeats are sent

StormHeart’s only concern is the Stormer it inhabits. It maintains the Stormer’s runtime state, reacts to orders, and ensures that what should be running is running.

Everything beyond that is noise.

Architecture Link to heading

StormHeart’s architecture is shaped by three hard constraints: its isolated execution context, its declarative control model, and the unreliable nature of edge environments. To fulfill its role reliably under these conditions, it adopts a small set of architectural characteristics:

• Self-Healing and Stateless: StormHeart maintains no internal state between restarts. If it crashes or reboots, it reconstructs the system state from the environment and resumes operation. This statelessness is what allows it to recover autonomously and remain reliable in unstable conditions.

• Declarative Reconciliation: StormHeart doesn’t execute step-by-step commands. It receives deployment plans that define the desired state of the Stormer. Its job is to reconcile the actual state with that target—by starting, stopping, or replacing behavior modules as needed. This model enables idempotence, fault recovery, and deterministic behavior.

• Virtualized Execution: StormHeart needs to support diverse hardware with varying capabilities. To remain consistent across devices, it treats all workloads—both system components and behavior modules—as isolated units deployed in virtualized environments. This abstraction layer enables portability, control, and safety.

• Message-Driven Operation: All interactions with StormHeart happen over asynchronous message channels. It listens for deployment instructions and emits heartbeats and status signals. There are no APIs, no RPC calls, and no tight integrations. This design ensures decoupling, supports intermittent connectivity, and aligns with fleet-wide communication patterns.

• Minimal and Focused: StormHeart doesn’t coordinate fleets, evaluate missions, or perform dynamic scheduling. It exists to keep one device in the correct state. Every architectural choice is made to support that role—nothing more.

How It Works Link to heading

StormHeart behaves as a local control loop embedded in a device. It is responsible for initializing the runtime environment, reacting to deployment instructions, and maintaining the system state over time.

Startup Link to heading

On startup, StormHeart initializes the Stormer. It ensures that required system components are present and running, and brings the device into a usable operational state. Once ready, it signals its presence to the rest of the system. From this point forward, the device is part of StormFleet.

Deployment and Reconciliation Link to heading

When a new deployment plan arrives, StormHeart treats it as the latest desired state. It does not execute imperative commands—instead, it compares the desired state to the actual state and performs only the actions needed to bring them into alignment. This reconciliation process happens on startup, after receiving new plans, and whenever the running state drifts from the expected configuration.

Maintaining Health and Signaling State Link to heading

StormHeart emits regular signals to indicate it is alive and functioning. These signals can be used by upstream systems to detect presence, track health, and observe behavior over time. Additional messages are emitted when deployments succeed, fail, or change unexpectedly. These provide external visibility without requiring tight coupling or direct access to the device.

Error Recovery Link to heading

StormHeart is designed to recover from failure automatically. If it crashes or restarts, it reinitializes its environment and resumes reconciliation without needing external input. If a deployment partially fails, it continues attempting to apply the plan until it succeeds or a new plan is received.

Security Considerations Link to heading

StormHeart executes code and actions on behalf of a remote system. That makes it a critical trust boundary within StormFleet. Although security is not the primary focus of the current design phase, it is a core concern that will guide future implementation.

The following principles shape StormHeart’s security posture:

• Distrust by default: Deployment plans and behavior modules are not trusted implicitly. Validation will be required before any execution.

• Isolation of execution: Deployed workloads will run in strict isolation from one another and from StormHeart itself, reducing the blast radius of failure or compromise.

• No exposed services: StormHeart does not host APIs or receive direct calls. This eliminates a common attack vector in distributed systems.

• Verifiable origin: Future iterations will include signature verification to ensure that only trusted sources can issue deployments.

Security will be addressed explicitly in future design and implementation phases, once the functional foundation of StormHeart is complete.

Closing Thoughts Link to heading

StormHeart is where StormFleet begins. It turns raw devices into structured, observable, and resilient agents by enforcing a single rule: the system must match the plan. Everything else—coordination, intelligence, adaptation—depends on this foundation working reliably at the edge.

One device. One job.