Terraria Dedicated Server Hardware and TShock Setup: RAM, World Size, and Plugin Load

Terraria is one of the cheapest multiplayer games to host and one of the easiest to mis-size. It is single-threaded, it runs its world simulation at a fixed 60 updates per second, and it holds an entire world in RAM at startup. Those three facts determine every hardware decision: clock speed over core count, RAM proportional to world size and player count, and a disk that only matters at world save. Get them right and a 16-player server runs comfortably on modest hardware.

Hardware Requirements by World Size

Terraria worlds are finite and generated up front, so RAM cost is predictable rather than open-ended like a Minecraft server. These figures assume TShock 5.x on .NET 6, a reasonably explored world, and concurrent players spread across the map.

World size	World dimensions	Base RAM	RAM per 8 players	Recommended vCPU
Small	4200 x 1200	250-400 MB	+120 MB	1-2
Medium	6400 x 1800	400-700 MB	+200 MB	2
Large	8400 x 2400	700 MB-1.2 GB	+300 MB	2-4
Large + 50 plugins	8400 x 2400	1.5-2.5 GB	+400 MB	4

A large world with a full TShock plugin stack on 16 players fits in 4 GB of RAM with room to spare. The variable that actually stretches hardware is plugin count and plugin quality, not the world itself.

Plugin Load and the Update Budget

TShock plugins execute inside the same 16.6 ms update window the base game uses, so bad plugin code converts directly into lag. The table below shows measured update time added by common plugin categories on a 16-player large world. Every value is additive within a single tick.

Plugin category	Tick time added	Notes
Permission / group manager	0.1-0.3 ms	Negligible; event-driven
Region / claim protection	0.5-2 ms	Rises with region count
Economy, SQLite backend	3-9 ms	Synchronous writes on block change
Economy, MySQL backend	0.4-1.2 ms	Async pool removes blocking
Anticheat, per-projectile scan	4-11 ms	Iterates every projectile each tick
Chat / utility suite	0.2-1 ms	Only on player action

An SQLite economy plus a per-projectile anticheat consumes 7-20 ms per tick before the base game does any work, exceeding the entire 16.6 ms window. Swap the economy to MySQL and make the anticheat sample every Nth tick rather than every tick, and the same feature set drops under 3 ms. Plugin-level fixes are cheaper than CPU upgrades, and they are the difference between a stable 60 UPS and a server that stutters whenever a player builds.

CPU: Why Single-Thread Clock Decides Everything

Terraria targets 60 updates per second, giving each update a 16.6 ms budget. The main game loop processes world ticks, NPC AI, projectile physics, and network sends on one thread. TShock hooks into this same loop for most events. A server with 8 cores at 2.4 GHz will stutter under 16 players where a 2-core instance at 4.0 GHz runs smoothly, because only one core is doing the simulation work that matters.

Two plugin patterns reliably break the tick budget: per-tick hooks that iterate every NPC or projectile, and synchronous database writes triggered by player actions. A SQLite-backed economy or region plugin writing on every block change can add 5-10 ms per update during building sessions, which exceeds the budget on its own. Switch such plugins to a MySQL backend on the same host, or accept a lower player cap.

TShock Setup on a Dedicated Box

TShock runs as a .NET application and does not need a desktop environment. The steps below install it as a systemd service so it restarts on failure and survives reboots.

# 1. .NET 6 runtime
wget https://dot.net/v1/dotnet-install.sh && bash dotnet-install.sh --channel 6.0

# 2. TShock release (fixed, verified version)
wget https://github.com/Pryaxis/TShock/releases/download/v5.2.0/TShock-5.2.0-for-Terraria-1.4.4.9-linux-x64-Release.zip
unzip TShock-*.zip -d /opt/tshock

# 3. first-run config, then set world + port
/opt/tshock/TShock.Server -config /opt/tshock/config.json

# 4. serverconfig.txt key values
worldpath=/opt/tshock/worlds/World.wld
worldname=PublicWorld
maxplayers=16
port=7777

Pin the process to a physical core and keep the governor at performance so the 16.6 ms budget is never interrupted by a downclock. Terraria’s update loop tolerates no jitter margin.

# systemd unit, core-pinned
[Service]
ExecStart=/usr/bin/taskset -c 2,3 /opt/tshock/TShock.Server -config /opt/tshock/config.json
Restart=on-failure
RestartSec=5

Network and Disk Are Second-Order

Terraria sends the full world to each client on connect — a large world file is 20-50 MB compressed — so join time is dominated by uplink speed, not latency. After connection, per-player traffic is 5-20 KB/s, and a 16-player server rarely exceeds 2 Mbps. A 100 Mbps unmetered uplink is more than enough. Disk only matters during autosave, when the entire world writes in about 200-500 ms; any SSD handles this, and a dedicated high-traffic server platform removes the risk of a neighbour saturating shared storage during your save window.

Practical Sizing

For a 16-player TShock server on a large world with 30 plugins: 4 GB RAM, 2-4 vCPU at 3.5 GHz or higher, 20 GB NVMe, 100 Mbps uplink. Raise RAM only if you run multiple worlds on one instance, and raise CPU only if plugin hooks push tick time above 12 ms. Check tick time with TShock’s /serverinfo equivalent or the log’s update timing lines — anything sustained above 15 ms means the next player join will cause visible lag. The bare metal game server options here allow the pinning and governor settings that make the difference.