Launch Day Checklist

This is the finish line. Before your game servers go live, walk through this checklist to catch the issues that cause launch-day failures.

Pre-Launch Recommendations

• Set a launch date on that is early in the week so that any major bugs can be addressed before the weekend starts. We highly recommend a Tuesday or at latest Wednesday.
• Set a launch time that best reflects your team’s early morning availability.
• Understand that Steam and other 3rd parties often have a slow cache refresh so hitting the target time perfectly is not always a guarantee. Plan to start some of those processes early so players aren’t waiting.

Server Build

• Server builds and runs on Linux (not just Windows)
• Server runs headless without a GPU or display
• Server starts within 60 seconds
• Server binary is stripped of debug symbols/code mapping
• Server build does not contain client-only assets (textures, audio, UI)

Shutdown and Signals

• Server handles SIGTERM and shuts down gracefully
• Graceful shutdown completes within 10 seconds
• Server exits with code 0 on clean shutdown
• Server exits with non-zero code on crash
• No data loss on graceful shutdown

Configuration

• Config files use a standard format (JSON, YAML, TOML)
• All config options are documented (type, range, default)
• Port numbers are configurable via startup arguments
• Server binds to 0.0.0.0 or custom IP, not just 127.0.0.1
• Server works on non-default ports

Networking

• All required ports are documented (port number, protocol, purpose)
• Server works in a shared hosting environment (non-default ports)
• Game client supports connecting to non-default ports
• Query protocol responds correctly (if implemented)

Console

• STDOUT produces “server online” and “server stopping” events
• Player join/leave events include platform IDs
• STDIN accepts at minimum: stop, save, status, list, kick, ban
• Console commands return execution results/feedback (not silent)

Save Data

• Save files are in a predictable, configurable location
• Auto-save runs at regular intervals (5-15 minutes)
• Save writes are atomic (temp file then rename)
• Backup rotation keeps previous saves
• Server detects and recovers from dirty shutdown
• Worlds can be moved between servers (portability)

Authentication

• Server verifies player identity server-side (not trusting the client)
• Invalid authentication results in disconnect, not fallback mode
• Auth failures are logged with relevant details

Player Management

• Players are tracked by platform ID, not username
• Ban system supports permanent and timed bans
• Player data is stored in JSON in a known location

Publishing

• Server is downloadable without purchasing the game (if using SteamCMD, anonymous access is enabled)
• Version is identifiable (version.txt, —version flag, or manifest)
• Update process is documented for hosting providers

Hosting Provider Coordination

• Share resource requirements with hosting providers (CPU, RAM, disk per server instance)
• Test deployment on your primary hosting provider (Nodecraft, etc.)
• Verify the download/install pipeline works end-to-end
• Confirm update automation works (SteamCMD update, archive replacement)
• Provide hosting-specific documentation (ports, configs, startup arguments)
• If supporting mods at launch, verify mod installation works on hosted servers

Day-of Monitoring

• Someone on the team is monitoring server logs during launch
• Crash reporting is active and sending data to your team
• You have a process for pushing an emergency server update if needed
• Communication channel with hosting providers is active (for urgent issues)

Common Launch-Day Failures

Failures we’ve seen repeatedly across game launches:

Caution

• SteamCMD rate limits: If your game goes viral (think Palworld), SteamCMD downloads can be throttled or fail under load. Hosting platforms can only download one server per Steam account at a time. Anonymous access helps, but plan for delays.
• Config typos crashing servers: A single wrong character in a config file can prevent a server from starting. Make sure your server validates config at startup and reports clear errors.
• Untested Linux build: “It works on Windows” is not enough. If you haven’t tested your Linux build in a container environment, you will discover missing dependencies in production.
• Port conflicts: Two servers assigned the same port on the same machine. This is the hosting platform’s problem, but if your server doesn’t report a clear error when it can’t bind to a port, diagnosis is slow.
• Save directory permissions: The server process doesn’t have write permission to the save directory. Silent failure, no saves, players lose progress.

Post-Launch: First 48 Hours

Hour 0-4: Watch for crashes, connection failures, and auth issues. These show up immediately under load.

Hour 4-24: Watch for memory leaks, save corruption, and performance degradation under sustained load. These emerge as servers run longer than your test sessions.

Hour 24-48: Watch for long-running session stability. Some bugs only appear after 24+ hours of continuous operation.

When to push the first patch: Unless there’s a critical bug (crash, data loss, security), wait 24 hours before pushing a server update. Hosting platforms need time to stabilize their deployments, and a rapid cycle of updates during launch creates more problems than it solves.