What a connection config file must contain

The short answer

A deployment manifest is for the host: it names the engine and transport, the exact start command, each port and protocol, how to check health and join, where saves live and how to stop. A connection configuration is for your players' clients: the address, port, protocol, whether TLS is used, and the build version they must match. NetCraftGames reads your submission to produce both, and you review what it proposes.

The deployment manifest, field by field

A real example

This is the Unity NGO template from the NetCraftGames integration docs. Replace the digest with the SHA-256 of your own archive.

{
  "engine": "unity-ngo", "transport": "udp", "platforms": ["windows", "android", "ios"],
  "mode": "dedicated", "networkingImplemented": true, "os": "linux", "arch": "x64",
  "command": ["/game/UnityServer.x86_64", "-batchmode", "-nographics"],
  "ports": [{ "port": 7777, "protocol": "udp" }], "profile": "standard",
  "savePath": "/game/saves",
  "health": { "type": "udp", "port": 7777, "request": "health", "expected": "healthy" },
  "playerProbe": { "type": "http", "port": 9090, "path": "/players" },
  "joinProbe": { "type": "udp", "port": 7777, "request": "join-status", "expected": "joinable" },
  "shutdown": { "signal": "SIGTERM", "graceSeconds": 30 }, "idleSupported": true,
  "artifact": { "id": "<archive id>", "sha256": "<64 lowercase hex characters>" }
}

Custom native TCP/UDP (direct): your own protocol

If your server speaks its own raw TCP or UDP protocol, with no Mirror, Netcode, Unreal, Godot or WebSocket library behind it, declare engine as custom-native and transport as tcp or udp. This lane is supported, and it is deliberately limited:

• Configuration and deployment only. We start your Linux x64 build on an isolated machine and check the checks you declare. Nothing about your game's protocol is certified.
• Direct, with no gateway. Players connect to the running server's public IP address and port. There is no TLS termination, no origin check and no WebSocket relay from us, so any encryption or authentication is yours to build.
• You supply the join probe. An open port never proves a player could join. Declare a joinProbe that your server really answers: for TCP, a banner your server sends first (we connect, send nothing, read the first bytes and match expected); or an http path, or a udp request and reply. Without it the release stays at "configuration needed".
• A launcher script is fine. If a shell script starts your server with its own arguments, use that script as command[0] so the arguments are kept. The image provides bash and a POSIX sh.
• Linux libraries. Programs are read for the glibc they need, and a build that needs a newer glibc than the worker image (2.39, Ubuntu 24.04) is held with advice, so build on Ubuntu 24.04.

{
  "engine": "custom-native", "transport": "tcp", "platforms": ["windows"],
  "mode": "dedicated", "networkingImplemented": true, "os": "linux", "arch": "x64",
  "command": ["/game/Server/run-server.sh"],
  "ports": [{ "port": 47777, "protocol": "tcp" }], "profile": "standard",
  "health": { "type": "tcp", "port": 47777 },
  "joinProbe": { "type": "tcp", "port": 47777, "expected": "YOUR-GAME-BANNER" },
  "shutdown": { "signal": "SIGTERM", "graceSeconds": 30 }, "idleSupported": false,
  "artifact": { "id": "<archive id>", "sha256": "<64 lowercase hex characters>" }
}

When you declare Mirror or Netcode for GameObjects for a Unity player build that holds none of their assemblies, the code reading raises a non-blocking advisory and suggests this lane. It never rewrites your declaration for you.

Rules that cause most rejections

• Paths are inside the machine, not on yours. command[0] and savePath must be literal paths under /game/.
• TCP and UDP probes differ. HTTP and TCP probes need a TCP port; UDP probes need a UDP port. A TCP connect alone never proves a UDP game works.
• Declare real ports. Every port your server opens, with the right protocol, and nothing it does not.
• No secrets. Credentials in the archive are detected and the build is rejected; the values are never repeated back.
• Digest of the exact file. Run sha256sum server.tar.gz on the file you upload.

What a player connection config must carry

NetCraftGames builds a schema-checked JSON document named netcraft.connection-config/1, plus engine-specific code snippets, from what it found in your submission and what you declared. Secrets are never included in it.

Browser and WebSocket games are reached at wss://<gateway host>/play/<gameId>, which requires an allowed Origin and forwards to your server at the root path, or at the one path you write as wsPath in your manifest. UDP and raw TCP games, including custom native servers, are reached directly at the running server's public address: the file then carries a generic direct client section (host, port, protocol and what your join probe expects) instead of an engine snippet. WebRTC games use room signaling. Never put a secret in a client config: players can read it.

Frequently asked questions

Written by Charging Bull Software. Facts on this page are checked against the product source and dated sources listed above; where something is not proven, the page says so.