Godot game server hosting
For a native Godot game using ENet, you need a machine that keeps your headless game process running and accepts UDP traffic on the game's port. A static web host alone cannot run that process.
Test scope: the downloadable project below was run with Godot 4.5.1 on Linux. Two local clients connected, received their own reliable RPC echo, and disconnected. A client also exited with an error when the server was unavailable. This is a connectivity check, not a full game, load test or cloud deployment.
1. Check your game's transport
Godot's high-level multiplayer API can use ENetMultiplayerPeer for native clients. ENet uses UDP, so allowing only TCP on the same port will not make it reachable. This guide uses port 7000/udp.
Browser exports need a different transport. Browsers cannot use raw ENet UDP sockets. Use WebSockets or WebRTC and design the server for that transport; the ENet project here will not connect from an HTML5 export. See the HTML5 hosting guide for WebSocket hosting.
2. Run the smallest headless check
Download the complete test project and unzip it. Install the official Godot 4.5.1 Linux binary, or use a compatible Godot 4 installation. The commands assume its executable is available as godot.
cd godot-server
godot --headless --path . -- --server --port=7000
# Expected: LISTENING UDP 7000
In another terminal, run a client from the same directory:
godot --headless --path . -- --host=127.0.0.1 --port=7000 --token=my-check
# Expected: PASS echoed my-check in ... ms
The same scene and RPC declarations run on both sides. The client sends a token to server peer 1; the server replies only to the sender. Nothing is drawn because the purpose is to verify networking before adding your game's scene, state synchronization and server-side rules.
Stop the manual server with Ctrl+C before running the automated check:
python3 smoke-test.py /absolute/path/to/godot
# Tests two clients on UDP port 17000 and cleans up its processes.
# Optional unused port: python3 smoke-test.py /path/to/godot 17001
Our run passed both echoes, both disconnects, and the unreachable-server case. All traffic stayed on loopback, so echo time is not a measurement of your players' internet latency.
3. Pick a Linux host that accepts UDP
A VPS gives you a public IP and control of inbound ports. The DigitalOcean pricing table lists a $4/month 512 MiB instance and a $6/month 1 GiB instance. Those are price examples, not tested capacity recommendations. Measure your game's memory, CPU and outbound traffic before choosing a size.
If you use a managed container host, confirm that it exposes UDP and gives clients a reachable address and port. A browser-oriented service that only exposes HTTPS is not enough for this ENet server. Compare architectures and prices in the host comparison.
4. Start it on the VPS and open the port
Copy the project to /opt/godot-game and place the executable at /opt/godot/godot. Match the binary to the server CPU architecture. Keep the client and server on a compatible Godot version.
# On the server, after copying the project and binary:
/opt/godot/godot --headless --path /opt/godot-game -- --server --port=7000
# If UFW is already your firewall, add an inbound UDP rule:
sudo ufw allow 7000/udp
Add the same UDP rule to your provider's cloud firewall. Preserve your SSH access rules. If you host at home, router port forwarding and carrier-grade NAT are additional obstacles; a public VPS avoids that particular setup.
From your own computer, replace the address below with the VPS public IP:
godot --headless --path . -- --host=YOUR_VPS_IP --port=7000 --token=remote-check
A successful echo from outside the VPS verifies the route through the firewalls. A ping response or a TCP port check does not verify this UDP application. The remote step is for you to run; it was not part of our local test.
5. Keep it running after SSH disconnects
The download includes a systemd unit for the test project. It runs as an unprivileged account, keeps Godot's user data writable in a dedicated state directory, and restarts after failure.
sudo useradd --system --user-group --no-create-home godotgame
sudo chmod 755 /opt/godot/godot
# Make the project readable by godotgame before starting.
sudo install -m 644 game-server.service /etc/systemd/system/game-server.service
sudo systemctl daemon-reload
sudo systemctl enable --now game-server
sudo systemctl status game-server --no-pager
sudo journalctl -u game-server -n 50 --no-pager
For your own game, change the unit's paths and startup arguments. An exported dedicated-server build can strip visual resources and is preferable to keeping the editor binary in production. Follow Godot's dedicated-server export instructions; this guide's smoke test runs the source project with the editor binary.
If a client cannot connect
- No listening message: inspect Godot's error output and check whether another process uses the UDP port.
- Local check passes, remote check fails: verify the public IP, UDP rules in both firewalls, and the server process.
127.0.0.1always means the client's own computer. - Connection succeeds but an RPC fails: check matching node paths, RPC signatures and authority. The example loads the same scene on both peers.
- Web export fails: change the networking transport. Opening more UDP ports will not give a browser raw UDP access.
Get the files and documentation
Download the project ZIP, or inspect main.gd, project.godot, main.tscn and smoke-test.py.
Transport and RPC details: Godot high-level multiplayer and ENetMultiplayerPeer reference.