Coral Vita · architecture
Why the control loop can't live in the cloud
A coral-reef facility runs on Starlink. That single fact decided the whole architecture of the control system — and pushed it to the edge.
The system
At Coral Vita I build the control systems that keep a coral-reef restoration facility running: firmware on a Raspberry Pi that physically drives water-treatment and per-zone life-support — pumps, valves, dosing, sensors — plus an Avalonia touchscreen on the wall and a facility server above it. The firmware runs a real-time loop that reads inputs, updates state, and writes outputs roughly once a second. When that loop stalls, living organisms are downstream of the bug.
The constraint that decided everything
The facility's internet is Starlink. Satellite links are good enough for a person on a video call and completely wrong to put inside a control loop for life-support: they drop during weather and obstructions, fail over between satellites, and add latency you can't bound. If keeping a pump running depended on a round-trip to a cloud region, then a cloud region — or a cloudy sky — could kill a tank of coral.
So the design question was never "which cloud." It was: what is allowed to depend on the internet, and what has to keep working when the internet doesn't?
The decision: control at the edge
The control loop lives on-site, on the box, at each facility. Neuron — the firmware — drives the hardware locally over GPIO, I2C, and Modbus, and talks to the rest of the site over a local MQTT broker. The cloud/server tier is for oversight, history, and operator control — not for the millisecond-to-second decisions that keep water moving. Each facility is deployed independently, per site, in Docker.
Concretely, that buys four things:
Fault isolation — one site's connectivity, or a central-server outage, cannot take down another site's life-support. Every facility is autonomous by default.
Bounded, deterministic latency — a pump or valve command is a local decision on the box, not a cloud round-trip, so the 1 Hz loop keeps its timing regardless of the link.
Fail-safe degradation — when a primary controller or the network misbehaves, a dedicated fallback controller takes over and MQTT auto-reconnects with retry, so the box degrades safely on its own instead of freezing.
A pinned contract — the MQTT wire protocol is a shared, version-pinned component across the firmware, kiosk, and server, so an offline box still speaks exactly the right protocol with no runtime negotiation to get wrong.
The tradeoff I accepted
Edge-per-facility is not free. There is no single cloud pane where everything is trivially visible; deploys and updates have to reach many autonomous boxes; and debugging a site over a link that is itself unreliable is genuinely harder. I took that operational cost on purpose — for life-support, an architecture that fails safe locally beats one that is convenient to observe but depends on a satellite staying up.