7 Days to Die Admin Commands for Moderating a Server

If you need to remove one player, a short command list is more useful than a cheat catalog. This reference checks moderation syntax on the V3.3.0 public-branch dedicated server: kick a player with a reason, add and remove timed bans, manage admin access, edit the whitelist and send an announcement. The running server’s help output is the final word if your build differs. For a UI-based comparison of player actions and other routine host controls, see our control panel tasks to test first.

For a focused guide to server-side teleportplayer, see how to teleport players on a 7 Days to Die server.

For these same jobs without typing IDs, Game Hosting’s 7 Days to Die server panel has a Players tab with online player IDs and actions for kick, timed bans, admin access, whitelist and announcements. Choose a player from the server’s list, then use the action that matches the incident; the panel is useful when you would rather select an account than enter its identifier by hand.

Confirm the server build and where to run commands#

This guide was checked on October 7, 2026, against the dedicated-server package on the public branch, build 25661908. Its Telnet connection reported V3.3.0 (b18), compatibility version V3.3.0. The official V3.3.0 Stable notes identify the current Stable release; this test did not cover an Experimental branch or console-client commands.

Run server commands from an admin-capable in-game console, the server’s local Telnet interface, or a hosting panel. On the dedicated server, type help to list commands and help ban, help admin, help whitelist or help kick for the syntax your server supports. Do not paste a command into the server process’s standard input and expect it to run.

The examples below use the current V3.3 help format. Replace each placeholder with a real value from your server; remove the angle brackets and do not include them literally. The test used disposable IDs in a private world, not real player accounts.

Keep the server version and command context together when you copy a command into notes. A dedicated server’s command list can differ from an old guide, another branch or a console client. If help returns a different argument order, follow the running server’s output and update your saved instructions. Do not test examples by choosing a live player at random: use a private test account or stay with read-only commands such as help, admin list, whitelist list and ban list until you have confirmed the target.

Find the exact player before you moderate#

Use the online player list or your panel to identify the account connected to the server. V3.3 help accepts a player name or entity ID for targets that are online, and a platform plus platform ID for offline ban, admin or whitelist entries. Keep the full platform identifier together when your server displays it as Steam_… or EOS_…; a display name alone can be ambiguous.

Before acting, compare the player’s name and ID with the session you mean to moderate. If the command returns “not a valid entity id, player name or user id,” recheck the server and identifier instead of trying a different account at random. The panel’s Players tab can select an account shown by the server and expose its platform ID for review.

Use the same identifier consistently for follow-up work. A name is easier to recognize, but the help text says names and entity IDs are for online targets in the ban, admin and whitelist commands. The platform-ID form is the option for an offline account. Do not swap a Steam ID for an EOS ID, trim a prefix or reuse an ID copied from another server’s chat history. If you are unsure which account a name refers to, wait until the player is online and match the identifier from that server before changing permissions or access.

Kick a connected player with a reason#

The current server’s help kick describes a kick with an optional reason and gives this format:

kick playername reason

For example, replace the placeholders with the player’s current name and a short reason: kick PlayerName spam. The server help says the command kicks the user. A test against a made-up name was rejected as an invalid target, so this guide does not claim a successful kick or test what a connected player sees. Use the exact player name shown by your live server and confirm the target before sending the command.

A kick removes the player from the current session; use a ban when the intent is to keep an account from joining again. Do not assume the optional reason automatically creates a permanent record of the incident. Record the player ID, time, reason and action in your own moderation notes.

Keep the reason brief and tied to the server rule, such as spam or base griefing. The reason helps moderators understand why the command was sent; it is not a substitute for checking the player name before execution. If the player should be allowed back after a warning, a kick is the narrower action. If the same behavior requires a time-limited restriction, use ban add with a duration instead and tell the group how long the ban lasts.

Add a timed ban and check its entry#

The current V3.3 help lists this order for a ban:

ban add <platform_id> <duration> <unit> [reason] [displayname]

A tested example with a disposable Steam ID was:

ban add Steam_<platform_id> 15 minutes "D02 test reason" "D02 Dummy Player"

