The Pattern
You follow a WebRTC tutorial. Two browser tabs. Camera works. Video streams. You deploy it. Nothing connects.
This isn't a bug in your code. Localhost creates an environment where all the hard parts of WebRTC are silently skipped.
What Localhost Hides
Browsers exempt localhost and 127.0.0.1 from HTTPS requirements for camera and microphone access. They also shortcut network traversal because both peers share the same IP, NAT behavior, and firewall rules. The browser connects peers using host ICE candidates alone - no STUN discovery, no TURN relays, no NAT traversal.
This works perfectly for demos. It teaches you nothing about production.
The Real Requirements
Production WebRTC needs four things tutorials skip:
Signaling infrastructure. WebRTC doesn't provide peer discovery. You need a server to exchange SDP offers/answers and ICE candidates. Most tutorials hard-code this or copy-paste between tabs.
STUN servers. Peers behind NAT need to discover their public IPs. Without STUN, they only offer local addresses like 192.168.x.x - useless across networks.
TURN relays. When direct peer connections fail - corporate firewalls, symmetric NAT, mobile carriers - media must relay through TURN servers. Industry data shows 5-50% of WebRTC sessions require TURN. These servers cost bandwidth and money.
HTTPS everywhere. Browsers require secure contexts for camera, microphone, and screen sharing in production. Localhost gets an exception. HTTP deployments get nothing.
The Failure Modes
Connections hang when ICE gathering times out behind restrictive firewalls. Video never appears when TURN isn't configured. Peers "connect" but send nothing when one side lacks server-reflexive candidates.
Browser fragmentation adds complexity - Chrome and Safari handle VP9 codec support differently. Network conditions that never surface on localhost (jitter, packet loss, bandwidth constraints) become critical in production.
What This Means
WebRTC testing on localhost validates browser-internal limits: stream counts, data channel capacity, memory constraints. What it doesn't test: real networking.
Production deployments need TURN infrastructure (self-hosted or third-party), proper ICE candidate gathering across network boundaries, HTTPS/TLS configuration, and cross-browser testing under actual network conditions.
The developer behind P2P Vision Web built a demo specifically to show these production requirements. Source code includes STUN/TURN configuration, signaling server implementation, and HTTPS setup.
Localhost isn't wrong for initial development. Just don't mistake it for a production environment. The network problems WebRTC solves only appear when you leave your machine.