Managing tModLoader Memory and Large Worlds via AMP

Vanilla Terraria barely sips memory, but tModLoader is a different animal. Once a server loads Calamity, Thorium, and a half dozen QoL mods on top of a Large world, the .NET process can climb past 6 GB resident, and the default AMP instance ceiling will OOM crash the world during cavern generation. This guide configures a Terraria tModLoader instance under CubeCoders AMP on Windows Server, allocates a realistic heap, and automates mod sync through tModLoader's built in workshop client so the operator never has to drag dll files by hand.

Prerequisites

• Windows Server 2022 with the latest .NET 6 desktop runtime installed.
• A licensed AMP instance manager (ADS controller running).
• At least 8 GB RAM and 4 vCPU dedicated to the Terraria instance.
• TCP 7777 open at the host firewall.

Step 1: Create a tModLoader Instance

Inside AMP's web UI, open the Instance Manager, click Create Instance, and select the TerrariaTModLoader module. Name the instance something stable like tml-main. AMP fetches the latest tModLoader release through SteamCMD automatically.

$# Optional: verify SteamCMD pulled the right branch
$Get-ChildItem "C:\AMP\Instances\tml-main\tModLoader" | Select-Object Name

Step 2: Raise the Memory Ceiling

AMP enforces a per instance memory cap independent of what Windows allows. Without raising it, the .NET garbage collector starts thrashing well before the OS would complain. Open the instance, go to Configuration, Performance, and lift the Maximum Memory Usage field to a value below total host RAM minus 2 GB.

$Maximum Memory Usage: 7168 MB
$CPU Limit (soft):       0   (unlimited)
$Process Priority:       AboveNormal

Step 3: World and Difficulty Settings

$World Name:    Calamitas
$World Size:    Large
$Difficulty:    Master
$Max Players:   16
$Server Port:   7777
$Auto Create:   3   (Large Master Corruption)

Step 4: Automated Workshop Mod Sync

tModLoader supports a enabled.json file that lists the exact mods the server should keep installed. Combined with an AMP scheduled task that runs steamcmd with the workshop_download_item directive, the operator gets unattended mod updates.

$[
$  "CalamityMod",
$  "ThoriumMod",
$  "MagicStorage",
$  "BossChecklist",
$  "RecipeBrowser"
$]

$Action: Run Shell Command
$Command: steamcmd.exe +login anonymous \
$  +workshop_download_item 1281930 2824688072 \
$  +workshop_download_item 1281930 911192541 \
$  +quit
$Then: Trigger "Restart Instance"

Performance and Tuning

• Keep heap headroom: never set AMP memory above total RAM minus 2 GB, the OS needs page cache for save flushes.
• Disable Windows Defender realtime scanning on the instance folder, it doubles world save times.
• Pin the instance to performance cores with start /AFFINITY if the host has hybrid CPU topology.

Conclusion

AMP turns tModLoader from a fragile single executable into a managed instance with a real memory budget, scheduled mod sync, and a recoverable lifecycle. With the heap correctly sized and Workshop sync running on a schedule, even a Large Master world packed with heavy content mods will stay online between patch cycles.