Use a real Steam_… or EOS_… identifier from the server, choose a finite duration, and replace the example reason and display name. The current help allows minutes, hours, days, weeks, months and years. A name or entity-ID target must be online; the platform-ID form can be used for an offline account.

Check the result before you close the console:

ban list

On the isolated V3.3 server, the list showed the test entry’s expiration, platform ID, display name and reason. Remove a ban by its identifier when you are ready to let that account return:

ban remove <platform_id>

The test server confirmed that the entry disappeared from ban list. A timed ban ends according to the duration you selected; do not describe it as permanent unless you choose a permanent option supported by your server’s current help.

Run ban list after adding or removing an entry, especially if another moderator was working in the console at the same time. Read the expiration and reason in the returned row before reporting the result. If the ID does not appear, check for a typo or whether you used a display name where a platform ID is required. Do not add a second ban just because the first command gave delayed feedback; inspect the list first so the record does not contain duplicate or conflicting actions.

Add or remove an admin deliberately#

The V3.3 server help shows this command shape:

admin add <platform_id> <level> [displayname]
admin list
admin remove <platform_id>

A disposable Steam ID appeared in admin list after adding it at level 0; a separate dummy EOS ID was also listed and removed. The game help defines level 0 as maximum permission. Give a moderator only the level your command-permission setup requires, and confirm the result with admin list. Do not copy level 0 as a default simply because it worked in a test.

For online players, the help also accepts a name or entity ID. For offline accounts, use the platform-ID form. Remove access when the role ends, then check the admin list again so an old test account or former moderator is not left with permissions.

Keep admin access separate from everyday player access. The test confirms how to add, list and remove an entry, but it does not map each permission level to a safe moderator role. Review the command-permission settings on your own server before choosing a level, and reserve the most powerful level for the people who actually need it. If you are only trying to let someone join a private world, use the whitelist rather than granting admin rights.

Use the whitelist without locking out the group#

The V3.3 help provides these commands:

whitelist add <platform_id> [displayname]
whitelist list
whitelist remove <platform_id>

A dummy EOS entry appeared in the test list; removing it emptied the list and turned whitelist-only mode off. The server help warns that any nonempty whitelist blocks players who are not listed. If you enable it on a live world, add every intended player first, check whitelist list, and keep an admin account available before relying on the restriction.

As with bans and admins, the help accepts a player name or entity ID for an online target and a platform ID for an offline one. The optional display name is a label to help recognize the account; it is not a login credential.

A whitelist is a gate for who may join, not merely a note that a player is approved. Before you add the first entry, make sure the intended members have identifiers ready and an administrator can still reach the server. After each change, run whitelist list; when the list is empty, the checked server reported whitelist-only mode as disabled. If you are setting up a private community for the first time, see our V3 server settings reference for the broader access and visibility controls.

Send an announcement and record the action#

Use say to send a message to connected players:

say "Server restart in five minutes. Please log out somewhere safe."

The V3.3 server help describes say as sending a message to all connected clients, and the isolated test accepted the command. No players were connected during that check, so it did not verify message delivery to a player. For a live maintenance notice, include the event and the time, then allow the group the notice you promised.

Keep a short incident record with the account ID, action, duration, reason, and time. That makes a later unban or permissions review easier, especially when multiple moderators share access. The panel’s Players tab can run the listed player actions directly; for the full command catalog, see our console commands for admins.

Review the action before you close the incident#

Use a consistent sequence: identify the exact account, choose the narrowest action that fits the situation, run the command, and confirm the resulting list or message before telling the group it is done. For a timed ban, that means reading the expiration in ban list; for an admin change, check admin list; for a whitelist change, check whitelist list. For a kick, current help supplies the command form, but the effect depends on targeting a connected player.

If a command fails, read its response and check help <command> on the same server before retrying. Avoid repeating a ban, permission change or whitelist edit when the response is delayed; inspect the stored list first. This keeps a typo or a second click from turning into a confusing moderation record. Share the action and reason with the other moderators through your agreed incident notes, and tell the affected group what access changed when appropriate.