The wrapper is the process that manages the daemon. It is not the daemon itself — it is a supervisor that downloads, integrity-checks and lifecycle-manages versioned daemon binaries.
In production the wrapper is what your service unit starts. The daemon JAR refuses to run otherwise unless given an explicit development flag.
Upgrading an agent that is also the thing you would use to perform the upgrade is awkward. Splitting them solves it: the wrapper stays running while the daemon underneath it is replaced, so a daemon version can be swapped remotely without the daemon being up and without restarting the wrapper.
Daemon JARs are loaded through a custom classloader, which is what makes that hot swap possible.
The wrapper exposes its own token-authenticated HTTPS control API, by default on port 2146. This is how the panel starts, stops, restarts and upgrades a daemon that may not be running.
It is a separate port from the daemon's own API on 2145 and 2147, and it must be reachable from the panel. See Ports & firewall.
The wrapper reads wrapper.properties from its root directory, set with -directory:
If -directory is omitted it uses the directory containing its own JAR.
The root directory is where the wrapper writes its configuration, staged daemon binaries and runtime state — keep it on persistent storage.
Daemon binaries are integrity-checked before being run. For development against an unsigned build, the wrapper accepts a flag to bypass that check. Do not use it in production: it exists so module and daemon developers can run local builds, and it disables the guarantee that the binary a node runs is the one we published.
The wrapper being up does not mean the daemon is. If the panel reports a node offline while
systemctl status gamedash-daemon looks healthy, you are most likely looking at a running
wrapper with a daemon that failed to start underneath it. The daemon's own logs are the place
to look.