This guide provides configuration examples for CloudXR.js client devices, including browser setup, web server hosting options, and connection modes. These examples demonstrate common deployment scenarios you may encounter.
CloudXR.js client applications can be hosted using either HTTP or HTTPS protocols. We provide examples for both modes to help you choose the right approach for your deployment.
This example demonstrates the simplest configuration for local development and testing.
Example command:
npm run dev-server
Access URLs:
http://localhost:8080/http://<server-ip>:8080/Characteristics:
ws:// (direct) and wss:// (proxied) CloudXR Runtime endpointsThis example demonstrates HTTPS hosting, which is used for both development with WebXR devices and production deployments. It provides encrypted client connections and is required for secure WebSocket connections.
Example command:
npm run dev-server:https
Access URLs:
https://localhost:8080/https://<server-ip>:8080/Characteristics:
wss:// (secure WebSocket) connection to CloudXR Runtimews:// connections from HTTPS pagesThe following table shows example connection configurations between the web application server and CloudXR Runtime:
| Client Web Server | Runtime Connection | Status | Use Case |
|---|---|---|---|
| HTTP | ws://server-ip:49100 |
✅ Supported | Local development (simplest path) |
| HTTP | wss://proxy-ip:48322 |
✅ Supported | Testing proxy configuration |
| HTTPS | ws://server-ip:49100 |
❌ Blocked | Mixed content security policy violation |
| HTTPS | wss://proxy-ip:48322 |
✅ Supported | WebXR device testing, production deployment |
Important: When using HTTPS mode for your web application, you must configure a WebSocket proxy with TLS support. See the Networking Setup Guide - WebSocket Proxy Setup for configuration details.
This section provides configurations for Meta Quest 3 to enable WebXR functionality with CloudXR.js applications.
When using HTTP mode, the Meta Quest 3 browser needs explicit permission to access WebXR APIs from non-HTTPS origins. Here's how to configure it:
Access Chrome flags:
chrome://flagsEnable insecure origins:
unsafely-treat-insecure-origin-as-secureAdd your development server:
http://<server-ip>:8080http://) and port number (:8080)Apply configuration:
Verify configuration:
chrome://flags after relaunchWhen using HTTPS mode with self-signed certificates (for the web server and the WebSocket proxy), you need to configure the browser to trust these certificates.
Note: Certificate trust settings persist across browser sessions. You only need to perform this configuration once per certificate.
Access the proxy endpoint:
In Meta Quest 3 Browser in the sample client page, fill in the proxy IP as server IP and corresponding port, and click "click xxx to accept cert" as shown below. Or you can directly navigate to https://<proxy-ip>:48322/

Accept certificate warning:
Click Advanced
Click Proceed to <proxy-ip> (unsafe) or similar option

Expected behavior:
501 Not Implemented errorNote: If you restart or recreate the proxy container (using the Docker HAProxy example with auto-generated certificates), a new self-signed certificate will be generated. You must repeat the certificate trust process by visiting
https://<proxy-ip>:48322/again and accepting the new certificate warning. If you mount your own certificate (see Networking Setup - Using Custom Certificates), the same certificate persists across restarts and you only need to trust it once.
Access the web application:
https://<server-ip>:8080/Accept certificate warning:
Click Advanced
Click Proceed to <server-ip> (unsafe) or similar option

Verify access:
When connecting to a CloudXR.js application:
Tip: For rapid development and debugging, you can test your CloudXR.js application on a desktop browser before deploying to Meta Quest 3. Detailed setup instructions are provided in the Isaac Lab Client guide.
For network and firewall configuration requirements, including port setup and bandwidth recommendations, see the Networking Setup Guide.
Symptoms:
Solutions:
Symptoms:
Solutions:
Symptoms:
Solutions:
npm run dev-server:https, ensure runtime connection uses wss:// not ws://Symptoms:
Solutions: