Project Zomboid Server Name: Set Public Text Safely

If you searched for a Project Zomboid server name, first separate the text players may see from the profile that selects server files. The current ServerOptions API lists publicName and publicDescription separately from isPublic; changing a display field does not make a private server public. This reference shows how to identify the active profile, make a reversible edit, and check the result from your own client. It does not promise a listing refresh time, a working invite, or that an untested host panel preserves a particular world.

Separate public text from the active server profile#

Project Zomboid exposes different options for a public name, a public description, and whether the server is public. The official ServerOptions API lists publicName as a string option, publicDescription as a text option, and isPublic as a boolean option. A current generated dedicated-server profile uses the INI keys PublicName and PublicDescription. Those names identify settings; they do not prove what every client will display or how quickly it will update.

The internal profile is a separate choice. The process startup argument and account or data root determine which server profile file is active; changing that identity can point the server at different files. This page does not provide a rename or save-migration procedure. If you need to locate the file that the running process actually reads, follow the active INI and profile checks first. Then return here and limit the change to public text.

The API uses camelCase identifiers while the generated INI uses title-cased keys. Match the spelling already present in your active file or current settings interface. Do not add duplicate lines under a different capitalization just because a panel labels the option differently.

Choose a name players can recognize#

Use a short name that lets your group distinguish this server from saved entries and similarly named communities. Put the group or campaign identifier first, followed by a location or play style only when that detail is accurate. For example, a private group could choose a pattern like Thursday Knox County rather than including a password or a friend’s personal information. The example is editorial guidance, not a tested in-game formatting rule.

Before saving, compare the proposed text with your group’s existing invitations and notes. If players already use a saved entry, tell them the intended new wording through a private channel after you confirm it appears correctly. Don’t add “open,” “join now,” a player count, a region, or a mod list unless those statements are true and remain current. This field is not a substitute for an access policy; public visibility, passwords, whitelist rules, and admission decisions belong in their own settings and procedures. When you need to replace the shared join secret, follow the server-password rotation checklist; it keeps that task separate from public-name changes.

There is no verified universal character limit or punctuation rule in the official API reference used here. Keep the text plain and concise, then check what the current client accepts. If the interface truncates it, shorten the phrase and repeat the check rather than guessing a limit or relying on formatting that may not render for other players.

Write a description without exposing private details#

Describe only information a prospective player needs to identify the server: its theme, intended audience, expected play style, and where to find current rules. Keep it factual and brief. A private server does not need a public-facing description at all; if you use one, don’t turn it into an access workaround or disclose details your group expects to stay private.

Never put a server password, administrator password, recovery code, personal address, private IP, or account name in the description. The same goes for a “temporary” credential that you plan to change later. If players need an access code, share it through a private channel and configure the server’s actual access control separately. PublicDescription is not the join-time welcome message; use a dedicated welcome-message setting for text shown after a player connects.

Avoid claims that could go stale: exact uptime, guaranteed events, promised moderation coverage, current mod versions, or open slots. If you mention a schedule or rules page, assign someone to keep it current. A stale description can send players to the wrong expectation even when the server itself is working normally.

Back up the active settings before editing#

Use the profile you already confirmed, not the first file named servertest.ini that a search returns. Stop the server through its normal control, copy the active configuration to a dated backup, and keep the original values somewhere private. If a provider panel manages the same options, check whether it is the source of truth before editing files directly; panel behavior varies and no universal control path is asserted here.

Capture enough context to reverse your own edit: the active profile name, the file or panel you changed, the old name and description, and the time of the change. Avoid pasting the complete INI into a public ticket or message because it may contain credentials. If you cannot determine which profile the running server uses, stop before editing and trace the process, account, launch settings, and data root first.

This is a reversible text change only when you know which source is active and have retained the old values. It is not a backup of the world. If the world itself matters, make a separate consistent server backup using the procedure for your installation; never assume copying these two lines protects player or map data.

Change only the two display fields#

After identifying the active configuration source, change only the name and description fields. Leave the profile filename, startup -servername, visibility, password, whitelist, mods, and world settings untouched. The example below shows the key names and neutral sample values; use the lines and values already present in your own current configuration.

PublicName=Thursday Knox County
PublicDescription=Private group; rules shared with invited players.

If one of the keys is absent, do not invent a second line in a panel or file without checking the current interface or game documentation for that installation. If the settings tool rewrites the INI, use that tool consistently and read the saved values back afterward. Keep special characters simple unless your current interface demonstrates that they are accepted and displayed as intended.

Use the normal save and restart process for the active server. This guide does not claim that all providers use the same restart button, that a particular panel exposes these fields, or that changing the values causes an immediate client refresh. If the saved file reverts, stop and compare the panel’s stored setting with the active file rather than repeatedly editing different copies.

Verify the configured text and the client listing#

First read the saved values from the active profile or settings screen. Confirm that the exact name and description you intended are present and that the internal profile and visibility settings still match your record. A saved line proves only what is in that configuration source; it does not prove that the server started with that file or that another player can see it.

Then use a current client on the same supported game build to check the listing you expect your group to use. Search for the configured name, open its details, and compare the displayed description with your saved text. If the entry is not visible or still shows old wording, don’t assume a specific refresh delay. Confirm whether the server is meant to appear in that listing, check the active profile and restart status, and consult the current in-game or provider support path for that environment.

Before sending invitations, have a group member use the exact route and instructions you intend to share. This reader-side check can catch a typo or the wrong server entry; it is not a guarantee that an invite feature exists or that a public listing is available for every private setup. Keep admission policy separate from discoverability and do not switch a server to public merely to make a name appear.

Confirm the intended world before announcing the change#

Reconnect only after checking that the server has started on the expected build and the intended profile. Confirm the expected world and character from the client before telling players that the change is complete. The official 42.21 release announcement says Build 42.21 moved to Stable on September 28, 2026; check your own client and server build before troubleshooting a mismatch. This name guide does not establish compatibility between different builds or branches, and it does not promise conversion of saves.

If the expected listing or world is not there, stop and preserve the current files. Restore the previous two text values using the same configuration source, then verify the profile and build before trying again. Do not rename the internal profile, move a save folder, or switch branches as a shortcut. A display-text edit should remain a small, reversible administration task; a world or version change is a separate operation that needs its own backup and compatibility checks.

For a group that would rather handle server rules and backups in one place, Game Hosting’s Project Zomboid plans include an integrated panel and three free backup slots. Check the plan details and your access needs before moving a world; this page does not claim that the panel has a specific public-name control or that it migrates a save for you.

FAQ: Project Zomboid server name changes#

Does renaming my Project Zomboid server rename its save folder?

This procedure changes public text and leaves the internal profile selection alone. It does not test a save-folder rename or prove that an arbitrary host workflow preserves a world; verify your active world before inviting players.

Why is the old description still displayed?

Check that the active profile contains the saved text and that the server restarted through its normal process. Then verify with a current client; no universal refresh delay is established here.

Should I put a password in my Project Zomboid server description?

No. Keep passwords and administrative details private, and configure admission rules separately from the text players use to recognize the server.