# Hosting a Godot WebSocket multiplayer server

> NetCraftGames is designed to host a Godot 4 server that uses WebSocketMultiplayerPeer, so web exports can play. Browsers must connect over wss, and the gateway terminates TLS for you. Godot WebRTC games use the separate signaling lane. Not certified yet.

*NetCraftGames (NCG) by Charging Bull Software. Last updated: 2026-10-03. Canonical page: https://netcraftgames.com/engines/godot-websocket/*

## 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](https://netcraftgames.com/engines/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](https://netcraftgames.com/guides/websocket-vs-udp-browser-multiplayer/) for the trade-offs.

## What you provide

- A Linux x86_64 dedicated server export that creates a `WebSocketMultiplayerPeer` server 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


1. **Export a dedicated server.** Use Export as dedicated server in a Linux preset and export Linux x86_64, as in the ENet checklist.
2. **Create the WebSocket server.** Create a `WebSocketMultiplayerPeer`, call `create_server(port)` on a fixed TCP port, and assign it to `multiplayer.multiplayer_peer`. Leave TLS to the gateway unless your own setup needs it.
3. **Make the browser client use wss.** Connect with `create_client("wss://...")` using the address from your connection configuration. A plain `ws://` connection from an HTTPS page is blocked by the browser.
4. **Declare allowed origins.** List the exact website origins of your game page, for example `https://play.example.com`. Wildcards are not accepted.
5. **Add health and join probes.** Answer 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`.
6. **Test in a real browser.** After 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](https://docs.godotengine.org/en/stable/classes/class_websocketmultiplayerpeer.html), accessed 2026-10-03
- [Godot Docs: Exporting for dedicated servers](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_dedicated_servers.html), accessed 2026-10-03

## Related pages

- [WebSocket vs UDP for browser multiplayer](https://netcraftgames.com/guides/websocket-vs-udp-browser-multiplayer/): Browsers cannot use raw UDP. Compare WebSocket, WebRTC data channels and native UDP for multiplayer games, and pick the right transport for your players.
- [WebRTC signaling for browser games, explained](https://netcraftgames.com/guides/webrtc-signaling-for-browser-games/): What a WebRTC signaling server does for a browser multiplayer game, why STUN is not a relay, when TURN is needed, and the offer, answer and ICE flow.
- [WebRTC signaling for browser and Godot games](https://netcraftgames.com/engines/browser-webrtc/): NetCraftGames offers managed WebRTC room signaling for browser and Godot games: offers, answers and ICE only. There is no TURN relay yet.