Discord plus game server integration without leaking admin tokens
Discord plus game server integration without leaking admin tokens
Most game servers live half in-game and half in Discord. Connecting them with a chat bridge, a status bot, or admin commands is useful and easy to do badly.
This article covers the common patterns, the security mistakes people make, and the setup that works for normal community servers.
The three integration types
Use webhooks where you can. Bots where you must. Command bridges only when you've thought carefully about who has access and how to audit it.
What "Discord integration" actually means
There are three different integrations people lump together:
- Chat bridge. In-game chat appears in a Discord channel and vice versa.
- Status bot. A bot that posts when the server starts, stops, or hits milestones.
- Admin command bridge. Run admin commands from Discord (
/restart,/kick,/ban).
Each has a different risk profile.
Chat bridges
For Minecraft, DiscordSRV is the standard. For other games, you'll usually find a similar mod or external tool (VintageCord for VS, DiscordConnector for Valheim).
How it works:
- A bot you create in Discord's developer portal has permission to read and write in a channel.
- Your server runs a plugin/mod that uses the bot's token to push and pull messages.
Setup is straightforward. The pitfalls:
The bot has a token. Treat it like a password. Anyone with the token can post as the bot, read the channel, and do whatever Discord lets the bot do.
Don't commit the token to git or share it casually. People put bot tokens in screenshots of their config file in support forums. Discord scans for leaked tokens and invalidates them, but the damage between leak and detection can be significant.
Restrict the bot's permissions. A chat-bridge bot needs: Read Messages, Send Messages, Read Message History, in one specific channel. It does NOT need: administrator, manage roles, kick / ban, manage server. Grant minimum permissions.
Status bots
A bot that posts "Server is online" / "X joined / left" / "Server crashed."
Risks are lower because the bot mostly posts. Still:
- Same token-secrecy rules.
- Limit posting frequency. A poorly-written status bot can spam join/leave events 200 times during a brief network blip.
Admin command bridges
This is where things get dangerous.
If your Discord has a #staff-commands channel where staff can type !restart and the server restarts, you have:
- Trust in Discord's identity ("the person who typed it is who their account claims to be").
- Trust in the bot's permission system ("only certain roles can use this command").
- Trust in the bridge software's filtering.
Each of those can fail. A staff member's Discord account gets compromised. The bot's permission check has a bug. A bridge logs all commands to a public channel.
For admin commands, the rules:
Limit which commands can be bridged. Maybe restart is fine. op is not. Whitelist, not blacklist.
Limit which roles can use them. A specific staff role only, never @everyone.
Audit log. Every Discord-initiated command should be logged somewhere (a separate channel or a database). If something goes wrong, you can trace it.
Two-factor for staff Discord accounts. This is between the staff member and Discord but you should require it. A compromised account that has access to admin commands is a serious risk.
A common-sense default
For most community servers:
- Chat bridge: yes. Low risk, high value.
- Status bot: yes. Low risk, moderate value.
- Admin command bridge: only if you really need it. The convenience is small; the risk is real.
Most admins live without command bridges and do fine. SSH or panel access is the right place for admin work.
Webhook vs bot
A subtle but important distinction:
| Webhook | Bot | |
|---|---|---|
| Capabilities | Write-only to one channel | Read, write, manage |
| Setup | Generate URL, paste in your script | Register app, manage permissions, store token |
| Compromise | Can spam one channel | Can do whatever bot permissions allow |
| Right for | Status messages, alerts, one-way notifications | Chat bridges, two-way interactions |
For status messages and one-way notifications (server crashed, server backed up), use webhooks. They're write-only, can't be used to read anything, and are simpler.
For two-way (chat bridge, admin commands), you need a bot.
Use the simpler mechanism where it works.
Storing tokens
Your bot token shouldn't be in a config file in plain text checked into version control. Options:
- Environment variables. Set the token in the OS environment, read by your plugin / mod.
- Secrets manager. For more serious setups, a tool like Vault or even a dotfile in a restricted directory.
- A config file with strict permissions.
chmod 600so only the owner can read.
For most hobbyist setups, a config file with restricted permissions is fine. Just don't share screenshots of it, and don't put it in git.
A real example: minimal Discord setup
For a small Minecraft community:
- Webhook for server events. Backup completes, server restarts, errors logged. Wired up from a shell script or a panel hook.
- DiscordSRV plugin. Bridges in-game chat to one Discord channel. Bot token in
config.ymlwith file permissions restricted. - No admin command bridge. Admins use the panel or SSH.
That setup is 30 minutes to deploy, handles 95 percent of use cases, and is reasonably safe.
Risks people don't think about
The bot reading messages. If your bot has "Read Messages" permission, every message in that channel is potentially seen by the bot. The bot can be misconfigured or hacked. Don't put secrets in a channel a bot can read.
Public bot lists. If your bot is "public" (others can invite it to their servers), they can use it. Most chat-bridge bots are private. Confirm yours is.
The .env file gotcha. Storing the bot token in .env is fine. Forgetting .env is in .gitignore is not. Check.
Logs. Some chat-bridge plugins log debug info including the bot token. Audit logs for accidentally-leaked tokens. Worst case: rotate the token.
When a token leaks
If you suspect your bot token leaked:
- Go to the Discord Developer Portal.
- Find the bot.
- Reset the token.
- Update your config with the new token.
- Restart the integration.
Discord proactively rotates leaked tokens it detects, but you should not rely on that. If in doubt, rotate.
Plugins / tools by game
Minecraft (Paper): DiscordSRV.
Vintage Story: VintageCord (the standard bridge) or similar mods.
Valheim: DiscordConnector (nwesterhausen) for webhook events; DiscordBot (RustyMods) for two-way chat bridging.
Eco: Eco supports Discord via mods; check the community modlist.
Rust, ARK, others: Discord webhooks plus an external "watcher" script.
For most games, a webhook plus a simple watcher script gives you 80 percent of the integration for a tiny fraction of the setup cost.
Conclusion
Discord integration is easy to set up and easy to misconfigure. The safe pattern: webhooks for one-way notifications, a private bot with minimum permissions for two-way chat, no admin command bridge unless you really need it, and tokens stored carefully.
This isn't security theater. Real game communities have been compromised through leaked bot tokens. Spend 10 minutes on the setup discipline; spend 10 years not regretting it.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
Load balancing, L4 vs L7 and when each matters
Many services run on multiple servers. A load balancer is the thing that decides which incoming request goes to which server. It sounds simple. The implementation choices have meaningful consequences.
GRE tunnels, how scrubbing services route traffic through their network
When a DDoS protection service "absorbs" attacks on your behalf, the actual mechanism usually involves a GRE tunnel: a virtual point-to-point link between your real server and the protection service's network. Cleaned traffic comes out t...
BGP hijacks and RPKI, the routing security problem
BGP is the protocol that makes the internet work. It's also one of its weakest links: by default, BGP has no authentication. If a router announces "I can reach this prefix," other routers tend to believe it. This has caused outages, redi...