Skip to main content
Version: 10

Remotely Connecting to the Web Interface

When running MoveIt Pro on one computer (such as a robot controller or a Virtual Machine), and wanting to access the web interface from another computer (such as your host machine or a laptop), you need to set up network access to the required ports.

Required Ports

The packaged web UI listens on loopback port 80. Its nginx proxy routes /api, /ros, /video, and /terminal to the backend, so a browser using the packaged UI needs port 80 plus port 3203, which carries the WebRTC camera media that no HTTP proxy can forward. The backend also exposes these ports for direct clients and separate-host Vite development:

  • Loopback port 80: Web UI frontend (reach it through SSH or HTTPS ingress)
  • Port 3200: REST API (backend services)
  • Port 3201: MoveIt Pro WebSocket bridge (foxglove_bridge) for browser-frontend ROS communication
  • Port 3202: WebRTC/WHEP video signaling (the browser exchanges an SDP offer and answer here; proxied under /video/)
  • Port 3203: WebRTC ICE media, UDP with TCP on the same port number as a fallback for UDP-blocking networks. The browser connects to it directly, so it must be reachable from the browser machine even when everything else is proxied
  • Port 3204: Instance discovery endpoint. Expose it only on trusted networks when remote frontends need to discover deployments.
  • Port 3205: Terminal service backing the in-UI Terminal pane (MoveIt Pro 9.4+). Customer deployments bind it to loopback and reach it through the web UI's /terminal/ proxy; development launch surfaces may expose it for a separate-host Vite proxy.

32003203 is one contiguous range on purpose: it is everything a browser or a direct client can need. Forwarding or allowing that single range covers the REST API, the WebSocket bridge, video signaling, and the WebRTC media the browser must reach itself. Discovery and the terminal service follow on 3204 and 3205; customer deployments keep the terminal on loopback behind the port-80 proxy.

Open backend ports only when a direct client or separate-host development setup needs them. Port 3204 is relevant only for remote instance discovery, and port 3205 only when a separate-host development frontend proxies the Terminal pane.

Exposing endpoints over a network

Authenticated backend operations require MOVEIT_FRONTEND_KEY, and backend ports serve TLS. In MoveIt Pro 10.0 and later, the signed /identity bootstrap, /health, API documentation and schema resources, and HTTP preflight requests remain unauthenticated. Direct and operator-managed clients must verify /identity before transmitting credentials. Any origin that can reach the REST port can read /identity through CORS. The response discloses a persistent, linkable deployment UUID; a per-process incarnation UUID; the public JWK and fingerprint; validity timestamps; the caller's echoed nonce; and the signature. Keep this disclosure inside a trusted network boundary. It is not PickNik telemetry or collection and does not alter PickNik's data-collection policy: the request and response remain on infrastructure controlled by the operator. The packaged 10.0 web UI still sends its configured shared key directly; signed identity preflight is part of the later standalone-shell connection flow. Set a deployment-specific key before exposing a deployment on a wider network. The packaged browser entry point is loopback-only HTTP on port 80; use an HTTPS reverse proxy or SSH tunnel for remote access. See Endpoint Security.

Requires MoveIt Pro 9.4 or later

Port 3201 runs foxglove_bridge starting in MoveIt Pro 9.4; earlier versions ran rosbridge_server on the same port.

Common Use Cases

Accessing from a Virtual Machine to Host

If you're running MoveIt Pro inside a Virtual Machine (VM), reach its loopback-only web interface through an SSH tunnel from the host operating system.

Parallels (macOS)

  1. Ensure SSH is enabled in the VM.

  2. Find the VM hostname or IP from the Parallels network settings.

  3. Create the frontend tunnel from macOS:

    ssh -L 80:localhost:80 -L 3203:localhost:3203 <vm-user>@<vm-hostname-or-ip>
  4. Keep that SSH session open and browse to http://localhost.

The 3203 forward carries WebRTC camera media over its TCP fallback; without it the UI loads but camera panes stay blank.

