A Valheim server for a group of friends is secured by four things: -public 0 so it is not advertised, a password that shares no word with the server name, an allow list in permittedlist.txt so only named players get in, and as few admins as possible. That covers almost every real problem a small server has, which is strangers, griefers and a password that leaked into the wrong Discord. The rest - your IP address, mods that run code, the panel account that controls the server, and floods - matters more the bigger and more public the server gets. Valheim's own tools are simple, and the advice here is mostly about using all of them together rather than relying on one.
What you are actually protecting against#
It helps to be honest about the threats, because the realistic ones are smaller and more mundane than the ones people worry about.
| Threat | How likely for a friends server | What stops it |
|---|---|---|
| A stranger finds and joins the world | Moderate if listed | Password, allow list, -public 0 |
| A password shared too widely | High over time | Allow list, rotating the password |
| A player griefs or steals | Low to moderate | Wards, ban list, backups |
| An admin abuses their rights | Low | Fewer admins, backups |
| A mod contains malicious code | Low, but serious | Trusted sources only |
| Someone takes over the hosting account | Low, but total | 2FA, separate logins |
| A flood takes the server offline | Low unless public or a grudge | The host's network, not your config |
The world itself is a single file. Most of what follows is about who can get into it, and the last line of defence for everything is a backup that is stored somewhere else and actually restores.
Public or private: -public and the community list#
-public 1 lists the server in the in-game community browser; -public 0 hides it. Hiding it is the first step for any private group: a listed server is seen by everybody who browses, and a short or obvious password will eventually be guessed.
What -public 0 does and does not do:
- It does keep the server out of the community list, so casual browsers never see it.
- It does not stop anyone who knows the address from joining by IP. A hidden server is not a closed one.
- It does not stop the server answering Steam queries on the query port. Tools that scan addresses can still discover it.
- On a crossplay server, players with the current join code can still reach it. The code changes on every restart, which helps, but anyone in your group chat has it.
So treat -public 0 as reducing noise, not as access control. The password and the allow list are the access control. Valheim's launch arguments lists the related flags with their defaults.
Password hygiene#
Valheim's server password has two rules, both enforced at start-up: it must be at least five characters, and it must not contain the server name (and should not share words with the world name either). A server that breaks either rule does not start, and the reason is easy to miss in the log. The password rules covers the edge cases.
Beyond the rules:
- Make it long and unrelated. Three random words with a number is easy to type on a controller and hard to guess. Do not reuse a password from anything else; it is shared with every player and is not treated as a secret by anyone.
- Share it in one place. A pinned message in a private Discord channel, not in a public one and not in the server name or description.
- Rotate it when people leave. The password is a group secret. When someone leaves on bad terms, or the password turns up somewhere it should not, change it and tell the remaining players.
- Do not rely on it alone. Passwords spread. A friend shares it with a friend, who shares it with a stream. An allow list does not have that problem.
Changing the password means changing the launch argument and restarting. On a panel host that is the password field on the Startup tab; on your own machine it is the start script. Players are prompted for the new one on their next join.
# Before-name "Longship Crew" -world "Midgard" -password "herring-barrel-42" -public 0# After a leak: new password, restart the server-name "Longship Crew" -world "Midgard" -password "salted-cod-1187" -public 0The allow list, ban list and admin list#
Valheim has three plain text files in the save directory: adminlist.txt, bannedlist.txt and permittedlist.txt. Each holds player IDs, one per line. The server re-reads them while running, so most changes do not need a restart.
`permittedlist.txt` is the strongest tool you have. If it contains any ID at all, only those players can join; everybody else is refused even with the correct password. For a friends server, this is the setting that makes a leaked password harmless.
// Steam-only server: SteamID647656119801234567876561198087654321// Crossplay server: platform-prefixed IDsSteam_76561198012345678Xbox_2535412345678901Points that catch people:
- ID format depends on crossplay. A Steam-only server uses the plain 17-digit SteamID64. A crossplay server uses platform-prefixed IDs. A list written for one does not work for the other.
- Get IDs from the log. Have each player join once (before you turn the allow list on) and copy their ID from the server log, where it appears in exactly the form the server expects.
- New players need adding first. With the allow list on, an invited friend gets refused until you add them. That is the point, but tell them, or they will assume the server is broken.
bannedlist.txt is for removing a specific person. An admin can ban a player in-game, which adds them to the file; banning by ID is more reliable than by name. With an allow list in place, the ban list matters less, because unlisted players cannot join anyway - but it is still how you remove someone who is on the list.
adminlist.txt grants admin rights: kicking, banning, forcing saves. Keep it to one or two people. Admin on a vanilla server cannot spawn items or fly, but a mod such as ServerDevcommands extends what admins can do, and then admin becomes a much bigger grant. The three list files covers every detail of the format.
Your IP address and what it exposes#
Every player who connects directly to a server learns its IP address. For a rented server, that is the host's address and tells nobody anything personal. For a server hosted at home, in-game or dedicated, it is your household's address.
What an IP address reveals is mostly an approximate location, often only city or region level, and an ISP. It does not give anyone access to your devices. The realistic risk is not hacking but disruption: someone with a grudge and your home address can flood it and take your whole household's internet offline. Your router cannot stop that and your ISP may not either.
If you host at home:
- Keep the server private and allow-listed, so only people you know learn the address.
- Do not post the address publicly. Players can join by a domain name if you want something easier to type - connecting a domain to a game server covers it, though a name does not hide the address behind it.
- Consider crossplay join codes for players you do not know well. Their traffic goes through a relay rather than straight to you, but treat that as a convenience, not a guarantee of privacy.
Running anything public from home is the point at which renting a server becomes a privacy decision as much as a performance one. IP leaks and doxxing for server owners and home hosting vs a rented Valheim server go further.
DDoS realities for small servers#
A small Valheim server is rarely attacked. Floods cost the attacker something, and nobody pays to knock over a ten-player world unless they have a reason. The reasons in practice are personal: a banned player, a falling-out, a rival community. That is why private and allow-listed servers are attacked so rarely, and public ones with a large community more often.
What helps, in order of value:
- Not hosting a public server at home. A flood against a home connection takes down everything in the house.
- Being hard to find.
-public 0, no address in public channels, a small group. - A host that filters at the network edge. No configuration of the game server itself can absorb a flood; it has to be dropped before it arrives.
- Restarts that recover cleanly. After an attack ends, the server should come back on its own with the world intact.
Be wary of absolute promises. A host that says no attack will ever take you offline is overstating what anyone can do. On RE:NODE the wording is exact: upstream filtering that drops obvious volumetric floods, plus reflection and malformed traffic. Attacks that look like real players are not filtered. DDoS attacks on game servers explained and what we do about attacks cover the detail.
Mods are code: treat them that way#
BepInEx mods are .dll files that run with the same rights as the server process. A malicious one can read files, open connections and do anything the server user can. On a home machine, that is your machine. On a rented container, it is limited to that server, but it can still damage the world or leak whatever is in its files.
Sensible habits:
- Install from Thunderstore or the author's own page. Avoid re-uploads in random Discord channels and "fixed" versions from people you do not know.
- Prefer well-known mods with active authors. Popularity is not proof of safety, but a mod used by thousands with a public source repository is a different risk from one with no history.
- Do not run the server as an administrator or root on your own machine. A dedicated user with access only to the server folder limits the damage.
- Back up before adding anything. If a mod corrupts the world, the backup is the fix.
Malicious plugins and mods goes through what bad mods tend to do and how to spot them.
The account that controls the server#
On a rented server, whoever logs into the hosting panel can stop the server, download the world, change the password and delete everything. That login matters more than any in-game setting.
- Turn on two-factor authentication. An authenticator app on the panel account stops a reused password from being enough. Keep the recovery codes somewhere safe. Two-factor on your panel account explains the setup.
- Give co-admins their own access. Do not share your login. On RE:NODE, subusers can be given only what they need - console only, or files only, with no billing - and access can be time-boxed and is recorded in a per-server activity log. Subusers and least privilege covers the pattern.
- Keep backups off the machine. RE:NODE backups are stored off the machine they protect and can be locked against rotation, so a bad day does not overwrite the last good copy. Note that deleting a server deletes its backups, locked ones included, so download one before you delete anything.
Griefing inside the world is a separate problem from all of this. Wards stop a lot of it on PvE servers and backups fix the rest; wards and griefing covers what wards do and do not prevent.
FAQ#
Is a Valheim server with -public 0 private?
It is hidden, not private. It no longer appears in the community list, but anyone with the address can still try to join by IP. Combine it with a password and an allow list in permittedlist.txt for a server that is actually closed.
Does the allow list replace the password?
No, both apply. A player must be on the allow list and know the password. Keep the password anyway - it still protects the server on the day somebody empties the allow list by mistake - but the allow list is what makes a leaked password harmless.
Can players see my IP address if I host Valheim at home?
Anyone connecting directly can, yes. It reveals roughly where you are and which ISP you use, not access to your devices. The real risk is someone flooding your home connection, so keep a home server private and allow-listed.
Should I worry about DDoS attacks on a small Valheim server?
Usually not. Small private servers are rarely targeted, and when they are, it is almost always somebody with a personal grudge. Keeping the server private, not hosting a public one from home, and choosing a host that filters floods upstream covers the realistic cases.
How do I remove a player who knows the password?
Ban them by ID with ban or by adding their ID to bannedlist.txt, remove them from permittedlist.txt if you use it, and change the password if they might share it. The list files are re-read while the server runs.
