Cloud Hosting

Managed Servers for Signaling

These providers offer managed signaling or real-time messaging layers suitable for exchanging session descriptions, ICE candidates, presence, and lightweight control messages between peers. They typically provide WebSocket or HTTP-based APIs and handle scaling, reliability, and security for you. When choosing a provider, consider factors such as latency, geographic coverage, pricing, and support for your preferred signaling protocol.

Peerix protects all data sent through the signaling layer with built-in encryption and namespace hashing, so you can use any provider that meets your requirements without worrying about data security. For production applications, we recommend choosing a provider that supports secure connections (e.g., wss:// or https://) and offers authentication mechanisms to protect your signaling messages from unauthorized access.

NATS

The NATS messaging system is a popular choice for signaling due to its high performance, scalability, and support for pub/sub messaging patterns.

NATS services suitable for signaling:

• Synadia Cloud: a fully managed NATS service with global coverage and support for WebSocket connections.

Free public NATS endpoints for development:

• Official demo server: wss://demo.nats.io:8443

MQTT Brokers

MQTT is a lightweight messaging protocol designed for low-bandwidth, high-latency networks.

MQTT brokers suitable for signaling:

• HiveMQ: free public MQTT broker with WebSocket support.
• EMQX: managed MQTT service with a free tier and WebSocket support.

Free public MQTT endpoints for development:

• EMQX: wss://broker.emqx.io:8084/mqtt
• HiveMQ: wss://broker.hivemq.com:8084/mqtt

Mercure Hubs

Mercure is a real-time hub for publishing and subscribing to updates, built on HTTP and Server-Sent Events (SSE).

Mercure services suitable for signaling:

• Mercure Cloud

Free public Mercure endpoints for development:

• Mercure: https://demo.mercure.rocks/.well-known/mercure

Other Providers

Other real-time messaging providers that can be used for signaling include:

• Centrifugo: a real-time messaging server with WebSocket support and alternative transport options.
• Supabase Realtime: a real-time database and messaging service built on top of PostgreSQL.

Cloud TURN Servers

If you do not want to self-host TURN , start with a managed provider that offers a free tier. These services provide TURN servers that can relay media when direct peer-to-peer connections are not possible due to network restrictions. When choosing a provider, consider factors such as geographic coverage, reliability, pricing, and support for short-lived credentials.

Free TURN Providers

How to Choose

For production workloads, compare providers using the criteria below rather than choosing solely by price:

• Coverage and latency for the regions where your peers connect.
• Quotas and rate limits for free plans.
• Authentication model (static credentials vs. time-limited credentials).
• Support for UDP and TCP/TLS relay paths.
• Reliability guarantees, logging policy, and compliance requirements.
• Pricing predictability when you outgrow the free tier.

Recommendation

• Development and demos: any provider with a free tier is usually fine.
• Staging and pre-production: choose a provider that supports short-lived credentials and has coverage near your test users.
• Production: use paid managed TURN or self-host for full control and predictable behavior.

Verify Before Shipping

Regardless of provider, validate your TURN setup before release:

1. Open the Trickle ICE WebRTC test page.
2. Add your TURN endpoint and credentials.
3. Gather candidates and confirm at least one relay candidate is returned.
4. Repeat this test from different networks (home, office, mobile hotspot, and VPN).

If you cannot consistently obtain relay candidates, review credentials, firewall rules, and provider limits before moving forward.