VirtualBox

  1. Power off your VM.

  2. Open VirtualBox Manager.

  3. Select your VM and click Settings.

  4. Go to NetworkAdapter 1AdvancedPort Forwarding.

  5. Add an SSH rule: Name ssh, Protocol TCP, Host Port 2222, Guest Port 22.

  6. Start the VM and create the frontend tunnel:

    ssh -p 2222 -L 80:localhost:80 -L 3203:localhost:3203 <vm-user>@localhost
  7. Keep that SSH session open and browse to http://localhost.

The packaged frontend listens on loopback so the frontend key is never sent over a remote plaintext HTTP connection.

Accessing from a Remote Laptop

If MoveIt Pro is running on a robot controller or remote computer, use SSH port forwarding or place the loopback-only frontend behind an HTTPS reverse proxy.

Ubuntu/Debian Firewall Configuration

If you're using ufw (Uncomplicated Firewall):

# WebRTC camera media. Required whenever the browser is not on this machine.
sudo ufw allow 3203/udp

# Everything a browser or a direct backend client can reach, in one range:
# REST API, WebSocket bridge, video signaling, and the WebRTC media above.
sudo ufw allow 3200:3203/tcp

# Enable the firewall if not already enabled
sudo ufw enable

# Check the status
sudo ufw status

For more restrictive access, you can limit connections to specific IP addresses:

# Replace 192.168.1.100 with your laptop's IP address. Open direct backend
# ports only when clients validate a hostname-correct operator certificate.
sudo ufw allow from 192.168.1.100 to any port 3200:3203 proto tcp
sudo ufw allow from 192.168.1.100 to any port 3203 proto udp

Accessing the Interface

Do not browse directly to http://<robot-ip-address>: that would send the bearer key over plaintext. Use the SSH tunnel below and browse to http://localhost, or configure a trusted HTTPS ingress before exposing the frontend remotely.

SSH Port Forwarding (Advanced)

If you have SSH access to the computer running MoveIt Pro, use SSH port forwarding to tunnel the loopback-only frontend:

# Replace user@robot-ip with your SSH username and hostname/IP address.
# 3203 carries WebRTC camera media over its TCP fallback.
ssh -L 80:localhost:80 \
-L 3203:localhost:3203 \
user@robot-ip

Keep this SSH session open and access the web interface at http://localhost in your browser.

Troubleshooting

Web Interface Loads but Features Don't Work

If the web interface loads but some features are missing or not working:

  1. Verify that port 80 is accessible for the packaged web UI
  2. If everything works except camera panes, verify port 3203 is reachable from the browser machine; WebRTC media does not travel the port-80 proxy
  3. Check your browser's developer console (F12) for connection errors
  4. Ensure no firewall or security software is blocking the connections

Cannot Connect to Web Interface

  1. Verify MoveIt Pro is running on the remote computer

  2. Check that the correct ports are forwarded/opened in the firewall

  3. Test connectivity to individual ports using:

    # Test from your local machine
    backend_host=moveit-pro.example.com
    curl --cacert /path/to/ca.pem "https://${backend_host}:3200/health"
  4. Ensure there are no network routing issues between the computers

Performance Issues

When accessing the web interface remotely, you may experience slower performance, especially with video streaming. This is normal over network connections. For best performance:

  • Use a wired network connection when possible
  • Ensure good WiFi signal strength if using wireless
  • Consider reducing video quality settings if streaming is laggy

Security Considerations

When exposing MoveIt Pro ports over a network:

  • Only open these ports on trusted networks
  • Use SSH tunneling for connections over untrusted networks
  • Protect and rotate MOVEIT_FRONTEND_KEY; do not reuse the local-development value
  • Configure trusted TLS certificates for direct backend clients
  • Keep the port-80 browser entry point on loopback; use SSH or a trusted HTTPS ingress
  • Limit port access to specific IP addresses when possible using firewall rules

For production deployments requiring remote access over the internet, please contact support@picknik.ai for guidance on secure deployment architectures.