Server configuration

Server owners run one executable: sanverse-server.exe on Windows or ./sanverse-server on Linux. The executable loads server.json, starts the internal transport and JavaScript hosts, then loads resources in the declared order. An alternate file is selected with sanverse-server --config production.json.

{
  "name": "My Sanverse Server",
  "description": "Sanverse Definitive Edition server",
  "language": "sr",
  "announce": true,
  "masterlist": { "enabled": true, "serverId": "your-server-id", "token": "your-masterlist-token", "controlPlaneUrl": "https://api.example.com" },
  "network": { "bind": "0.0.0.0", "port": 22005, "maxPlayers": 500, "password": "", "timeout": 30000, "compression": true },
  "resources": ["database", "core", "gamemode"],
  "logging": { "level": "info", "console": true, "file": true, "directory": "logs" },
  "runtime": { "resourceDirectory": "resources", "startupTimeout": 5000, "restartOnCrash": true }
}

Each resource contains a resource.json manifest and compiled JavaScript entry point:

{ "name": "gamemode", "version": "1.0.0", "author": "Team", "main": "dist/index.js", "dependencies": ["core"] }

TypeScript is compiled to dist/index.js during development; the production server only loads the compiled entry point. server.toml and resource.toml are legacy compatibility fallbacks.

The supervisor owns child-process lifecycle. Node paths, host scripts and transport executables are internal runtime details and are not required as environment variables for normal operation.