tModLoader Dedicated Server Container

Updated 2026-10-07 08:49 UTC · Refreshed hourly · Metric definitions

Run a modded Terraria server in Docker, with a built-in web dashboard for managing worlds, Workshop mods, players, and backups. Keep your server's data across container updates and manage it from your browser or Docker Compose.

This independently maintained project has its own features, fixes, and releases. It is not affiliated with Re-Logic or the tModLoader team.

Container images · Docker Hub · Releases · Changelog

What it includes

• Web dashboard: see server health, loaded mods, connected players, and recent activity; send commands through an interactive console and cancel saved drafts.
• Mod configuration editor: edit existing UTF-8 configuration files with syntax checks for JSON, YAML, TOML, INI, and XML. Other text formats can be edited without syntax validation. Restart the server to load saved changes.
• World cleanup: delete unused worlds after confirmation; running and draft-selected worlds are protected. Deletion includes their local backup files.
• Worlds and playthroughs: create or switch worlds, save mod profiles, and pair a world with its settings and mod selection for later use.
• Steam Workshop management: download mods and collections, look up Workshop URLs or IDs without an API key, and reuse cached content when Steam is unavailable. Workshop search requires a Steam API key.
• Backups and recovery: create or schedule backups, verify archives, and restore from the dashboard. Backups briefly stop the game and disconnect players.
• Persistent server data: worlds, mods, settings, and logs survive container replacement. The game and dashboard run as a dedicated non-root user.
• AMD64 and ARM64 support: Linux images for both architectures, with automated build checks and real-server startup tests before publication.

Image tags and updates

The release workflow also supports publishing verified images to Docker Hub. See Docker Hub publishing setup and retries.

Tag	Behavior
3.0.1	Fixed stable release; matches the GitHub Release tag
3.0.1-preview	Fixed preview release; marked as a GitHub prerelease
latest	Follow the latest tested stable build
preview	Follow the latest tested preview build

Release notes identify the default runtime channel; the installed tModLoader version is shown in the dashboard. Numbered image tags are never overwritten. By default, the server can update its persistent runtime at startup independently of the image; use TMOD_AUTO_UPDATE=0 to retain the selected runtime. Container releases still deliver dashboard, security, system-library and downloader updates.

Container images publish when VERSION changes on master, or through a manual workflow run. New upstream tModLoader releases are handled by the runtime updater; they do not trigger scheduled image builds. Images contain the server management tools and system dependencies. First startup downloads the newest supported release for the selected stable or preview channel and installs its matching native .NET runtime into /data. Internet access is required for this initial installation, even with TMOD_AUTO_UPDATE=0; that setting disables subsequent automatic updates. Later starts reuse the cached runtime.

Persistent player history

The Players page shows everyone recorded on this server and everyone recorded on its currently loaded world, with first/last join dates and visit counts. Search and paging cover the full history. Tracking runs with the game, including when the dashboard is closed or disabled, and begins when this feature is installed. A small server-only component captures character joins and connection addresses; clients do not install an extra mod. It is built using the downloaded runtime's compiler and rebuilt when that runtime or the component changes. If it cannot load, English join announcements (TMOD_LANGUAGE=en-US) provide name-only history. Older visits cannot be reconstructed reliably.

Character history groups visits by character name and lists observed connection addresses for that name. Names can be reused or changed, and IP addresses can be shared or change; these records do not identify verified accounts or unique people. Older appearance-based records are combined by name in the dashboard while retaining their visit counts, dates and recorded ban targets. No portrait artwork is required.

The server-only helper appears as ContainerCharacters in the server's mod list; startup ensures it is enabled. Its build diagnostics are in /data/.tmod-control/character-bridge/build.log.

History also retains server-observed IP addresses or supported Steam identifiers from native player queries and native network log entries that explicitly pair an endpoint with the character. A verified account name is not supplied for direct-IP players. The cards show that limitation and each recorded ban target; no IP or account is inferred from a character name or connection timing.

Ban player reviews and appends the selected identifier to the persistent native ban list, even after the player has left. It blocks subsequent connections using that identifier and does not kick an existing session. IP bans can affect other people sharing an address and can be bypassed by changing addresses. Names without a captured identifier cannot be banned offline. Custom server configurations continue to require manual ban-list management.

World history follows the world's internal GUID across switches and file renames. A newly generated world with the same filename starts a separate history; copies of the same world retain the same identity. Unknown world formats still allow server-wide tracking but cannot be assigned a world history.

