Configuration
Token, nodes, debug logs, and node rotation behavior (all config-driven).
A bot that you can maintain is a bot where secrets and tuning knobs live in config, not scattered through code.
This page covers:
- where to store your token safely
- how to configure multiple nodes (main + backup)
- how to toggle Moonlink debug logs from config
- how node selection and player failover work
config.json (classic approach)
Create a config.json in your project root:
Never commit your token. Add config.json (or .env) to .gitignore.
Debug logs (controlled by config)
Moonlink emits a debug event with helpful internal messages.
A solid rule:
debug: true→ attach the listener and print logsdebug: false→ do nothing (clean production output)
You’ll see the exact wiring inside the Creating Your First Bot page.
Node “rotation” (what Moonlink actually does)
Most bots don’t rotate nodes manually.
What usually happens is:
- You configure multiple nodes.
- When a player is created, Moonlink chooses a node based on your selection strategy.
- If a node disconnects and
autoMovePlayersis enabled, Moonlink can move players to another healthy node.
selectionStrategy
moonlink.options.node.selectionStrategy controls how Moonlink picks the best node:
leastLoad(default): balances using penalties/load.players: fewest total players.playingPlayers: fewest active players.memory: most free memory.cpuSystem: lowest system CPU load.uptime: highest uptime.random: random node.priority: uses each node’spriority.
If you want deterministic selection, use priority. If you want the most common “smart default”, use leastLoad.
autoMovePlayers (failover)
When autoMovePlayers: true, a node going offline can trigger player migration.
For production: keep avoidUnhealthyNodes: true and set realistic CPU/memory thresholds. This prevents moving players onto a dying node.
Environment variables (.env)
If you prefer secrets outside JSON, use env vars:
How you load env vars depends on your runtime. The important part is: don’t hardcode secrets.