Project Zomboid Private Server: Plan Access for Your Group
Plan a Project Zomboid private server around your invited group, owner, schedule, and access expectations before the first session.
You will need
- A list of intended players and their game storefront, platform, and build
- A named world owner and an estimate of when the group expects to play
A Project Zomboid private server works best when the group agrees on access before the first survivor logs in. Write down who is invited, who approves changes to the roster, and when the world needs to be available. Then check those decisions against the chosen hosting mode and current game build.
This is a planning guide for a new, small group. It does not walk through server setup or promise that a particular account will be blocked. Those details depend on the exact configuration and should be checked on the server the group will use. If you are choosing among providers, use the Project Zomboid hosting buyer checklist after your group has written down its requirements.
Who is in the group, and who approves additions?#
Start with a roster and one named owner. The roster can be as simple as player names and the account or storefront each person uses. Add one sentence about who can invite someone new. A group that agrees on this early is less likely to confuse “a friend has the password” with “the group approved another player.”
Record who makes the final call if the original organizer is unavailable. That person does not need every account credential; they need a clear path to ask the owner to approve a change. Keep the current roster somewhere the group can find it, and agree how updates will be announced. Avoid storing passwords or private account details in a shared roster.
Membership decisions are human decisions. Project Zomboid exposes separate server options related to public listing, openness, and passwords in its official ServerOptions API, but field names alone are not a complete access recipe. Do not assume one setting proves that only intended members can join. Later, test the exact setup with an invited player and a separate account that should not be admitted.
For a community that already has moderators or conduct rules, use the server rules playbook to decide what happens after a policy is broken. This page covers who belongs in a new private group; it is not a moderation procedure.
Will the world be available when the organizer is away?#
Agree on the hours people expect to play before choosing how the world will run. If everyone plays together while one person is present, an in-game hosted session may fit. If members often arrive at different times, ask whether a separate dedicated-server process better matches that schedule and who will keep the device or service available.
Do not turn “dedicated” into a promise that the world is always reachable. A process cannot serve players when its host machine or service is stopped, and settings can affect what happens when nobody is connected. The official API lists a pauseEmpty option, but its existence does not establish what your chosen server will do in every configuration. Check the mode and settings you actually plan to use.
Write a simple availability expectation, such as “we meet Saturday evening” or “the owner will announce maintenance before restarting.” Include the time zone if members live in different places. If players need to enter without waiting for the organizer to start a session, compare a dedicated option against that requirement. The Project Zomboid hosting page is one place to review managed hosting; its listing does not resolve build, mod, or access compatibility for your group.
What does “private” mean for discovery and admission?#
Separate two questions: do you want the server to be discoverable, and which players should be admitted? The game documents separate fields for public listing, openness, and password handling. Historical release notes also describe a distinction between an open server and public-list visibility, but old behavior is not a current Build 42 configuration guide. Confirm the behavior against the version and setup you intend to run.
Put the group’s intended policy in plain language before anyone edits a setting. For example: “We want invited members to find the server using the details we share, and we do not want unapproved accounts joining.” That statement is a goal, not proof that the chosen controls enforce it. If a server name or description will be publicly visible, decide whether it should identify the group or reveal personal information.
At acceptance time, use two separate checks. First, have one intended member follow the exact join path the group plans to use. Then check an account that should not be admitted, without exposing a real member’s credentials. Record the date, Build 42 branch, server mode, relevant policy, and observed result. If the result differs from the agreement, stop and resolve the configuration before sharing access more widely.
This is a reader-run check. We have not tested an allow or reject attempt on your server, and this guide does not identify a universal password, whitelist, or visibility recipe. A current how-to for a specific control should use the precise version and setup it was tested against.
Who owns the decisions after the first session?#
Name a primary owner and a backup contact for group decisions. Decide who updates the roster, communicates schedule changes, and approves a change to the game branch or mod list. Keep the agreement short enough that players will read it; one shared note is more useful than a policy document nobody opens.
The group can also agree on how to handle a temporary exception. A one-night guest, a returning player who lost the connection details, and an account that was never invited are different cases. Decide who can approve the first two and how the owner will confirm the last case. Do not give a broader account login to someone just because they need to pass along a join detail.
If the original organizer may leave, decide who inherits the world and what happens to access. A handoff is easier to discuss before the person is already offline. Write down where the owner keeps the current agreement, how the backup can reach them, and which decisions must wait for owner approval. If the owner changes, tell every invited player who now approves additions and where to find the updated roster. The rules playbook covers expectations and consequences for a group with moderators. If the question is how to divide hosting costs and administrative work, use a comparison checklist rather than treating those topics as an access rule.
What should the group verify before inviting everyone?#
Check compatibility and access in a small first session. Ask each player to report their storefront, operating system, game version or branch, and any mods the group expects to use. Steam currently lists Windows, macOS, and SteamOS/Linux client requirements on its Project Zomboid store page; that listing does not establish every storefront combination or guarantee cross-play. Confirm the requirements for each member’s actual copy.
The current official release announcement identifies Build 42.21 as Stable. Agree on a build and branch before starting a shared world, and check the official release notes again when planning an update. Do not assume that a save can move between incompatible versions or branches. If someone’s client does not match, resolve that before calling the server broken.
Use this short record for the first session:
- Invited player and account/storefront checked
- Server build, branch, and mode written down
- Intended member’s join path and result
- Separate non-member check and result
- Any mismatch or unresolved setting assigned to the owner
The list is not a substitute for a tested recovery plan. It only records whether the group’s access agreement matches the behavior it observed. If the setup changes later, repeat the checks that the change could affect.
When does a dedicated host fit the plan?#
A dedicated host can fit when the group expects access beyond the organizer’s own hosted session and wants a separately running server process. It is not necessary for every friend group: if members can coordinate around one person hosting, start by testing that arrangement and write down the schedule it supports.
Before renting, compare the group’s actual requirements: chosen branch, client compatibility, required mods, access controls, expected play hours, and who owns the world. Ask the provider about any control the group considers essential, and verify it in the actual plan instead of inferring it from a generic panel label. The buyer checklist covers how to compare current plans, documented controls, and recovery terms. Hosting can separate the game process from one player’s PC; it cannot make incompatible clients or saves compatible.
A useful agreement is short: named owner, invited roster, how additions are approved, when the world should be available, and what the group will check before sharing access. Once everyone agrees on those points, choose the hosting mode that meets them and record what remains unverified.
Quick answers
Does a private server have to disappear from the browser?
Not necessarily as a planning concept: discovery and admission are separate choices. Confirm what the chosen Build 42 setup actually does before relying on a visibility or access setting.
Can friends play after the organizer closes the game?
That depends on the hosting mode and whether its process and device remain available. Decide when the group needs access, then verify the chosen setup rather than assuming an empty world keeps running.
What should a group agree on before renting a server?
Name the world owner, define who can join, agree on the build and client requirements, and decide when the world needs to be available. Then compare providers against those requirements.