---
title: "How to Add Admins and Whitelist Players in 7 Days to Die"
description: "Grant admin in serveradmin.xml with a Steam or EOS ID, whitelist players without locking yourself out, and run the F1 commands current 7DTD builds accept."
url: "https://www.gameserverkings.com/knowledge-base/7-days-to-die/how-to-add-admins-and-whitelist-players/"
category: "7 Days to Die"
category_url: "https://www.gameserverkings.com/knowledge-base/7-days-to-die/"
published: "2026-03-21T17:01:41.056Z"
updated: "2026-08-01T16:13:37.780Z"
source_format: "markdown"
site: "GameServerKings"
---

# How to Add Admins and Whitelist Players in 7 Days to Die

This guide covers granting admin access through `serveradmin.xml` and the most useful in-game commands.

## Admin Setup (serveradmin.xml)

Admins are defined in `serveradmin.xml`. The `AdminFileName` property in `serverconfig.xml` names that file, and its path is **relative to `SaveGameFolder`** — so it sits with your save data, not in the server root. If you cannot find it, check `AdminFileName` and `SaveGameFolder` in `serverconfig.xml` rather than hunting through the server root.

Entries are keyed on a platform and a user ID, so both Steam and Epic players can be made admins:

```xml title="serveradmin.xml"
<adminTools>
  <admins>
    <user platform="Steam" userid="76561197960287930" name="Your name here" permission_level="0"/>
  </admins>
  <permissions>
    <!-- command permissions can be customized here -->
  </permissions>
</adminTools>
```

Use your 17-digit SteamID64 for `platform="Steam"`, or your EOS ID with `platform="EOS"` if you play through the Epic Games Store.

Permission levels run 0 to 1000, and the scale is inverted from what most people expect:

- `0` = Full admin (everything)
- `1000` = Default level for anyone without an entry
- Numbers in between (e.g. 100) can be assigned per-command to build moderator tiers

> [!IMPORTANT] Restart the server after editing this file
> Alternatively, skip the file entirely: running `admin add <platform user id> 0` from the console writes a correctly formatted entry for you and takes effect immediately. That is the less error-prone route, and it is how you make yourself an admin before you have ever joined.

## Whitelisting Players

A whitelist restricts the server to an explicit list of players. It is off by default, and there is no separate "enable whitelist" switch — the list being non-empty *is* the switch.

> [!WARNING] One entry locks out everyone else
> Per the in-game help: if there is at least one entry on the whitelist, no user who is not on that list can join. Adding a single name to test the feature will remove every other player from your server on their next connect. Add everyone who should have access *before* you add the first entry.

### From the console

As with admin grants, letting the server write the entry is the less error-prone route:

```console
whitelist add SomePlayer
whitelist list
whitelist remove SomePlayer
```

`whitelist` takes the same kind of player identifier as `admin add` — a name, an entity ID, or a platform plus platform user ID. The name and entity-ID forms resolve against players the server can currently see, so use the platform user ID form for someone who has not joined yet. Run `help whitelist` to confirm the exact argument order on your build; the [console and admin command reference](/knowledge-base/7-days-to-die/7-days-to-die-console-commands/) covers the identifier forms in detail.

### Turning the whitelist back off

Because enforcement keys on the list being non-empty, the whitelist is only off once it is *completely* empty. Run `whitelist list` and remove every entry — clearing all but one still locks out everybody except that one player.

> [!TIP] For a small private server, a password is simpler
> If the goal is just "only my friends", `ServerPassword` in `serverconfig.xml` does the job with no per-player maintenance and no risk of locking yourself out. See the [serverconfig.xml Reference](/knowledge-base/7-days-to-die/serverconfig-xml/). A whitelist is the better tool when you want the server publicly listed but entry-controlled, or when you want to hand out access without handing out a shared secret.

## Common In-Game Admin Commands

Connect, then open the console with **F1**. Useful commands:

```text
cm                              Toggle Creative Menu mode
giveselfxp 10000                Grant yourself XP
se <playerId> <entity#> <count> Spawn an entity
teleport 1000 -1 1000           Teleport to coordinates, y = -1 drops you to ground level
kick "PlayerName" "Reason"      Kick a player
ban add "PlayerName" 7 days "Cheating"   Ban a player
```

> [!NOTE] `loglevel` is not an in-game command
> Older guides list `loglevel info` for log verbosity. That is not valid syntax and it does not work in the F1 console — `loglevel` is marked Telnet/Web only, and it takes a level plus a boolean: `loglevel WRN false`, with levels `INF`, `WRN`, `ERR`, `EXC` or `ALL`. By default every level is printed on a new connection.

Type `help` in the console for the list your build supports. [7 Days to Die Console and Admin Commands](/knowledge-base/7-days-to-die/7-days-to-die-console-commands/) is the full current reference, covering permission levels, the `cp` system, and the commands older guides still list that no longer exist.

## What to Read Next

- [serverconfig.xml Reference](/knowledge-base/7-days-to-die/serverconfig-xml/) for what still lives in that file and the V3.0 SandboxCode migration
- [How to Install Modlets and Overhaul Mods](/knowledge-base/7-days-to-die/how-to-install-modlets-and-overhaul-mods/) for adding new content

---

Made with 💜 by GameServerKings