Records persist in /data/.tmod-control/player-history.sqlite3. World switches, container recreation, and world restores do not clear them. This control data is excluded from the dashboard's world backups; preserve the full data volume (or copy the database with the server stopped) when migrating the entire server.

Startup updates and compatibility

With TMOD_AUTO_UPDATE=1, startup checks the image's stable or preview channel for supported Terraria 1.4.4 releases. Set TMOD_UPDATE_CHANNEL to override the channel, or TMOD_UPDATE_VERSION to pin an exact supported release. Pins may advance the runtime; downgrades require a matching data checkpoint. Major Terraria branch migrations are blocked until explicitly supported.

Downloads are cached in /data/.tmod-control/updates, including each installed runtime and its native .NET installation. Workshop updates happen in a separate copy of the game data. The candidate must load every enabled mod and its required dependencies, load or generate a copied world, reach server readiness, and exit cleanly. Only then are the runtime and staged mods selected. The live world is not replaced with the test copy. Startup checks cannot prove every mod works throughout gameplay.

If download or compatibility checks fail, the installed runtime and live mods are retained together. The dashboard shows the available version, blocked-update reason, and Workshop/compatibility diagnostics. If live startup then fails, the pre-update runtime and world/mod checkpoint are restored automatically. Custom server configurations are not automatically updated because their external paths cannot be safely redirected for the compatibility test.

The overview checks for new releases in the background (cached for six hours; failed checks retry after fifteen minutes). Check for updates refreshes the notice, rate-limited to once per minute; it does not install anything. Startup is the installation point. Restart game and apply updates runs the same checks from the dashboard without restarting the container; it disconnects players and leaves saved drafts unapplied. Restore previous runtime and data queues recovery for the next game restart and requires confirmation: worlds, mods, mod configs and saved settings revert to the checkpoint. Current data is retained in another checkpoint until recovery passes its health check; both recovery copies are then deleted automatically. Failed recovery retains them. Credentials are preserved, and automatic updates are held until Restart game and apply updates is selected. Queued recovery can be performed with Restart game and restore checkpoint while the dashboard remains available. Compose values are not part of a checkpoint.

Staging needs free space for three copies of game data plus TMOD_UPDATE_MIN_FREE_MB (default 1024 MiB). Runtime caches and update checkpoints are excluded from ordinary backup archives and retained on the data volume; backups record the actual selected runtime for compatibility checks. Keep an independent backup of this volume for disaster recovery. Existing dashboard Apply operations still intentionally refresh the selected Workshop mods; the automatic compatibility gate applies to startup updates.

Set TMOD_UPDATE_TEST_TIMEOUT above the default 600 seconds if a large modded world needs longer to test or start. A timeout blocks the update rather than assuming compatibility.

For Drydock, use a numbered stable tag and opt into version updates with this Compose label (the double dollar sign escapes Compose interpolation):

labels:
  - 'dd.tag.include=^[0-9]+\.[0-9]+\.[0-9]+$$'

This restricts updates to stable container versions. The image's source label points to this repository, where matching release tags provide release notes. See Drydock's getting started guide.

Dashboard gallery

Captured from the current 3.2.0 dashboard interface with demonstration server data. Workshop cards show real public Steam titles and artwork in an illustrative results list. Select a screenshot to view it full size.

Overview	Worlds
Health, players, settings, and backup status	World details, uptime, creation, and Journey permissions

Backups & recovery	Steam Workshop search
Archive contents, verification, and compatibility	Search controls, Steam preview artwork, and mod selection

Enter a Steam API key on the Workshop page to unlock search and dependency checks. After validation, the key field is hidden; use Replace API key to change it. Adding a mod checks nested Workshop requirements and lists missing items in an Add / Cancel dialog before saving the selection as a draft. Client-only dependencies are excluded. Apply the draft when ready to restart. Importing a Workshop URL or ID works without a key; adding without a key requires acknowledging that dependencies have not been checked. Checks use Steam's declared requirements, so they cannot detect undeclared dependencies or version conflicts.

