Deployment

Deployment

Production deployment combines compatible builds, stable configuration, persistent databases, network routing, TLS, logs, and a controlled update process.

Build Set

A typical deployment contains:

• master-server build;
• spawner build when rooms are started on demand;
• room-server build;
• client build for each supported platform;
• matching application.cfg files and imported config files;
• database and platform provider configuration;
• persistent MST security key ring.

Build all processes from the same MST revision. Mixed client/master or room/master revisions can break packet serialization, opcodes, permission protocol, and persistence contracts.

Startup Order

1. Start and verify the database service when an external provider is used.
2. Start the master and confirm that its socket and HTTP endpoints bind successfully.
3. Start each spawner and confirm that it receives the spawner permission and registers.
4. Spawn or start room processes and confirm room_server registration.
5. Release clients only after the backend health checks pass.

Network Layout

• Bind internal database ports to trusted networks only.
• Keep room-management and spawner endpoints private where possible.
• Expose public WebSocket traffic through WSS.
• Use dedicated ports and document every firewall rule.
• Configure the public room endpoint separately from an internal or redirected endpoint when NAT or a reverse proxy is involved.

Persistent Files

Back up and preserve:

• production databases;
• mst-security.keys.json or the configured key-ring file;
• production config files;
• TLS certificates and renewal procedures;
• logs required for diagnostics and audit.

Do not place mutable database files inside a directory replaced wholesale during deployment.

Configuration Separation

Use separate main configs for master, room, spawner, and client roles when they run as independent builds. Shared defaults can be imported:

@import "common.cfg"
@import "security.cfg"

A spawner may pass room startup arguments supplied by the master. Confirm the actual process command line instead of assuming a spawned room reads a standalone config file.

Update Procedure

1. Back up databases, configs, and key rings.
2. Build and stage the complete compatible process set.
3. Run automated tests and focused local integration tests.
4. Stop traffic or drain rooms according to the game's policy.
5. Apply required database migrations.
6. Deploy master, spawner, room, and client revisions in the planned compatibility window.
7. Verify login, profile loading, room registration, spawning, and persistence.
8. Keep the previous binaries and migration rollback procedure available.

Minimum Production Checks

• public WSS connection succeeds;
• invalid permission credentials are rejected;
• valid room and spawner credentials are accepted;
• duplicate user login follows the configured session policy;
• profile changes persist after reconnect;
• room termination does not leave stale registry state;
• logs are written to the expected path and do not expose protected values;
• database backups can be restored.