Platform · OS
My own platform layer, built for boats.
The 32°N operating system is the software layer that boots on the hub, starts the platform services, and manages the apps. It runs on the hub (a Mac mini in the nav station), but it is not macOS — it is the 32°N stack running on top of macOS, packaged as a Docker image, deployable anywhere.
Apple built a coherent ecosystem by owning every layer. I am doing the same thing — but with web tech, open-source, on hardware you can buy at any electronics store. The analogy is the inspiration, not the platform.
What the OS is
One install. Everything else runs on top.
The 32°N OS boots on the hub and starts seven platform services. Every app on the boat gets all of them for free — no wiring, no configuration. The app just implements the platform contracts and the OS hands it identity, storage, the event bus, AI access, and the audit log on arrival.
Identity
Every device that connects to the hub goes through a registration handshake. Devices are scoped to specific permissions. Nothing connects that has not been explicitly admitted. The same identity principal flows from the hub out to the cloud sync layer so you are never managing two sets of credentials.
Data store
A structured local Postgres instance owned by the OS. Apps get a per-app schema; they cannot read each other's tables directly. The OS mediates cross-app data access through the bus and the sync contracts. Backups replicate to the cloud layer when you have a connection.
Event bus
The native 32°N data bus lives inside the OS. Apps subscribe to topics; they do not poll. Every instrument reading, state change, and OS event arrives as a typed, timestamped, source-tagged message. The bus is how apps know the boat's state without talking to each other directly.
Audit log
Every significant action — device registration, permission grant, app install, data export, agent invocation — is written to a structured, queryable, tamper-evident audit log. Not a syslog dump. A first-class log you can actually search through from the UI.
Agent runtime
The OS runs a lightweight AI agent runtime: background processes that watch the boat state and take action when conditions are met. Anchor watch, bilge alert, abnormal electrical draw, barometric pressure drop — all implemented as agents that run continuously without any app open.
MCP server
The OS runs a Model Context Protocol (MCP) server that exposes the boat's current state, history, and configuration to any MCP-aware AI client. This is how the AI assistant gets clean, typed access to everything — boat position, weather, battery, anchor status — without needing to parse raw bus messages itself.
Secret store
API keys, certificates, NMEA gateway credentials, cloud tokens. Apps declare the secrets they need; the OS injects them at runtime. No secrets in app bundles. No plaintext in the database. The store is encrypted at rest and backed by the identity layer.
Why build it at all
The analogy that explains the choice.
Apple's devices feel like one product because the hardware, the OS, the app store, the design language, and the developer tools were designed together. That coherence is the thing I wanted — not the Apple stack.
What macOS does for me
The Mac mini runs macOS. macOS gives me a stable, trusted hardware abstraction, a filesystem, networking, Bluetooth and USB drivers, and a process scheduler. I use all of that. I do not fight it.
The 32°N OS layer sits on top of macOS as a Docker container — or several. Docker handles process isolation, resource limits, and restarts. macOS handles the hardware. 32°N handles everything above that line.
What 32°N adds that macOS does not
macOS has no concept of a boat, an instrument bus, an NMEA-2000 gateway, a sailing passage, or an app that needs to know the vessel's battery state at boot. Those are 32°N's domain.
The OS layer is where I define the contracts that apps depend on. Without it, every app would have to wire up its own database, its own identity, its own AI integration. With it, they get all of that from the platform on arrival.
Deploy anywhere — Mac mini is the reference, not the requirement
The 32°N OS ships as a Docker image. The reference hub is a Mac mini. That is the hardware I recommend and design for today. The same image runs on a Raspberry Pi, a NUC, a server in your house, or any cloud provider.
When I say the architecture does not depend on Apple Silicon, I mean it. I use a Mac mini because it is the right hardware for where the project is now — fast enough for local AI inference, quiet enough for a nav station, commercially available anywhere in the world.
My own App Store
Apps on the 32°N platform come from my registry, not Apple's. Every app that enters the registry goes through a signing pipeline and a capability scan. The capabilities are declared in the app manifest; the OS enforces them at runtime.
This is how I control the trust model. An app that declares it needs GPS access gets GPS access. It does not get battery data unless it declares that too. The registry is open — anyone can publish an app under AGPL-3.0 — but the trust pipeline applies to everyone including me.
App sandbox
Apps get what they declare. Nothing else.
Every app runs inside a sandbox enforced by the OS. The sandbox is not advisory — it is structural. An app that wants access to a capability has to declare it in its manifest before it is signed into the registry, and the OS only grants it at runtime if the declaration is present and the user approved the capability during install.
Capabilities are declared before the app is signed into the registry. The OS checks them at install and enforces them at runtime. An app that tries to read the battery data without declaring
battery.read
in its manifest gets a permissions error — not a permission dialog. The contract is set at build time, not at runtime.
Agent runtime + MCP
Background intelligence, typed access.
Two related OS services handle the AI layer: the agent runtime runs background processes that watch for conditions and act; the MCP server gives any AI model a clean, structured window into the boat's state without having to interpret raw bus messages.
Agent runtime
Agents are long-running OS processes, not app features. They boot with the OS and keep running whether or not any app is open.
The anchor watch agent watches position drift continuously. The electrical agent watches for abnormal draw patterns. The barometric agent watches for rapid pressure drops. Each one is a small, typed process that subscribes to specific bus topics and emits alerts when thresholds are met.
Agents can also call the AI gateway for inference. The anchor watch agent does not just trigger on GPS drift — it can ask a model "is this normal swing at this anchorage given the current wind?" before alarming.
MCP server
The Model Context Protocol (MCP) server is an OS-level service that exposes a typed, versioned snapshot of the boat's state to any MCP client — including the AI assistant in the 32°N UI.
When you ask the AI "what is my estimated range to the next fuel stop?" it does not scrape the screen or parse logs. It calls the MCP server, which returns a structured object: current fuel level, engine hours, SOG (speed over ground), the current route, and the fuel consumption model for this vessel. The AI gets facts, not text.
The MCP server schema is open and versioned in the public repo. Third-party AI clients can use it too.
Install + update
One command to start. Updates pull automatically.
The 32°N OS is distributed as a Docker Compose stack. Install is one command. Updates pull the new image and restart in place — no downtime for the bus or running agents during a patch update, because the OS services restart in dependency order.
See it in the demo, or go deeper in the docs.
The demo lets you explore the OS UI, the app registry, and the platform services without any hardware. The developer guide has the full architecture — contracts, schemas, deployment topology, and the SDK.