Platform · Cloud
Cloud and AI first. Offline where it matters.
32°N is designed for a world where the boat is online most of the time. The cloud layer handles the things that genuinely need or benefit from the internet: AI that calls frontier models, live weather data from multiple forecast sources, data sync across your devices, share links, and the hosted version of the platform itself.
When you are offshore with no signal — anchored in a remote bay, crossing an ocean — the hub keeps the safety-critical apps running locally. Charts, anchor watch, navigation, electrical monitoring. The cloud catches up the moment you reconnect.
What the cloud does
Heavy lifting off the boat. Quick stuff on it.
The cloud is not a backup destination or a relay. It is where the platform's bigger services run — so the hub stays light, responsive, and quiet in the nav station.
AI when it needs to think hard.
Quick AI runs on the hub — anchor watch, anomaly detection, voice transcription, basic context queries. The bigger questions ("is this a good window to leave?", "what does this electrical pattern suggest?") route to a frontier model in the cloud when you have signal.
The AI gateway is a cloud service. It is not bring-your-own-key. I run it, I manage the model connections, and I abstract that complexity away from the apps.
Weather, charts, AIS — aggregated.
The cloud pulls forecasts from NOAA, ECMWF (European Centre for Medium-Range Weather Forecasts), ICON, AROME and other sources, blends them, and delivers clean data to your boat. Charts and AIS targets work the same way. One cloud connection, every source underneath it.
Data licences that are redistributable under ODbL, public-domain, or ECMWF Open terms are served from my API. Commercial providers (PredictWind, some chart vendors) require your own licence key — those are the only bring-your-own-key integrations in the platform.
Data backed up. Devices in sync.
Your boat's data backs up encrypted to the cloud and syncs across your phone, tablet, and laptop automatically. Same passage plan, same logbook entries, same waypoints — on every screen, all the time. Your data is portable by design — you can take it to self-hosted infrastructure any time.
Share links + container images.
Share links let you send a read-only view of your passage plan, current position, or logbook to anyone — without giving them access to the hub. Useful for marina arrivals, shore-side crew briefs, or family tracking.
Container images for every platform component are published to the GitHub Container Registry. The self-hosted deployment uses the same images as my hosted instance. AGPL-3.0 prevents a "cloud edition" that quietly diverges.
AI gateway
Two tiers. One interface.
The AI layer in 32°N runs at two levels. The hub runs a small local model for continuous background tasks: anchor watch, anomaly detection, voice command transcription. These tasks run all the time, with no dependency on signal.
When you ask the AI assistant a harder question — passage planning, electrical fault diagnosis, weather routing analysis — the gateway routes the request to a frontier model in the cloud. The model gets the boat's current state, history, and context through the MCP (Model Context Protocol) server running on the OS. It gets structured facts, not screen-scraped text.
The gateway is a managed cloud service. There is no API key for you to supply or rotate — I handle the model connections and abstract that away. The gateway is horizontal across all the apps: every app that needs AI calls the same gateway, gets the same capabilities, and costs nothing extra.
Offline · graceful degradation
When you lose signal, the boat keeps working.
The cloud does the heavy lifting, but the hub does not need it to keep you safe. Offshore, in a remote anchorage, after a storm — the safety-critical apps keep running locally.
What keeps working offline: the chartplotter (with the most recently cached chart tiles), anchor watch (the local AI model does the watching), navigation instruments, electrical and systems monitoring, the ship's log, AIS from the onboard receiver, comms. All of it, because it all runs on the hub.
What pauses: frontier-model AI questions, the latest weather model refresh, off-boat backups, share link access for people reading your position from shore. They catch up the next time you get signal.
I did not build offline-first — that is a different product, with different trade-offs. I built cloud-first that degrades gracefully where it counts.
Deployment shapes
Three ways to run 32°N.
The boat hub is always yours — a Mac mini in the nav station running the 32°N OS. The cloud layer has three options. All three run the same source code under AGPL-3.0.
My hosted cloud
Use the 32°N cloud instance I run. Point your hub at it during setup. You get all the cloud services — AI gateway, weather, sync, backups, share links — without running any server infrastructure. This is where most people start.
Start hereSelf-host the cloud
Run the cloud layer on your own infrastructure — any cloud provider, a server in your house, a VPS. Pull the container images from the registry, point your hub at your own cloud endpoint. Same code, same capabilities, your infrastructure.
AGPL-3.0 means anyone running a modified version of the cloud layer must publish their changes under the same licence.
Full self-host
Hub and cloud both on your own hardware. Nothing leaves infrastructure you control. Some cloud services (like weather from external providers) still need internet access — but the platform itself runs entirely on hardware you own.
Documented in the developer guide. Docker Compose stacks for all platform components are in the public repo.
Read how to self-host.
The developer guide has the full deployment topology, container references, and self-hosting instructions.