A public Valheim community lasts when four things are settled before the first stranger joins: how people get in (an allow list fed by Discord beats an open server with a password), who runs it (two to four admins with clear powers and separate logins), what the server runs (vanilla or vanilla-plus with server-side mods, so crossplay players are not shut out), and what happens over months (scheduled restarts, off-machine backups, events, and a plan for the day the world runs dry). The hard limit shapes all of it: ten players online at once. A healthy community of forty members fits comfortably inside that cap, because people play at different times - but only if you plan for it.
This playbook covers the order to set things up in, the onboarding flow that keeps griefers out without scaring newcomers off, the admin team, the technical routine, and the slow problems that kill community worlds after three or four months.
Decide what kind of server it is#
Before any setting, decide three things and write them down where players can read them. Almost every later argument on a community server is really an argument about one of these.
| Decision | Options | Consequence |
|---|---|---|
| Access | Open, password, allow list | How much griefing you will clean up |
| Mods | Vanilla, server-side only, client mods | Whether Xbox players can join |
| Pace | Free progression, announced bosses, events only | How late joiners experience the world |
Access. An open server with no password will attract griefers within days of appearing in the community list. A password shared in Discord keeps out drive-by visitors but leaks quickly; once it is in a screenshot it is public. An allow list - permittedlist.txt with every member's ID - is the only setup where you decide who gets in, one person at a time. For a public community it is the right default.
Mods. Xbox players cannot install mods. A server that needs client mods is a PC-only server whatever the -crossplay flag says. If you want console players, stay vanilla or limit yourself to mods that only run on the server. If the community is PC-only, mods open up a lot, but every game patch now means a wait for mod updates, and every newcomer has to install the exact mod set. Valheim mods with BepInEx on a server covers the install; Valheim crossplay and Xbox players covers what crossplay changes.
Pace. On a shared world one player's boss kill changes the game for everyone. Decide whether bosses are free for all, announced, or event-only, and whether raids follow the world's progress or each player's (-setkey playerevents).
Size the server for your peak, not your member count#
The ten-player cap is per server, at the same time. What matters for sizing is how many are online together and how much of the world has been built and explored, not how many are in your Discord.
| Peak online | World state | RAM | Notes |
|---|---|---|---|
| 3-5 | New world | 2-3 GB | Fine for the first weeks |
| 6-8 | Several bases, explored | 3-4 GB | The common community case |
| 9-10 | Mature world, many bases | 4-6 GB | Memory grows with the world |
| 10, modded | Content mods | 6-8 GB | Depends entirely on the mods |
CPU matters as much as memory: the simulation leans on one thread, so clock speed counts. Disk is rarely the limit; a long-lived world is one .db file of tens to low hundreds of megabytes plus its backups. How much RAM does a Valheim server need has the detail.
When ten is not enough, the realistic options are a second world on its own server, or a mod that raises the cap with all the costs that brings - enemy scaling and network load were not designed for it. Valheim player limit and larger groups goes through both. For most communities the honest answer is that a full server at peak time is a sign of health, and a polite "Server is full" at 9 pm on a Saturday is acceptable.
The onboarding flow#
The goal is a path from "I found your Discord" to "I am in the world" that takes a newcomer ten minutes and gives you a record of who they are. A flow that works:
- Join Discord. New members see only the rules and an application channel.
- Accept the rules. A reaction or a short form. Ask for their in-game name, their platform (Steam, Xbox, Game Pass PC), and which time zone they play in.
- First connection attempt. They try to join. With an allow list in place they are refused, but the attempt is in the server log with their ID in the exact form the server wants.
- Admin adds the ID to
permittedlist.txt. The server re-reads the file while running, so no restart. - Welcome. They get the member role, the portal hub location, the starter rules on bases and a contact for help.
Step 3 is the trick that saves the most time. Players rarely know their SteamID64 and almost never know their platform-prefixed crossplay ID. The log does.
// Steam-only server: SteamID6476561198012345678// Crossplay server: platform-prefixed IDsSteam_76561198012345678Xbox_2535412345678901// added 2026-10-11 by Ingrid, application #42Steam_76561198011112222The format of each file and the usual mistakes - wrong ID form on crossplay, a stray space, editing the copy in the wrong folder - are in Valheim adminlist, bannedlist and permittedlist.
Keep a password as well as the allow list. It costs nothing and stops the server being probed by everyone browsing the community list. The password must be at least five characters and must not share a word with the server name or world name, or the server will refuse to start.
Building the admin team#
One admin is a single point of failure: holidays, burnout and time zones guarantee there will be weeks with nobody to deal with a problem. Two to four is the useful range for a ten-slot server. More than that and decisions become committees.
Give each admin role clear powers rather than "admin" in general:
| Role | Can do | Needs |
|---|---|---|
| Owner | Billing, backups, restores, mod updates | Full server access |
| Server admin | Kick, ban, allow list, restarts | Console and file access |
| Moderator | Discord moderation, reports | In-game admin list only |
| Event host | Running events | Mod-granted commands if used |
In-game admin rights come from adminlist.txt, and vanilla admins get only the short command list: kick, ban, unban, banned, save, ping and a few more. Cheat commands such as spawn, goto and event are refused on a vanilla dedicated server even for listed admins; giving them out needs a mod such as Server Devcommands (check its documentation for how to limit commands per admin in the version you install). Treat those commands as a privilege for repairs, used on a separate admin character. See the admin console commands reference and the Server Devcommands guide.
Outside the game, the people with access to the server's files and console need their own logins, not a shared password. On RE:NODE each admin can be a subuser of the server with only the permissions they need - console only, files only, or no billing - and the activity log records who restarted the server or edited a list file. When an admin steps down, you remove one subuser and nothing else changes.
Write down the rules for admins too, and put the most important one first: admins play by the same rules as everyone else. Valheim server rules has a full template, including admin conduct.
The technical routine#
A community server needs a routine that runs whether or not anybody remembers it. Four jobs, most of them schedulable:
Saves and restarts
The world is written to disk on a timer - every 30 minutes by default. A crash or a forced stop loses everything since the last save. On a busy community world, lower it:
-saveinterval 600 -backups 4 -backupshort 7200 -backuplong 43200Ten minutes between saves costs a short hitch on a large world and caps the loss at ten minutes. A daily or weekly scheduled restart keeps memory flat; warn players in Discord or in-game first, and always use a clean stop so the world saves on the way down. Valheim scheduled restarts and automation goes into timing and warnings.
Backups somewhere else
The built-in backups sit next to the world on the same disk. They protect against a corrupt save, not against a deleted server or a mistake with the file manager. A community world represents hundreds of hours of other people's time; back it up off the machine daily and before every update or mod change, and restore one occasionally to prove it works. On RE:NODE backup slots are included on every Valheim plan, can be scheduled on the Schedules tab, and can be locked so the one before a big change is not rotated away. Valheim server backups and world corruption covers what to keep.
Updates
Every Valheim patch forces an update before anyone can join. On a vanilla server, update the same day and announce it. On a modded server, wait until every mod has been updated, test on a copy, then update - and tell players which mod versions to install. Valheim update server and version mismatch covers the routine.
Monitoring
Know when the server is down before your members tell you. The query port answers Steam's server queries, which is enough for simple uptime and player-count checks, and a Discord bridge mod can post joins, leaves and deaths into a channel. See Valheim server monitoring and player counts and the Discord Connector mod guide.
Laying out the world for a community#
The first week sets the shape of the world for months. Three decisions are worth making before the first wave of members spreads out.
A public hub. A shared building near the spawn with the portal hub, a few public workbenches and a notice board of signs. It gives newcomers somewhere to start that is not someone's base, and keeps portal tags in one controlled place. Design it so it does not become a lag point - Valheim portal hub design has the layout advice.
Spaced bases. Three hundred metres between base centres is the minimum worth enforcing, because of how zone ownership works. Players who want neighbours can build a village with shared walls, but it should be a deliberate choice. Valheim base placement for shared servers explains why.
Shared infrastructure. Roads, a public dock and a public farm make a world feel lived in and give quieter players something useful to do. Keep the heavy pieces - smelter rows, kilns, animal pens - out of the hub.
Keeping a world alive for months#
Most community worlds do not die in a dramatic grief. They fade: the core players finish the content, the newcomers find a world with bosses dead and copper mined out, and the server goes quiet. Plan against each cause.
- Progression runs out. Spread the bosses out with announced boss nights rather than letting the most dedicated player clear the world in two weeks. The world's progress belongs to everyone.
- Late joiners struggle. A newcomer on a world where Moder is dead faces later raids at their base unless
playereventsis on, and finds the easy resources gone. A starter area left untouched near the hub, and a "starter kit" rule that lets veterans hand over basic gear, help a lot. Onboarding late joiners covers this. - Resources deplete. Copper, tin and silver deposits do not respawn, and crypts are cleared once. After a few months the nearby land is empty. Exploring further out helps for a while; eventually a fresh world is the honest answer. See long-running server resource depletion.
- Nothing happens. A world where nothing is scheduled is a world people forget. A build contest, a sailing race or a group boss fight once or twice a month brings people back. Valheim community event ideas has a list with the commands to run them.
- The world gets heavy. Terraforming, huge stone piles, dropped items and herds of tames all grow the world and slow it. Set clean-up rules early and deal with the worst offenders politely.
Seasons
Many communities eventually run in seasons: a world for four to six months, then a fresh one, with the old world archived and its location announced in advance. Decide early whether characters carry over or start fresh; fresh characters are fairer, carry-over keeps veterans happy. A new season also lands well at a major game update, because new biomes only generate in parts of the world nobody has visited. Valheim server wipes and seasons covers announcements and archiving.
FAQ#
Should a public Valheim server use an allow list or just a password?
An allow list, with a password as well. A password alone leaks within weeks and then anyone can join. With permittedlist.txt you add each member by ID and remove them just as easily, and the password stops casual browsers.
How many members can a community have with a ten-player cap?
Far more than ten. The cap is concurrent players, and members spread across the day and the week. Thirty to fifty active members on one server is common; if the server is full at peak most evenings, that is the point to consider a second world.
Can Xbox players join a modded community server?
Only if every mod runs on the server alone. Console players cannot install mods, so any mod that players must also have makes the server PC-only, regardless of the crossplay setting.
How do I find a new member's ID for the allow list?
Ask them to try joining once. The connection attempt is written to the server log with the ID in the form the server expects, including the platform prefix on a crossplay server. Copy it from there into permittedlist.txt.
How often should a community world be backed up?
At least daily to somewhere off the machine, and by hand before every game update, every mod change and every boss night. Keep several days of copies, because griefing or corruption is often noticed a day or two after it happens.