Keys entered on the page are encrypted in /data/.tmod-control/workshop.key, with Linux permissions 0600. Authenticated Workshop requests derive an encryption key from your admin token using Argon2id and a random salt, and use Fernet authenticated encryption. The admin token and derived encryption key are never saved with the ciphertext. Use a strong, unique admin token: the protection of the encrypted Steam key depends on its strength. Changing or resetting the admin token requires re-entering the Steam API key. Previously saved plaintext keys are encrypted on the next authenticated settings or Workshop request. The key is never returned by the dashboard API or included in container backup archives. Keep the data volume to preserve it across recreations; re-enter it when moving to a fresh volume. An optional mounted TMOD_WORKSHOP_KEY_FILE remains an externally managed plaintext input; a key saved on the page takes precedence. Use HTTPS for administration over untrusted networks.

Getting started

You need Docker Engine with Compose or Docker Desktop, a 64-bit AMD64 or ARM64 Linux container environment, and enough memory and disk space for your mod pack. Players need tModLoader clients compatible with the server's version and mods.

1. Get the files

Clone this repository, or download docker-compose.yml and .env.example into the same folder.

git clone https://github.com/Crosis47/tmodloader.git
cd tmodloader

Copy .env.example to .env:

cp .env.example .env

On Windows PowerShell, use Copy-Item .env.example .env instead.

2. Choose how to manage settings

Open .env. For browser-based configuration, set:

TMOD_WEB_ENABLED=1

This enables settings edits, world selection, and loading profiles and playthroughs in the dashboard. Environment values seed the initial settings; afterward, saved web values take precedence. Save changes in the dashboard, then use Review & apply to apply them and restart the game.

Set TMOD_WEB_ENABLED=0 to manage settings through .env and run without the dashboard or its setup step. Existing installations can explicitly retain TMOD_CONFIG_SOURCE=env to keep environment-managed settings with dashboard monitoring, console, and backup controls.

Review the essential settings below before starting, particularly the game password, world name, and mods.

Server passwords can be changed or removed in Configuration when web management is enabled. Save the password as a draft, then review and apply to restart the game. Passwords are never returned by the settings API; the protected server data stores the value needed to generate the game configuration. A saved dashboard password (including an empty value) overrides the Compose password or password file on later starts.

3. Start and complete setup

docker compose pull
docker compose up -d
docker compose logs --tail=100 --follow tmodloader

With the dashboard enabled, the game waits for first-run admin setup:

1. Find the one-time setup code in the container logs.
2. Open http://SERVER-IP:8080 from your home network, or http://localhost:8080 on the Docker host.
3. Enter the code and choose an admin token (8–256 ASCII characters, no whitespace). Save it in your password manager; use it to sign in afterward.

The container saves a hashed credential in the persistent data directory and continues startup automatically. First-time mod downloads and world generation can take several minutes. Press Ctrl+C to stop following logs without stopping the server.

HTTP works for clients in 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 (RFC 1918), plus loopback. Other sources, including non-loopback IPv6, require HTTPS for setup and all dashboard access. HTTP traffic is unencrypted; use it only on a trusted network. The server checks the client source IP, not the URL.

Leave TMOD_WEB_ORIGIN empty when opening the server IP. For a hostname, set it to the exact browser origin. For HTTPS through a reverse proxy, also set TMOD_WEB_TRUSTED_PROXY to that proxy's IP as seen by the container, or its service name/network alias (for example, reverse-proxy) on a shared Docker network. Hostnames are resolved for each request; failed lookups do not trust forwarded headers. Use a name controlled by you on a trusted network. URLs, ports, wildcards, and subnets are not accepted. The proxy must preserve Host and overwrite X-Forwarded-For with the actual single client IP and X-Forwarded-Proto with http or https. Multi-proxy header chains are rejected. Restrict backend access to the proxy when publishing it.

Docker forwarding or another gateway can hide the original source IP behind a private address. This rule can only classify the IP the container actually sees; do not directly port-forward the HTTP dashboard to the internet. Use the HTTPS proxy with the trusted-proxy setting to preserve the original client identity.

4. Join the server

Check readiness in the dashboard or run:

docker compose ps

Once the server is healthy, connect from tModLoader to your Docker host's address on port 7777 (or your chosen TMOD_PORT). Allow that TCP port through the host firewall and forward it on your router if players connect over the internet.

Essential settings

The commented .env.example contains the full list of options. These are the main values to review for a new server:

