Terraria Field guide

Move a Terraria world to a Linux server without replacing its progress

Move a Terraria world to Linux: preserve the original, select the intended file and verify progress after a restart.

Move a Terraria world to a Linux server without replacing its progress

Move a stopped copy of the existing world, give it an explicit filename on the destination and verify a recognizable landmark before players resume. A server that successfully generates an empty world has not completed your migration.

This procedure is for vanilla PC Terraria and the terraria account from our Linux setup guide. The destination uses /srv/terraria/worlds and /srv/terraria/serverconfig.txt. Keep compatible PC builds on both ends; the example launcher is 1.4.5.8. Console/mobile exports, tModLoader companion files and TShock databases require a different migration plan.

Find the copy that actually contains your latest session#

Save and leave the source world, then close the game or dedicated-server process that writes it. For our tmux server, attach to its console, enter save, wait, then enter exit. Prevent another administrator or automatic launcher from restarting the source during the transfer.

For a Windows PC world, inspect %USERPROFILE%\Documents\My Games\Terraria\Worlds. Documents may be redirected. Steam Cloud worlds can instead live under your actual Steam installation's userdata\<userID>\105600\remote\worlds. The official world reference describes the distinction. Confirm the selected world in the game before shutdown; the most familiar-looking folder is not necessarily active.

A 2026 transfer discussion describes apparently old progress after copying files. That thread concerns modded play; it is useful as a reminder to identify the active source, not as a vanilla file checklist.

Copy the vanilla .wld into a separate export folder while the writer is stopped. Keep the original and any adjacent rolling copies. Record the exact file size and hash. Do not rename a backup over your sole original or let cloud synchronization become the only remaining copy.

Upload into a staging directory#

Keep the original source unchanged until the destination loads the intended progress and survives a restart.

On the destination, use your normal SSH administrator to create a private staging directory:

bash
(
  set -eu
  umask 077
  mkdir "$HOME/terraria-import"
)

An existing directory makes this stop; inspect that earlier import instead of mixing transfers. From the workstation, replace the three obvious placeholders:

bash
scp /PATH/TO/Coop.wld YOUR_SSH_USER@YOUR_VPS_IP:terraria-import/Coop.wld

The example deliberately uses Coop.wld, without spaces, to avoid ambiguous quoting in launch wrappers. On the destination, record sha256sum "$HOME/terraria-import/Coop.wld" and compare it with the source hash using a local checksum utility. A matching hash verifies transfer bytes, not world health.

Stop any destination Terraria instance before continuing. Retain its previous selected world and configuration using the backup procedure. Neither a private staging folder nor a new filename makes concurrent writers safe.

Install a separate selected file with the right owner#

Run the following from the destination administrative SSH account. It rejects a symlink source or an occupied destination filename; choose a fresh name if this is a repeated migration:

bash
(
  set -eu
  terraria_source="$HOME/terraria-import/Coop.wld"
  terraria_target=/srv/terraria/worlds/ImportedCoop.wld
  test -f "$terraria_source"
  test ! -L "$terraria_source"
  test -s "$terraria_source"
  sudo test -d /srv/terraria/worlds
  sudo test ! -L /srv/terraria/worlds
  sudo test ! -e "$terraria_target"
  sudo test ! -L "$terraria_target"
  sudo install -o terraria -g terraria -m 600 \
    "$terraria_source" "$terraria_target"
  sudo -u terraria test -r "$terraria_target"
)

Edit /srv/terraria/serverconfig.txt and set the selector explicitly:

ini
world=/srv/terraria/worlds/ImportedCoop.wld
worldpath=/srv/terraria/worlds
port=7777

Keep the existing password and player limit in that file. Remove active autocreate entries and check that another world= line or command-line -world is not selecting something else. Do not use recursive permission changes or make the world writable by everybody to solve an ownership error.

Start the destination and inspect meaningful progress#

Enter the existing terraria tmux session, or create it under that account if no session exists. With no other instance running, launch:

bash
cd /opt/terraria-release/1458/Linux
./TerrariaServer -config /srv/terraria/serverconfig.txt

Confirm the expected build and successful load. Join from a compatible PC client using the destination address. Inspect a recent building, a chest containing known world items and a known progression milestone. A matching display name alone cannot identify the right save.

The world does not carry a player's personal inventory. Character data remains separate, so players should use their existing characters and back up those saves themselves. An unexplored minimap alone is not proof of missing terrain.

Retire the old writer after a restart check#

Save and stop the destination through its console, restart with the same configuration, then join again. Confirm that a small agreed change persists. Leave the old host stopped throughout this check to avoid two diverging copies that both appear authoritative.

Only then share the new address with the group. Retain the source export, checksum and old destination backup until the new server has a verified off-host backup. If progress is wrong, stop the destination and recheck the source selection; copying additional random files over the running world makes that investigation harder.