Quest 3 is only a browser. This globe is drawn on the headset. The “backend” is a normal HTTPS website, not Meta’s cloud, App Lab, or a game server.
What this demo is running on
- Public URL —
https://85-10-235-242.sslip.io/maritime/ (Caddy, Let’s Encrypt). HTTP is not enough: WebXR needs a secure context.
- Origin — Python 3 on
127.0.0.1:8140 (triton-maritime). Serves the Three.js app and JSON.
- Headset — Meta Horizon / Oculus Browser (Chromium). WebGL 2 + WebXR
immersive-ar / immersive-vr. Pose, passthrough, hands and sticks are local at 72 Hz.
- Data merge — the same Python process polls Digitraffic / Kystverket AIS, OpenSky, Open-Meteo, OSM, Terrarium. The Quest never talks to those APIs directly.
- Cache —
cache/ on disk (coast, terrain tiles). No database, no GPU on the server.
What is typically required to run this
- Always-on Linux — 2 vCPU / 1 GB RAM minimum; 4 vCPU / 2–4 GB is comfortable when a new harbour builds terrain.
- HTTPS — Caddy or nginx, a hostname, Let’s Encrypt. Mixed content will block AR.
- Reverse proxy — only the app path need be public (here
/maritime/), proxy to localhost.
- Outbound internet on the server — AIS, weather, OSM. Snapshot ~1 Hz, tens of KB; coast/terrain a few hundred KB once per harbour.
- Quest on ordinary internet — to load this site (and YouTube harbour cams). No Meta login, STUN, or WebRTC.
- Not required — Meta App Lab, Unity on the server, a GPU box, WebSockets, a database. Native APK is a different product that would still call this same HTTPS JSON.
If the picture is empty
The page still loads without live AIS. Empty sea is honest: free coastal AIS is Baltic/Norway here; mid-ocean needs paid satellite AIS. Weather, terrain and air can still be live.