Setting	Purpose / default
TMOD_WEB_ENABLED	1 enables the dashboard; 0 disables it and skips admin setup.
TMOD_WEB_PORT	Dashboard listening and published port in the supplied Compose configuration; defaults to 8080. Not editable in the dashboard.
TMOD_PASS	Initial game password, separate from the admin token. Empty means no game password. A saved Configuration password overrides it in web-managed mode.
TMOD_PORT	Game listening and published port in the supplied Compose configuration; defaults to 7777.
TMOD_WORLDNAME	Selects a saved world or creates it if missing; defaults to Docker.
TMOD_WORLDSIZE	New world size: 1 small, 2 medium, 3 large (default).
TMOD_DIFFICULTY	New world difficulty: 0 Classic, 1 Expert (default), 2 Master, 3 Journey.
TMOD_WORLDEVIL	New world evil: random (default), corruption, or crimson.
TMOD_MODS	Comma-separated Workshop mod IDs and collection:ID entries; empty by default.
TMOD_BACKUP_INTERVAL	Minutes between backups; 0 disables scheduling, 1440 means daily.

World creation and Journey permissions live on Worlds. New World opens the creation form. For saved Journey worlds, Server Journey defaults sets shared permissions, and Set Journey permissions on a world lets you inherit those values or save an override. Controls are hidden for non-Journey worlds and unreadable world types. Existing global permissions seed the initial server defaults.

Saving permissions does not change the running game; they take effect when that world next starts. Review & apply stages the selected world and opens the usual restart confirmation. Per-world overrides survive switching worlds and container restarts. Applying a playthrough's different Journey snapshot records it as that world's override. Server defaults remain unchanged.

Review saved changes opens a running-versus-saved comparison, including fields edited outside Configuration. A draft identical to the running settings does not trigger the saved-changes reminder. Unsaved form edits are not part of this review.

Select a name in Saved worlds to expand details from its last save: dimensions, difficulty, evil, seed, creation date, Hardmode status, special seeds, spawn and dungeon coordinates, and file sizes. Expanded entries remain open across refreshes. The current world has a status badge; other worlds have a Switch button. Current session uptime starts when the world finishes loading and resets on a game restart or world switch. Total uptime accumulates loaded time across sessions and persists with the world data. Tracking begins with this feature; earlier sessions are not included. Totals are checkpointed every five seconds and on normal shutdown; an abrupt kill can lose up to five seconds. Inactive worlds display Not active for their current session and retain their total. This is not player playtime. Metadata currently supports world formats 194–279; unreadable or unsupported headers show an explanation while file details and existing world-selection controls remain available.

World generation settings only affect new worlds. Choose an unused world name to generate a different world. Profiles and playthroughs do not archive world files or pin mod versions; keep backups before changing a world's mods.

After editing .env, recreate the container with docker compose up -d. In web mode, change saved settings in the dashboard. Docker ports, mounts, credentials, and configuration mode remain managed outside the dashboard. If you explicitly set TMOD_WEB_ORIGIN, update its port when changing the dashboard port.

Data and backups

Scheduled game restarts

The Game controls panel offers Save now (command delivery is reported; check the console for completion) and Restart now (reviewed save-and-restart with the configured countdown). Restart now preserves running settings and the runtime; it does not apply drafts or check updates.

During the countdown, Postpone restart delays this occurrence by 1–1440 minutes and Skip once / cancel countdown skips it without disabling the recurring schedule. Controls close once saving and stopping begin. Remaining-time chat warnings are configured with TMOD_RESTART_COUNTDOWN (default 300,60,10 seconds); only warnings within TMOD_RESTART_DELAY are used. For a five-minute warning period, set the delay to 300. Empty countdown settings disable those messages independently of the initial announcement.

Open Configuration → Scheduled restarts and choose a schedule:

Mode	Behavior
Disabled	Default; no automatic restarts.
Every X minutes	Interval in minutes; 0 disables it.
Every X days	1–3650 periods of exactly 24 hours from game startup.
Daily	Every day at the selected time.
Weekly	On the selected weekday at the selected time.
Monthly	On the selected day (1–31); use the last day in shorter months.

Daily, weekly, and monthly schedules use a 24-hour time and timezone, such as 04:00 in America/New_York. Defaults are 04:00 UTC, Sunday for weekly, day 1 for monthly, and 7 days for every-X-days mode. The form shows the fields for the selected mode. Set the warning delay in seconds and chat announcement, then save and apply. The warning begins when the schedule is due; the game stops after the delay (default 60 seconds, 0 skips waiting). An empty message omits the announcement.

