Nanome's current headset apps and web app need outbound TCP 443 (HTTPS and secure WebSockets) to *.nanome.ai and *.nanome.com, allowed by hostname and exempt from TLS inspection, according to the firewall checklist in Nanome's setup guide. Meta Quest headsets also need Meta's own hosts and ports. The previous generation, Nanome Classic, adds UDP 5055-5056 for collaboration and TCP 8888 for plugins, listed beside its downloads on the versions page. Questions from a security review, data requests and account deletions go to the Nanome team at support@nanome.ai. For student data, class accounts can use generic names such as student-1, and Nanome's FAQ describes deleting an account's data as a manual request that takes 2 to 3 weeks.
A reviewer's summary
- Network. Outbound HTTPS and secure WebSockets on TCP 443, with Nanome's hosts exempt from TLS/SSL inspection (setup guide).
- Hosting. Nanome's servers run on Cloudflare and AWS. The MARA privacy policy says personal information from EU users is processed in the United States.
- Sign-up data. For MARA accounts, that same policy lists a username, an email address and an IP address at registration, plus an organization name once one is configured.
- Identity. Admins set up single sign-on at home.nanome.ai, and MARA's technical docs describe SSO through standard SAML.
- Isolation. Academic Classroom and Personal seats use a shared tenant Nanome-hosted collaboration server. Commercial Cloud runs on a single tenant Nanome-hosted stack, and Commercial Enterprise moves to a private cloud or the customer's own servers (pricing).
Firewall allowlist by version
| Traffic | Protocol and port | Host |
|---|---|---|
| Web app and workspaces | TCP 443 | app.nanome.ai |
| Accounts, licenses and organizations | TCP 443 | home.nanome.ai |
| Sign-in and licensing, Nanome 2.6 and later | TCP 443 | api.nanome.com |
| Sign-in, earlier releases and Classic | TCP 443 | api.nanome.ai |
| APK and Windows downloads | TCP 443 | downloads.nanome.ai |
| Classic collaboration | UDP 5055-5056 | collaboration.nanome.ai |
| Classic plugins | TCP 8888 | plugins.nanome.ai |
| Meta Quest platform | TCP 80, 443, 3478, 3479, 8080; UDP 40003, 40005, 40007, 40008, 50000-59999 | Meta's host list |
The first 5 rows come from the setup guide. It asks for rules by hostname, since IP addresses on Cloudflare and AWS change. The Classic rows come from the versions page. For allowlists built from exact hosts, Nanome's Classic-era troubleshooting page also names collaboration-us-east.nanome.ai and collaboration-us-west.nanome.ai for collaboration, and lists optional TCP 443 to files.rcsb.org, pubchem.ncbi.nlm.nih.gov and www.drugbank.ca for loading structures from public databases. Nanome 2.6.0 replaced Photon with an in-house real-time networking stack (release notes), and the published list for current Nanome is TCP 443 alone.
ArborXR and ManageXR each publish their own hosts. For headsets those services manage, the setup guide lists the main ones and links to each full list. On 802.1X networks, the MDM's Wi-Fi profile needs the RADIUS server's domain and a root certificate served with its full chain, intermediates included (setup guide).
Private cloud and customer-hosted installs use their own hosts and ports, set out in the enterprise deployment guide. The deployment VM opens TCP 80, plus TCP 443 when it serves HTTPS, and needs DNS names for the web app, tools and workspaces. That VM pulls Nanome's container images from AWS ECR with access tokens Nanome provides, and it calls whichever LLM provider the customer chose. Headset sign-in and licensing still go to the Nanome API. When headsets have no route to the internet, an auth proxy on the same VM forwards those requests, and each headset is pointed at it through the MDM.
Nanome doesn't publish a bandwidth or latency minimum for headsets or browsers. Its FAQ asks for a stable connection, especially for collaboration, and 2.6.0 added live high-ping indicators in XR and on the web (release notes).
Checking a network before a session
Four tests from the setup guide's network step can run days before a class or a design review:
- No browser sign-in page. Guest networks with a captive portal block first-time headset setup, and a Quest shows a no-internet message whenever it can't reach Meta, before Nanome opens.
- Port 443 from the same network.
curl -v https://api.nanome.comconfirms the port is open. Ping uses ICMP and doesn't test it. - A phone hotspot. When the hotspot works and the building network doesn't, the network is blocking something.
- MAC registration. Quest 3 uses a randomized MAC address for each network by default, so networks that register devices need the device MAC, or randomization turned off in the MDM's Wi-Fi profile.
What to send support when a session fails
A first message with these details usually saves a round of back-and-forth:
- The Nanome version, which the headset's login screen shows along with its online or offline status
- The headset model, and whether it runs standalone or tethered to a PC
- Whether the headset is enrolled in an MDM, and which one
- The network type: guest, 802.1X, VPN or hotspot
- The workspace code, and the time of the failure with its time zone
- The curl result and the hotspot result
Since 2.6.1, Report a Problem in the right sidebar sends a bug report without leaving the session (release notes). Each report carries a screenshot of the user's view, the account details, and the workspace and scene names and contents, so a report filed from a workspace holding confidential structures sends those contents to Nanome. The feature is turned off in deployments on a customer's own servers.
Common failures on restricted networks
| What happens | Likely cause | First step |
|---|---|---|
| Headsets lag while laptops are fine | Headsets on a separate, slower or more restricted network | The same workspace loaded on each network from a phone, then compared (session guide) |
| Quest reports no internet before Nanome opens | The headset can't reach Meta, often because of a captive portal | A network with no browser sign-in, and Meta's hosts allowed (setup guide) |
| Connections fail only on the managed network | TLS inspection on Nanome's hosts | Nanome's hosts exempted from inspection (setup guide) |
| Classic signs in, but collaboration never connects | Sign-in uses TCP 443, while collaboration uses UDP 5055-5056 | UDP 5055-5056 allowed to collaboration.nanome.ai (versions page) |
| The web app loads, then stays black | The browser is rendering without the GPU | Hardware acceleration on, and chrome://gpu checked for a disabled WebGL line (session guide) |
| A headset feels slow | Usually the shown atom count; a Quest 3 is comfortable at about 7,500 atoms | Everything hidden, then only what the scene needs brought back (session guide) |
Student accounts and personal data
Beyond the registration fields, the MARA privacy policy covers chat content. With hosted models, chat data may be processed by third-party providers including OpenAI, and with self-hosted models it stays inside the customer's infrastructure.
Class accounts can stay generic. Nanome's FAQ describes a license-administrator account that owns a class's licenses and assigns them, including to new accounts named student-1, student-2 and so on. Seats and headset sign-in for a class set have a walkthrough of their own.
Age limits matter for schools. The Nanome privacy policy says its products are directed to people 18 or older and that Nanome doesn't knowingly collect information from children under 13. The MARA policy says its services aren't intended for anyone under 18, and that Nanome deletes information it learns came from a child under 18 without verified parental consent. A school planning accounts for younger students can raise that with the Nanome team before rollout.
Deletion goes through support@nanome.ai. The FAQ describes deleting an account's data, or exporting a copy, as a manual process that takes 2 to 3 weeks, and the privacy policy sends requests to correct or show personal information to the same address.
Workspaces and who can see them
Permissions are set per workspace (session guide). A Viewer explores, spotlights, follows and moves through scenes. An Editor changes the workspace and invites others, and the Owner can also delete it, with a single Owner per workspace (permissions guide).
A workspace reaches other users 3 ways. Its code hands the workspace's global level to anyone who enters it, an email invite gives one address its own level, and members of the same organization who are online can be invited directly (session guide). With the global level set to None, the code admits nobody, so a workspace can stay closed to the rest of an organization while one invited colleague edits. A post on software for remote drug discovery teams shows how shared sessions run across sites.
Sign-in, SSO and two-factor
Users sign in at app.nanome.ai with an email address or with Google, Microsoft, Apple or SSO (setup guide). MARA's technical docs name Microsoft Azure Active Directory and Okta among the SAML identity providers it works with. SSO accounts sign in to a headset by device code: the headset shows a short code, the user enters it in the web app on another device, and no password is typed in the headset.
Two-factor authentication sits under Account Settings > Security at home.nanome.ai. It uses a 6-digit code from an authenticator app, and setup includes downloading recovery codes (2FA guide).
Private hosting and a dedicated MARA
Enterprise deployments run in a private cloud or on the customer's own servers and can connect custom or internal LLM and MCP servers (pricing). The deployment guide lists Anthropic, OpenAI, AWS Bedrock and Microsoft Foundry as supported LLM providers, and the MARA page states that Nanome has no access to Enterprise customers' data. MARA Enterprise lists single sign-on, org-level permissions for tools and queries, and auditability, log history and alerts among its Enterprise features. MARA's plans and dedicated instances are covered in the MARA plans post.
Compliance documents and security notices
Nanome's public site doesn't post a VPAT, HECVAT or SOC 2 report, so the current status of each is a question for the Nanome team at support@nanome.ai.
Nanome posts security notices on its blog. When Unity disclosed an engine vulnerability in 2025, the Unity vulnerability notice named the patched builds, Nanome 1.24.6 and 2.3.1, alongside Horizon OS v79 for Quest and the October 3 Windows Defender update for PC VR. Questions about a deployment's patch level go to support@nanome.ai, the contact that notice gives.
FAQ
What ports does Nanome need through a firewall?
Current Nanome needs outbound TCP 443 to *.nanome.ai and *.nanome.com, by hostname (setup guide). Nanome Classic adds UDP 5055-5056 to collaboration.nanome.ai and TCP 8888 to plugins.nanome.ai (versions page). Meta Quest headsets need Meta's own hosts and ports as well.
Can the allowlist use IP addresses?
IP rules eventually break. Nanome's servers run on Cloudflare and AWS, where addresses change, so the setup guide asks for hostname rules and a TLS inspection exemption for Nanome's hosts.
Does Nanome support single sign-on?
Yes. Admins set it up at home.nanome.ai (setup guide), MARA's technical docs describe SAML with providers such as Azure Active Directory and Okta, and SSO accounts sign in to headsets by device code.
How is a student's account deleted?
By a request to support@nanome.ai. The FAQ describes deletion as a manual process that takes 2 to 3 weeks.