For your IT and security reviewers

Network & security

Every hostname, port and figure below is read from the shipping build's own configuration, not from marketing copy. Last verified 30 August 2026.

The short answer

The clinical loop runs with no internet egress. Casting, controlling headsets, playing 360° video and recording session state all happen between devices on your own network. Blocking this application at the perimeter does not stop a class from running.

The scope of that sentence, stated up front, because an unscoped version of it is false: it describes our software on a Pico fleet provisioned in kiosk mode, which is the configuration we declare support for. A Meta Quest fleet carries its own platform requirements that apply no matter whose application is installed — see Platform scope below.

What happens on your network

Hub ↔ headset Headsets open a WebSocket to the Hub PC on TCP 5259. The Hub never dials out to reach them.
Discovery The Hub sweeps its own subnet for headsets — roughly 2,285 addresses in about 9 seconds, repeating every 45 seconds. Ordinary TCP connection attempts on 5259; no broadcast protocol, no mDNS dependency.
Cast media Peer-to-peer between headset and Hub on your LAN. The picture does not traverse a relay — ours or anyone else's.
Bandwidth Local only. There is no per-headset internet bandwidth figure to budget, because no headset streams over your uplink.

The one UDP exception, stated plainly: each cast session queries stun.l.google.com:19302 (UDP) once, to gather connection candidates. No media, no patient data and no application payload of any kind crosses it — it is the same class of dependency as ARP or DNS, not a data channel. A TURN server (an actual media relay) is deliberately not deployed, and an automated check fails our build if that ever changes quietly.

What the optional cloud connection touches

None of the following is required for the clinical loop. A signed-in installation with no route to the internet keeps working — that is the design, not a degraded mode.

HostPurposeRequired to run?
api.minervaxr.com (HTTPS + WSS)Accounts, content catalogue, statistics uploadNo — cached content and local session state continue without it
releases.minervaxr.comUpdate manifest — which version is currentNo
minervaprodsa05g63r.blob.core.windows.netRelease binariesNo
*.azurefd.net (HTTPS + WSS)Azure Front Door, in front of the aboveNo
*.sentry.ioCrash and error telemetry. Diagnostic data only — no video, no patient dataNo
minerva-simulations-store.s3.eu-north-1.amazonaws.comLegacy, unused. Retained in the policy after our 2026 move off AWS; removal pendingNo
d3brkcv6178qok.cloudfront.netLegacy, unused. Same — and an automated test already asserts the updater must not use itNo

The last two rows are listed rather than omitted, deliberately. They are hosts the application is still permitted to reach and no longer uses. If you diff this page against our configuration or against a packet capture, we would rather you found them here first.

How that list is enforced. Two layers constrain where the desktop application connects: the in-app browser view is bound by a Content-Security-Policy, and the desktop runtime's own network capability is scoped to a tighter subset of the same list. File transfers are performed natively against our API and the storage URLs it issues.

Sign-in, which neither layer covers: interactive login opens your browser (or a system Custom Tab) rather than an in-app request, so it is not governed by the policy above. It reaches minervaxrext.ciamlogin.com — Microsoft Entra External ID. Allowlist it only if you want staff to be able to sign in; a session, once established, then continues to work offline indefinitely.

What never leaves the building

Platform scope — read this before quoting the claim

Pico (our declared scope)Meta Quest
Our applicationNo egress requiredNo egress required
The device platformKiosk-provisioned; tolerates an offline networkMeta's own requirements apply. Devices enrolled in Meta Horizon managed services need meta.com, facebook.com, fbcdn.net and akamaihd.net reachable; Meta advises against IP-based allowlisting
Net effect on a closed VLANRunsOur features run; Meta platform functions — enrolment, device updates, store — do not

A Quest fleet on a fully closed network is a Meta constraint, not ours, and we will not claim otherwise. If a closed network is a hard requirement, Pico is the configuration to specify.

One cost of isolation, stated plainly. Our remote "halt a bad release" lever is delivered through the update manifest on releases.minervaxr.com. A site with no egress does not receive it, and version control becomes a local, manual procedure. Isolation is traded against remote recall. That is a real trade, and you should make it knowingly.

How these figures are produced

Every number on this page is read from the shipping build's own configuration rather than written by hand, and an automated check fails our build if the application gains a network destination that is not declared here. That is why the legacy rows above still appear: the check reports what the application is permitted to reach, not what we would prefer to show you.

Questions

If your review needs something this page does not answer — a packet capture, a deployment diagram, or a question about a specific control — write to contact@minervaxr.com and it will reach the engineers who wrote this, not a form.

← Back to minervaxr.com