Environment-managed servers use TMOD_RESTART_MODE, TMOD_RESTART_INTERVAL, TMOD_RESTART_DAYS, TMOD_RESTART_WEEKDAY, TMOD_RESTART_MONTHDAY, TMOD_RESTART_TIME, TMOD_RESTART_TIMEZONE, TMOD_RESTART_DELAY, and TMOD_RESTART_MESSAGE in .env. Recreate the container to apply them. The schedule works with the dashboard disabled too.

Scheduled restarts save and restart the game, disconnecting players while the dashboard stays available. They do not apply saved drafts or check for updates. Minute and day intervals reset whenever the game starts, including after a backup or settings apply. Calendar modes select the next future occurrence in the chosen timezone; a time skipped by daylight saving shifts forward by the clock-change gap, and a repeated time uses its first occurrence only. Busy or unhealthy servers defer the restart. Configuration shows the next planned restart and failures. A failed restart pauses the schedule for manual recovery; without the dashboard, the container exits for Docker's restart policy to handle it.

Autosave

Scheduled world saving is controlled by TMOD_AUTOSAVE_INTERVAL, in whole minutes (default 10; 0 disables scheduled saves). In the WebUI, open Configuration → Backups & autosave → Autosave interval (minutes), save the draft, then Apply & Restart. Applying disconnects players to restart the game; subsequent scheduled saves run without disconnecting them. The timer resets whenever the game starts.

With the WebUI disabled, set TMOD_AUTOSAVE_INTERVAL=5 in .env to save every five minutes, then recreate the container with docker compose up -d. In web-managed mode, saved WebUI values take precedence over .env after first boot.

Autosave updates the live world files; it does not create a backup archive. Use the separate backup interval to schedule recoverable archives.

Backup schedules and console retention

Configuration → Backups & autosave offers the same disabled, minutes, every-X-days, daily, weekly, and monthly modes for cold backups. Set the backup time and timezone separately from restarts. Short-month and daylight-saving rules match restart scheduling. The next planned backup appears in Configuration and Backups & recovery. Backups wait for a healthy, idle game and disconnect players while saving, archiving, and restarting. Backups take priority if both schedules become due together; the game start recalculates the restart timer.

Environment settings are TMOD_BACKUP_MODE, TMOD_BACKUP_INTERVAL, TMOD_BACKUP_DAYS, TMOD_BACKUP_WEEKDAY, TMOD_BACKUP_MONTHDAY, TMOD_BACKUP_TIME, and TMOD_BACKUP_TIMEZONE. Default mode is interval, with interval 0 leaving scheduling disabled. Backup attempts reset the schedule; failures remain visible in backup activity rather than retrying every few seconds.

Configuration → Runtime & logs controls console archive retention: TMOD_LOG_RETENTION_DAYS=30, TMOD_LOG_HISTORY_MAX_MB=512, and TMOD_LOG_ROTATE_MB=64. Age or history-size limits set to 0 disable that limit. Cleanup removes oldest console archives first and runs at game startup, rotation, and periodically while console output arrives. Active and previous console logs are outside the history budget; tModLoader's own logs, player history, and backup archives are unaffected. New settings take effect after saving and applying. Rotating the active log keeps console history available without allowing a single game session's console file to grow indefinitely.

The Autosave chat announcement field sets the message sent before each scheduled save (TMOD_AUTOSAVE_MESSAGE). Leave it empty to save silently.

Under Configuration → Runtime & logs, Shutdown warning delay (seconds) (TMOD_SHUTDOWN_DELAY, default 3, 0 skips waiting) controls the pause between the shutdown announcement and save-and-exit when Docker stops the container. Save and apply changes as above. Dashboard restarts and backups use their own stop flow. Keep Compose stop_grace_period longer than the warning delay plus TMOD_SHUTDOWN_TIMEOUT and shutdown overhead.

The supplied Compose file keeps persistent files beside it:

Host folder	Contents
./data	Worlds, mods, mod configuration, dashboard settings, and logs.
./backups	Backup archives created by the container.

Startup prepares these directories for the runtime user, including changing Linux host ownership to UID/GID 1000:1000. Use dedicated, writable local folders. Keep both folders when replacing the container.

Use Backups & recovery in the dashboard for manual backups and restoration. Scheduled backups are off by default. Keep a separate copy of your .env and any external secret or custom configuration files; container backups do not include them. Retain the original image version for recovery, since restores check the container build that created the archive.

