Project Zomboid Server Discord Integration: What You Can Verify
Project Zomboid server Discord integration: see documented fields, bot access limits, and a safe checklist for testing channels and credentials.
You will need
- Access to the server build and configuration you intend to use
- A private, owner-controlled Discord test server if you choose to test a relay
- Permission to review the integration's current documentation and channel access
The current official Project Zomboid server-options reference lists Discord-related fields, but it does not prove that a particular message flow works on your build. This guide separates documented names from runtime behavior, shows what to check before granting a bot access, and gives you a reader-run acceptance checklist for testing messages and credentials safely.
Decide what a Project Zomboid server Discord integration must do#
Write down the one job you need before choosing a bot or changing server settings. “Discord integration” can mean a server message appears in Discord, a Discord message appears in game, an admin command is available, or a log is copied to a channel. Those are different flows with different access and failure cases.
The official Project Zomboid ServerOptions API currently lists these Discord-related properties:
| Property in the API | Type shown by the API | What the name suggests, not a verified behavior |
|---|---|---|
discordEnable |
Boolean | A switch related to Discord functionality |
discordToken |
String | A credential value associated with a bot |
discordChatChannel |
String | A channel associated with chat |
discordLogChannel |
String | A channel associated with logs |
discordCommandChannel |
String | A channel associated with commands |
That reference establishes that the names exist in the documented server-options schema. It does not specify defaults, exact values, supported message directions, permission requirements, or whether each field behaves the same way on every build. Treat field names as a map of what to investigate, not as a complete setup recipe.
Before proceeding, define the source, destination, and purpose for each message you want to move. If you only need outage notices, a chat relay may be the wrong tool; if you need in-game visibility, a Discord bot alone may not provide it. Keep moderation policy separate from transport: decide who may post and how moderators respond. For community rules that can be applied consistently, see rules your moderators can enforce.
Map chat, log, and command channels before granting access#
Separate channels by purpose where the implementation allows it, then confirm the behavior in its current documentation. The option names above look distinct, but the API page does not explain whether they accept IDs, names, or another value. It also does not say whether an empty value disables a route. Do not paste a guessed channel name or ID into production and assume the result is private.
Make a small channel map before you invite or configure anything:
| Intended flow | Destination to plan | Questions to answer first |
|---|---|---|
| Public server chat copied outward | A channel visible to the intended community | Which in-game messages are copied, and can players opt out? |
| Operational logs | A staff-only channel | Could lines include player identifiers, IP addresses, or other private details? |
| Commands or command requests | A tightly restricted staff channel, if supported | Which commands are accepted, who can use them, and are results logged? |
This is a planning table, not a claim that the native integration implements all three flows. In particular, a setting named discordCommandChannel does not tell you which commands it accepts or whether it can affect the world. Confirm that in a current source for the exact integration you intend to run.
Use an owner-controlled test server and channels that contain no real player history. Check channel visibility from an ordinary member account, not only from the owner view. If you cannot tell which messages may leave the game or who can read them, pause before adding real players. A separate channel does not make content private when its permission overrides allow everyone to view it.
Review the bot and channel permissions you actually grant#
Give an integration only the channel access its documented job needs, and verify the effective permissions after Discord role and channel overrides are applied. Discord’s permissions reference describes permissions such as VIEW_CHANNEL, SEND_MESSAGES, and READ_MESSAGE_HISTORY; it does not define which combination Project Zomboid or a particular bridge requires.
| Permission to inspect | What Discord documents it permits | Check before enabling it |
|---|---|---|
VIEW_CHANNEL |
Seeing a channel and reading its text messages | Can the bot see only the intended channel? |
SEND_MESSAGES |
Sending messages in a text channel | Does the documented flow need to post here? |
READ_MESSAGE_HISTORY |
Reading earlier messages | Does the implementation actually need history, or only new events? |
Do not treat this list as a guaranteed minimum for the game’s native option or for a third-party bridge. The integration may use a different mechanism or need additional access; the available official PZ schema does not answer that question. Use the implementation’s maintained permission guidance, then compare it against the exact permissions shown on the bot role and each channel. If it requests administrator access, ask what operation requires it and whether a narrower channel-specific grant works.
Discord also documents privileged Gateway intents, including Message Content access, in its Gateway reference. Whether a particular Project Zomboid feature or bridge needs that intent is not established by the PZ API fields. Do not enable privileged access merely because an old tutorial says to. Match each requested permission or intent to a current implementation document and a test you can repeat.
If the granted permissions are broader than the documented task, remove the extra access before inviting players. If the channel boundary cannot be checked from a non-owner account, the test is incomplete.
Keep the Discord token out of screenshots and public support#
Treat a bot token like a password: anyone who obtains it may be able to act as that bot within its granted permissions. Do not post it in a support ticket, public issue, screenshot, stream, shared spreadsheet, or chat message. Avoid copying an entire configuration file into a public forum just to show one setting; redact the credential and any unrelated identifiers first.
Keep the token in the location and format documented for the exact implementation you chose. This article does not name a universal file path because the current API reference does not establish one for every server installation, host, or bridge. Restrict who can view the configuration and backups that contain it. If your hosting panel offers a secret or environment-variable field, confirm its behavior with that provider before using it; do not assume every panel masks or encrypts every setting.
If a token is exposed, remove the post or shared copy where possible, then reset the token in Discord’s Developer Portal and update the integration that is supposed to use it. Discord’s token reset guidance explains that a forgotten token must be regenerated; once reset, the old value should no longer be used. Restart or reload only through the documented process for your integration, and verify the new credential without displaying it in output.
Store a short note with the credential owner, intended server, channels, and rotation date. Never put the token itself in that note. If nobody can tell which installation uses a token, rotate it through the owner-controlled account and update only the intended integration. That avoids leaving an abandoned copy quietly authorized.
Test each message direction and channel boundary yourself#
Test a copy of the integration in an owner-controlled Discord server before exposing it to your real community. Record the game build, integration name and version, operating system, panel or launch method, channels, permissions, and test result. That record makes a future build update much easier to diagnose.
Write down the expected flow
State whether a test message should travel from the game to Discord, from Discord to the game, or both. Note the exact test channel and expected result before sending anything.
Check channel access from a normal account
Confirm that ordinary members cannot see staff-only channels, then confirm which channel the bot can view and send to. A permission screen for the owner alone is not enough to prove member visibility.
Run one direction at a time
Send a harmless test message in the direction the current implementation documents. Record whether it arrives, where it appears, and whether the server log reports an error. Do not assume a failed inbound test means the outbound route is broken too.
Try the denied-channel case
Remove the bot’s access to a test channel or use a channel outside its grant, then confirm the integration does not post or read there. Restore only the intended test permissions afterward.
Repeat after a restart or credential change
Follow the integration’s documented restart process, then repeat the same test. If you rotate the token, verify that the replacement works and that the old value no longer does; never paste either value into the test notes.
These are tests for you to perform; they are not results measured for this guide. If the implementation provides no way to distinguish message direction, cannot constrain the channel, or logs credentials, stop and resolve that issue before connecting a live community. Do not use a public server as the first place to discover whether a command or message route is active.
Check build and third-party compatibility before installing a bridge#
Verify compatibility against the exact Project Zomboid build, the bridge version, operating system, and server control panel. A mention of “Build 41+” or “Build 42” in a community post is not enough to prove support for your current branch. Current official news can help identify the game build you run, but you still need a compatibility statement from the integration maintainer or a repeatable test on your own isolated server.
The recent Project Zomboid Discord Bridge Workshop listing describes its own Linux and Pterodactyl-oriented setup. That description is specific to that project; it does not establish compatibility with Windows, another panel, or a managed host. Read its current requirements and source code or maintainer notes before installing. If the instructions require shell access, a webhook, a bot token, or a particular container layout, confirm that each is available and supported in your environment instead of copying commands from another panel.
Check the project’s latest release date, supported game branch, open compatibility issues, required permissions, and token storage before you install. Then make a backup of the relevant configuration and test on a disposable world or isolated instance. A server can start while the message relay is failing, so “the server booted” is not proof that the integration works. Conversely, an integration error should not be debugged by changing unrelated world or mod settings.
When no current compatibility claim exists, record that uncertainty and choose a supported alternative or leave the feature disabled. Do not present an old B41 tutorial as a current B42 procedure. The goal is to understand the access path before it handles player messages, not to get a green check mark at any cost.
Remove integration access cleanly when you stop using it#
Disable the route using the method documented by the integration, revoke the bot’s server access, remove channel overrides that were added only for it, and reset any token that may remain in old configuration or backups. If the integration was installed as a mod or separate service, remove it through its documented process and verify that the game server still starts without it.
Keep a brief change record: what was removed, which channels were affected, whether the token was reset, and which server build you checked afterward. This helps distinguish a deliberate shutdown from a broken relay when another admin takes over. If you are removing only one flow, confirm that the other routes are also disabled or still intentionally permitted; separate chat, logs, and command settings may not share one switch.
Finally, tell moderators and players what changed if the integration had been carrying their messages. Review any copies that remain in Discord according to your community’s retention rules. A clean removal closes the access path and the communication loop, rather than leaving an unused bot with permissions nobody remembers granting.
Quick answers
Does Project Zomboid have native Discord integration?
The current official server-options API lists Discord-related fields, but that reference does not prove a particular message flow works on your build. Verify the behavior you need on your own server.
Does a Project Zomboid Discord bot need administrator permission?
The sources here do not establish a minimum permission set for every integration. Avoid broad access unless the implementation documents a requirement you can verify.
Can Discord issue commands to a Project Zomboid server?
A command-channel option name alone does not prove which commands work or who can invoke them. Confirm the current implementation documentation and test only in a private environment.
Does a Project Zomboid Discord bridge work on every host?
No universal compatibility claim is supported here. One surfaced Workshop listing describes a Linux and Pterodactyl setup; check the exact project, build, operating system, and panel before installing anything.

