Skip to main content

Set up TShock accounts and grant limited administrator permissions

Confirm TShock and the supported Terraria version

TShock adds accounts, groups and permissions to Terraria. Its account system is separate from your CloudExa panel login and from a shared server-join password. Confirm that the service actually runs TShock, then note the installed TShock and Terraria versions. A vanilla Terraria server will not recognise TShock account commands.

Use documentation for that release. Older TShock guides use an /auth setup flow, while newer releases use /setup. Do not mix the two or replace the server software just to match a tutorial. Read the setup instruction printed by your running server and consult its bundled command help.

Back up accounts as well as the world

Before changing access, keep a complete stopped backup containing the world, TShock configuration, account/group database and any plugins. If this installation uses an external database, ask support for a consistent database backup alongside the files. A world file alone cannot restore accounts or group permissions.

Do not delete the TShock database or setup lock to recover an account. That can remove users and reopen initial setup. If setup is already complete but the owner account is inaccessible, use a trusted existing administrator or support-assisted recovery while retaining all current data.

Complete first setup privately

For an unconfigured server whose startup explicitly requests /setup, join the server and follow that release’s displayed code workflow. Keep the one-time setup code private; it grants temporary powerful access. The exact account-registration step varies by release, so use the current prompt rather than assuming every version creates the same owner group.

The TShock /user command supports account management; its help guide.documents /user add username password group and /user group username group. Replace placeholders with a unique account name, strong password and an existing appropriate group. Only an authorised administrator should run these commands. Never paste real passwords into a shared support conversation.

Give staff only the permissions they need

Create individual staff accounts instead of sharing the owner login. Start with an ordinary group and add only the documented permission nodes needed for a task, using the installed release’s group help. Group inheritance can grant permissions indirectly, so inspect the parent group too. Avoid granting a wildcard merely to silence a single “permission denied” message.

A superadmin can bypass protections that ordinary players must follow. Keep that role for trusted owners and use narrower roles for moderation. Server-side character settings and building protections may have special bypass permissions; test them with an ordinary account because a superadmin’s success is not proof that normal access is configured correctly.

Verify login, limits and persistence

Log out and sign in with the intended staff account, then test the specific action you granted. Also test a prohibited action and a normal player account. Check the server response for the exact command and permission rather than repeatedly broadening the role.

Complete the setup-locking step prescribed by the running release and confirm the setup code no longer grants access. After a normal restart, verify the account and group still work. Keep a private role-change record. If anything behaves unexpectedly, restore the recorded group membership or configuration rather than resetting users or replacing the world.

Further reading

Looking for another game? Browse game server setup and troubleshooting guides.