Short answer
If your browser or Godot game already uses WebRTC peer connections and only lacks a place to exchange the handshake, NetCraftGames can provide that. It creates rooms with a short code, lets peers join, and relays offer, answer and ice messages between them over a room-scoped WebSocket. After the handshake your players talk to each other directly. We do not relay game or media traffic, and we offer no TURN service yet.
What this lane includes
- Rooms of 2 to 16 peers, created and joined with a short code. Rooms expire after two hours.
- Signaling over WSS: peers connect with an opaque, room-scoped token and forward offer, answer and ICE messages to a target peer.
- A reference browser connector that handles room requests and the signaling socket. Your game still owns
RTCPeerConnection, offers, answers, ICE, game state and reconnects. - Exact origin checks, so only your listed websites can create rooms.
- Rate and size limits on signaling messages.
What it does not include
- No TURN media relay. STUN only discovers a peer's public address. When a symmetric NAT or strict firewall blocks a direct path, a TURN server must relay the traffic. Without one, those players cannot connect. NetCraftGames will not offer TURN until metering and real connectivity testing exist.
- No dedicated server. This lane runs no game process, so there is no command, port or health probe.
- No Unity support. Unity is not listed for this lane because no verified Unity WebRTC integration exists.
Limits
| Limit | Current value |
|---|---|
| Browser WebSocket gateway: largest frame | 64 KiB |
| Browser WebSocket gateway: rate per connection | up to 120 messages and 2 MiB per second |
| WebRTC signaling: largest message | 16 KiB |
| WebRTC room size | 2 to 16 peers; rooms expire after two hours |
| Idle shutdown | after 10 continuous minutes with zero players (needs player-count reporting) |
| Region | us-east-1 only |
Steps
- Declare the relayed WebRTC laneIn the manifest set the mode to relayed and the transport to webrtc, and state that your signaling adapter is implemented. No archive, command or ports are needed.
- Create or join a roomThe client requests a room, or joins one with a short code, and receives a room id, a peer id, a token and the signaling WebSocket address.
- Connect the signaling socketOpen the WebSocket address with the room-scoped token. Never log or store that address or token; treat it like a password.
- Exchange offers, answers and ICEForward offer, answer and ice messages to the target peer id. Peers announce themselves with peers, peer-joined and peer-left events.
- Handle failure honestlyIf ICE fails, show the player a clear message and a retry. Do not promise connectivity on every network, because there is no relay.
- Test with two real networksJoin from two different home or mobile networks and confirm data flows before launch.
Honest gaps
- A published signaling configuration is not a certified peer connection. Two real clients, on different networks, must complete ICE and exchange data before you can claim compatibility.
- One controller process routes signals today, so rooms are not spread across machines.
- Peer-to-peer games have no authoritative server, so cheating and desync are your design problem.
Frequently asked questions
Does NetCraftGames include a TURN server for WebRTC?
No. It provides room signaling only: offers, answers and ICE messages. STUN can discover addresses but cannot relay media, and without TURN, peers behind symmetric NATs or strict firewalls may not connect. NetCraftGames will not offer TURN until metering and real connectivity testing exist, and says so on this page.
How many players fit in a WebRTC room?
Rooms hold two to sixteen peers and expire after two hours. Each admitted peer, including one still opening its socket, uses one connection slot against your plan's connection ceiling. Larger rooms depend on your game's own peer-to-peer design, because every peer connects to the others directly.
Sources
- MDN: WebRTC protocols (ICE, STUN, TURN), accessed October 3, 2026