Expand an archive row to see its backup date, last running world (when recorded), world files, enabled mods, Workshop selections, sizes, and included settings/logs. Inspect & verify checks the actual archive and fills in details for older backups. A saved world selection in an old backup is labeled as such; it is not proof that that world was running.

When an inspected backup uses the same tModLoader release but a different container build, Prepare for Running Container Version creates a verified copy for the current build. The original and world data remain unchanged. After inspection, compatible archives show Restore this backup in their expanded details. This opens a review popup that verifies the archive and available space before you confirm the restore. Different or unknown game releases cannot be converted automatically: retain the matching original image. Normal retention preserves backups from other container builds, so these preserved copies may require additional storage.

Help and project information

For startup or connection problems, begin with docker compose ps and docker compose logs --tail=200 tmodloader. Include relevant logs with an issue report, removing private information first.

• Configuration template
• Release history
• Contributing and development
• Security reporting
• License

Credits

Built on tModLoader for Terraria. Inspired by JACOBSMILE/tmodloader1.4. Thanks also to ldericher, rfvgyhn, guillheu, and FlorentLM for their earlier work.

Container code and scripts are distributed under LICENSE.md. Terraria, tModLoader, and bundled third-party tools retain their respective licenses.

The update card offers an opt-in Announce new tModLoader versions in game chat setting. It saves immediately without a restart, defaults to off, and sends one announcement per newly detected release while the game is healthy. The administration service checks in the background even without an open dashboard, using the existing release-check cache. Disabling and re-enabling the option does not repeat an already announced release.

Dashboard appearance

Use the Theme selector in the header to choose Slate & Teal, Forest, Ocean, Amethyst, Copper, Solarized, Nord, or Rose Pine. The sun/moon button switches between light and dark mode. Both choices are remembered in this browser; initial light/dark mode follows your system preference.

For GitHub API rate limits during release discovery, optionally provide TMOD_GITHUB_TOKEN as a runtime environment variable. Public release metadata requires no additional repository permissions. It is used only for GitHub API requests, is not a dashboard setting, and is not included in image builds. CI smoke tests use their temporary workflow token automatically.

With TMOD_WEB_ENABLED=0, settings are environment-managed even if TMOD_CONFIG_SOURCE=web remains set. Saved WebUI settings and game passwords are ignored but retained for when WebUI management is enabled again.

Port configuration

Set TMOD_PORT for the game (default 7777) and TMOD_WEB_PORT for the dashboard (default 8080). The supplied Compose configuration uses each setting directly for both the container listener and published host port.

For compatibility, Compose accepts TMOD_HOST_PORT and TMOD_WEB_HOST_PORT as fallbacks when their corresponding recommended setting is unset or empty. TMOD_PORT and TMOD_WEB_PORT take precedence when both names are supplied. Use the recommended names for new configurations.

If using a custom server configuration file, its game listening port must match TMOD_PORT. Custom Compose files can still map different host and container ports using Docker's normal port mapping.

Container and game readiness

With WebUI enabled, Docker health checks the dashboard while first-time admin setup is waiting. After admin setup, both the dashboard and game must be healthy. A stopped or failed game reports unhealthy after Docker's configured failed checks, while the dashboard remains available for recovery. Downloads, world generation, backups, and intentional game stops can also temporarily report unhealthy; health status alone does not restart the container. The dashboard reports game readiness separately. With TMOD_WEB_ENABLED=0, Docker health checks game readiness only.

The default startup grace period is 60 seconds, with checks every 30 seconds and three failures required to report unhealthy. A successful check ends the startup grace period. Keep the default unless measured startup time requires a longer grace period, such as initial downloads or world generation in headless mode. Adjust TMOD_HEALTH_START_PERIOD in the supplied Compose .env, or Docker's --health-start-period, to suit that startup time. This is a deployment setting, not a WebUI setting.

healthcheck --container selects the appropriate check; healthcheck (or --game) always checks the game. Internal update and recovery operations use game readiness. The dashboard readiness endpoint /healthz is accessible only from container loopback and returns no credentials or game information. Deployment ports, mounts, and settings management mode remain controlled outside the dashboard.

TCP listener recovery

The bundled server-only mod also manages the TCP listener lifecycle. Each accept thread owns its socket, preventing an older thread from closing a replacement listener when connection slots fill and reopen. Terraria still handles player limits, authentication, and packets. No client mod is required. This addresses listener recovery; it is not a substitute for firewall or access controls.

Upstream report: tModLoader/tModLoader#5470.