Short answer
Yes, by design, for a Godot 4 server exported for Linux x86_64 that uses WebSocketMultiplayerPeer. Players on web exports connect over wss:// to a NetCraftGames gateway, which terminates TLS and forwards frames to your server. Native clients can use WebSocket too, but ENet is the better transport for them. Godot WebRTC (WebRTCMultiplayerPeer) is a different lane: see browser WebRTC.
Why WebSocket for the browser
Browsers cannot open raw UDP sockets, so ENet is out for web exports. WebSocket works over TCP and is allowed from a page, but a page served over HTTPS may only open wss:// connections. Godot's create_server() accepts a port, an optional bind address and optional TLS server options, which lets you terminate TLS yourself; on NetCraftGames the gateway does that for you, so your server can focus on the game. Read WebSocket vs UDP for the trade-offs.
What you provide
- A Linux x86_64 dedicated server export that creates a
WebSocketMultiplayerPeerserver on a fixed TCP port. - A health reply (HTTP or TCP) and a join probe.
- The exact browser origins that may connect, such as
https://yourgame.example. Origin matching is exact. - A client that connects to the
wss://address from your connection configuration.
Steps
- Export a dedicated serverUse Export as dedicated server in a Linux preset and export Linux x86_64, as in the ENet checklist.
- Create the WebSocket serverCreate a
WebSocketMultiplayerPeer, callcreate_server(port)on a fixed TCP port, and assign it tomultiplayer.multiplayer_peer. Leave TLS to the gateway unless your own setup needs it. - Make the browser client use wssConnect with
create_client("wss://...")using the address from your connection configuration. A plainws://connection from an HTTPS page is blocked by the browser. - Declare allowed originsList the exact website origins of your game page, for example
https://play.example.com. Wildcards are not accepted. - Add health and join probesAnswer an HTTP request on a declared port with a known body so we can prove a join, then pack the export as a clean
.tar.gz. - Test in a real browserAfter launch, open your game page from a different network in more than one browser and join.
Limits of the gateway
| 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 |
Honest gaps
- Not certified. TLS termination, browser compatibility and a real browser join still need live evidence.
- Higher latency than UDP. WebSocket is TCP, so a lost packet delays the packets behind it.
- Frame limits apply to every message: keep game messages small.
- No anti-cheat; origin checks stop other websites from using your server, not cheaters.
Frequently asked questions
Why does my Godot web export need wss?
A page loaded over HTTPS can only open secure WebSocket connections, so a plain ws address is blocked as mixed content. With NetCraftGames, players connect to a wss address on the gateway, which terminates TLS and forwards frames to your server, so the server itself does not have to hold certificates.
Should I use WebSocket or WebRTC for a Godot browser game?
Use WebSocket when a server is authoritative, because everyone connects to it and results are easy to reason about. Use WebRTC when you want peer-to-peer data channels and accept connectivity risk: NetCraftGames offers signaling but no TURN relay, so some restrictive networks will fail to connect peers.
Sources
- Godot Docs: WebSocketMultiplayerPeer, accessed October 3, 2026
- Godot Docs: Exporting for dedicated servers, accessed October 3, 2026