Giving the right people admin rights is one of the first things you do after spinning up a 7 Days to Die dedicated server. Whether you want to kick a griefer, ban a cheater, spawn in supplies for an event, or just teleport yourself out of a stuck spot, none of it works until your account is registered as an administrator. The good news: 7 Days to Die has a clean, flexible permission system that lets you do exactly that, either by editing a single XML file or by typing one console command. The catch is that the syntax changed with the 1.0 release in July 2024, and a lot of older guides still show the deprecated format. This guide covers the modern way to do it on the current 1.0-and-beyond (2.x series, 2026) builds, explains the permission-level scheme in full, and walks through every method so you can pick the one that fits your workflow.
The two files that control admin access
7 Days to Die keeps its server configuration spread across two main files, and it helps to know which one does what before you start editing. The first is serverconfig.xml, which holds the world settings, ports, difficulty, blood moon frequency, and anti-cheat toggle. The second, and the one this guide is built around, is serveradmin.xml. That file is the single source of truth for who is an admin, who is whitelisted, who is banned, and what permission level each individual command requires. If you are configuring admins, serveradmin.xml is where you live.
Every setting inside these files follows the same XML pattern. In serverconfig.xml each option looks like serveradmin.xml uses dedicated element types like
Understanding the 0-1000 permission scheme
This is the part that trips up most newcomers, so it’s worth getting straight before you touch a single line. 7 Days to Die uses a numeric permission scale that runs from 0 to 1000, and it is inverted relative to what your instinct might tell you:
- 0 is the highest authority — a full super-admin with complete control over the server.
- 1000 is the default for an ordinary player who has not been registered at all — the lowest authority.
The rule that ties it all together is simple: a player can run any command whose required level is equal to or greater than (numerically) the player’s own level. In plain English, lower-numbered players can do more. A level-0 user can run everything, a level-1000 user can run only commands that are open to everyone, and anything in between gives you a tiered moderator structure. This means you don’t have to make every trusted person a god. You might keep yourself at 0, set co-owners at 0 or 1, give moderators something like 100, and leave regular players at the default 1000.
| Permission level | Typical role | What they can do |
|---|---|---|
| 0 | Owner / super-admin | Every command, no restrictions |
| 1 | Co-owner / head admin | Effectively everything except level-0-only commands |
| 100 | Moderator | Kick, ban, teleport, kill players (commands set to 100 or higher) |
| 1000 | Default player | Only commands explicitly opened to everyone |
The actual breakpoints (100 for moderators, and so on) are entirely your choice — they’re just numbers. The only fixed facts are that 0 is the top and 1000 is the baseline player default. Everything else is a convention you design for your community.
Method 1: Add an admin by editing serveradmin.xml
This is the canonical method and the one to use when you’re setting up admins before launch or doing bulk changes. Stop your server first (or be ready to restart it) so your edits load cleanly, then open serveradmin.xml. Inside you’ll find an
The modern 1.0+ crossplay syntax
Since 7 Days to Die left Early Access at 1.0 on July 25, 2024 and added crossplay between PC, PS5, and Xbox Series in the 1.2 update, the user element is now platform-prefixed. This lets the server identify accounts coming from Steam, Epic/EOS, and console networks rather than assuming everyone is on Steam. On any 1.0-and-beyond server, use this form:
- platform — the account network, e.g.
Steam(Epic/EOS users use their platform identifier instead). - userid — the player’s unique ID. For Steam this is the 17-digit SteamID64 beginning with
76561198. - name — a free-text hint so you remember who the entry belongs to; it has no functional effect.
- permission_level — the 0-1000 value from the scheme above. Use
0for a full admin.
The older Steam-only syntax (still seen in old guides)
Before crossplay, the user element used a steamID attribute directly:
You’ll find this format all over older tutorials. If you’re running a current 1.0+ build, prefer the platform/userid form so your config is consistent with the crossplay-era expectations and works regardless of which network a player joins from.
Save the file and restart the server. When the player connects, the server matches their account ID to your entry and grants the level you assigned. Spelling the ID wrong is the single most common failure here, so double-check it before you blame the server.
Method 2: Add an admin from the console
If your server is already running and you want to promote someone on the fly, the in-game/web console is faster than editing files. Open the console (the telnet/web panel or, if you’re playing on the same machine, the in-game console) and run:
admin add A concrete example that makes a player a full super-admin:
admin add 76561198XXXXXXXXX 0The command accepts a player name, an entity ID, or a SteamID. The level argument is the same 0-1000 value — use 0 for full control. The benefit of the console route is that it writes the entry into serveradmin.xml for you and applies immediately, no restart required. The related management commands you’ll use alongside it:
| Command | What it does |
|---|---|
admin add | Register a player as admin at the given permission level |
admin remove | Remove a player’s admin entry |
kick | Disconnect a player, with an optional reason |
ban add | Ban a player; units are minutes/hours/days/weeks/months/years |
So ban add 76561198XXXXXXXXX 3 days griefing bans that account for three days with a reason logged. Because the console writes through to the XML, the two methods are fully interchangeable — pick whichever is convenient at the moment.
Fine-grained control: per-command permissions
Registering a user at a level is half the system. The other half is deciding what level each command requires, and that’s what the serveradmin.xml are for. Each one looks like this:
The cmd attribute is the command’s name and permission_level is the minimum authority needed to run it. Any command you don’t explicitly list keeps its built-in default level. This is where the tiered-moderator idea becomes real. Say you want moderators (level 100) to be able to kick and ban but not shutdown the server. You’d set the kick and ban commands to require level 100 (or higher numerically, meaning anyone at 100 or stronger can use them) while leaving shutdown restricted to 0. Combine thoughtfully assigned user levels with command levels and you can build any moderation hierarchy your community needs, from a flat “everyone’s an admin” private game to a layered public server with owners, head admins, and junior mods.
Finding a player’s SteamID64
Every method above needs the player’s unique ID, and for Steam users that’s the SteamID64 — the 17-digit number that begins with 76561198. There are a few reliable ways to get it:
- Paste the player’s Steam profile URL into a calculator site such as steamid.io or the steamdb.info lookup, which converts a profile link or vanity name into the SteamID64.
- If the player is currently connected, run a
listplayerscommand in the console — it prints connected players alongside their IDs, which you can copy straight intoadmin add. - Check your server logs, which record the joining ID for each connection.
Console and Epic players won’t have a SteamID64 — they have their own platform identifiers, which is exactly why the crossplay-era platform/userid attributes exist. Use the ID that matches the network the player connects from, and set the platform attribute accordingly.
PC vs Console Edition: what to watch for
The modern Console Edition for PS5 and Xbox Series X|S launched on July 25, 2024 on the same 1.0 base as PC, and it is completely distinct from the abandoned 2016 Telltale version on PS4/Xbox One (which receives no updates and is irrelevant here). Crossplay arrived for the modern console build with the 1.2 update in December 2024. Historically, the Console Edition has tracked a patch or two behind PC, which has since moved through 2.0 “Storm’s Brewing” up to the current 2.x line in 2026. For admin setup specifically this rarely matters — the permission scheme and file structure are shared — but if you run a crossplay server you’ll want the platform/userid syntax precisely because your admins may be joining from different networks. When in doubt about console-specific behavior, verify against your build’s patch level, since some PC 2.x content may not yet be present on console.
A quick note on EAC and modded servers
Admin setup itself doesn’t depend on anti-cheat, but if you plan to run mods you’ll bump into EasyAntiCheat. EAC is controlled in serverconfig.xml with false or players get kicked. Disabling EAC is a fully supported configuration with no ban risk to you as the owner — the only trade-off is reduced protection against cheaters, which is exactly when a solid set of admins and ban commands earns its keep. For the full walkthrough, see our guide on how to disable EasyAntiCheat on a 7 Days to Die server.
Setting up a server from scratch
If you don’t yet have a server to administer, you have two paths. Self-hosting means installing the free dedicated server tool through SteamCMD. The game client is app ID 251570, but the dedicated server is a separate, free tool with app ID 294420 that installs with an anonymous login — no second game license required:
steamcmd +force_install_dir /path/to/7dtd-server +login anonymous +app_update 294420 validate +quitThe download runs roughly 10-15 GB. Once installed, your serverconfig.xml defaults include the primary game port 26900 (it also uses 26901-26902 UDP), a default of 8 max players, blood moons every 7 days, and game difficulty 2. The alternative is letting a host handle the hardware, networking, and file management for you — our dedicated 7 Days to Die hosting plans give you a control panel where editing serveradmin.xml and restarting are a couple of clicks rather than a command-line session. Either way, once the server is live, the admin steps above are identical. For the official panel-by-panel reference, check the 7 Days to Die documentation.
Frequently asked questions
Does 0 or 1000 give the most power?
0 is the most powerful. The 7 Days to Die permission scheme is inverted: 0 is a full super-admin with access to every command, and 1000 is the default level of an ordinary unregistered player. A player can run any command whose required level is numerically equal to or higher than their own, so lower-numbered users can do more. Set your trusted owners to 0 and your moderators to something in between, like 100.
Should I use the steamID or the platform/userid syntax?
On any 1.0-and-beyond server, use the crossplay form
Do I have to restart the server after adding an admin?
It depends on the method. If you edit serveradmin.xml by hand, restart the server (or have it reload) so the change is read. If you use the console command admin add , it applies immediately and also writes the entry into the XML for you — no restart needed.
How do I find a player’s SteamID64?
It’s the 17-digit number starting with 76561198. Paste the player’s Steam profile URL into a calculator like steamid.io or steamdb.info, run listplayers in the console while they’re connected, or read it from your server connection logs. Console and Epic players use their own platform IDs instead, which is why the platform attribute exists.
Can I give moderators some commands but not all?
Yes — that’s exactly what the serveradmin.xml are for. Register your moderators at a middle level such as 100, then set the commands you want them to use (like kick and ban) to that level while keeping sensitive commands like shutdown at 0. Commands you don’t list keep their built-in default.
Does the modern Console Edition support admins the same way?
The modern Console Edition (PS5/Xbox Series, launched July 2024 on the 1.0 base) shares the same permission scheme and file-based approach, and it gained crossplay in the 1.2 update. Console has historically lagged PC by a patch or two as PC moved into the 2.x series, so verify console-specific behavior against your current build. For crossplay servers, the platform/userid syntax is essential because your admins may connect from different networks.
Keep building out your server
With admins in place you can run a tighter, more enjoyable server. If you’re tuning the experience further, our companion guides cover the survival side: prepare for horde night with the Blood Moon horde strategy overview, plan where to base by reading the comprehensive guide to biomes, and learn what to expect from the roster in our guide to zombie types. Set your admins, lock down your permissions, and your 7 Days to Die server will be ready for whatever the Wasteland throws at it.
Ready to play?
Run your own 7 Days to Die server with XGamingServer
Spin up an always-on 7 Days to Die server your friends can join in minutes — no port-forwarding, no tech headaches.
