Running a Music Bot: Split the Bot From the Audio Node

The first music bot most developers write streams audio from inside the bot process: fetch a track, decode it with FFmpeg, encode it to Opus, send it to Discord. It works in one server. At twenty servers the bot stutters, CPU is pinned, memory balloons, and a single crash stops every queue at once.

The fix used by nearly every serious music bot is to split the work in two: a bot that handles commands, and an audio node that handles playback. On Discord, that audio node is almost always Lavalink.

What each half does

The bot is a normal Discord bot. It receives slash commands, searches for tracks, manages queues and settings, and tells the audio node what to play. It’s lightweight — the same kind of process as a moderation bot.

The audio node does the heavy lifting: resolving tracks from sources like YouTube or SoundCloud, downloading and decoding audio, applying filters, encoding to Opus, and streaming it to Discord’s voice servers. It needs CPU, memory and network throughput.

Your bot talks to Lavalink over a WebSocket and REST API using a client library. When someone runs /play, the bot asks Lavalink to load the track, then tells it to play in a given guild’s voice channel. Lavalink streams the audio directly to Discord’s voice server. If Lavalink is new to you, start with what is Lavalink?.

Why splitting helps

Resources scale independently

Text commands and audio have completely different profiles. Audio needs steady CPU for encoding and bandwidth for streaming; commands need very little. When they share a process, you size the whole thing for audio. Split apart, the bot can run on a small plan while the audio node gets the resources it needs — and you can scale each as it grows.

Crashes are contained

If the bot process restarts during a deploy, Lavalink keeps its players alive, and a reconnecting client can resume. If the audio node restarts, the bot stays online, answers commands and can reconnect players. In an all-in-one design, any crash stops every song in every server.

Better audio quality

Lavalink is built on a mature, optimised audio pipeline in Java, with jitter buffering, efficient Opus encoding and a full set of filters. It’s very hard to match that stability by piping FFmpeg in a Node.js or Python process, especially under load.

Multiple bots, one node

Several bots — or several shards of one bot — can connect to the same Lavalink node, as long as it has enough resources. That’s useful if you run a main bot and a premium or test bot.

How to host each half

The bot

Host the bot like any other Discord bot, close to Discord’s US East infrastructure for fast commands. On Kerit Cloud, a music bot’s command process typically fits in the Pro or Extreme Discord bot plans once audio is offloaded; the bot workload matrix suggests Extreme and up for music bots because queues, search results and many connected guilds add up.

The audio node

For the audio node you have two choices:

• Managed Lavalink — the node is installed, configured, updated and monitored for you, with LavaSrc and SponsorBlock pre-installed. You receive a host, port and password and plug them into your client. Kerit Cloud’s managed plans start at ₹59/month.
• Self-managed Lavalink — a server with root SSH, Java 17 pre-installed and full control over application.yml, plugins and JVM flags. Self-managed plans start at ₹49/month.

Managed vs self-managed Lavalink compares them in detail.

Where to put the node

Audio latency depends on the distance between the node and the Discord voice server handling the call — which is chosen by region, near your listeners. If most of your users are in India, a node in Mumbai or Delhi will sound better than one in Virginia, even though the bot itself should stay in US East. Kerit Cloud offers Lavalink in 14 regions; see choosing a Lavalink region.

Connecting the two

Your bot needs a Lavalink client library. Popular options:

Configuration comes down to three values from your node: host, port and password. Keep them in environment variables:

LAVALINK_HOST=node.example.net
LAVALINK_PORT=2333
LAVALINK_PASSWORD=your-node-password

Step-by-step guides: connecting discord.js with Shoukaku and connecting discord.py with Wavelink.

Design tips for a stable music bot

• Store queues outside the process if they need to survive restarts. A small Redis or database table holding the current queue per guild lets the bot rebuild players after a deploy.
• Handle node disconnects. Client libraries emit events when the node disconnects or reconnects. Log them, and tell users politely if playback stops.
• Plan for more than one node. Big bots connect to several Lavalink nodes and spread players across them; most client libraries support this. See running multiple Lavalink nodes.
• Leave empty channels. Disconnect after a few minutes alone in a voice channel. It saves node resources and is good etiquette.
• Don’t cache giant search results. Keep only what you need to show the user and play the next track.

What about source availability?

Lavalink v4 moved YouTube support out of its core into a dedicated plugin, and platforms regularly change how they serve media. Keeping sources working is part of running a music bot — a strong argument for managed hosting if you don’t want to track plugin updates yourself. Background is in the YouTube source plugin.

Also check the terms of the platforms you stream from and respect Discord’s developer policies; responsibility for how the bot is used sits with its operator.

Summary

Music bots run best as two parts: a lightweight bot for commands and queues, and a Lavalink node for resolving, decoding and streaming audio. The split lets each scale independently, contains crashes, improves audio quality and lets several bots share one node. Host the bot near Discord in US East, host the node near your listeners, connect them with a client library and three environment variables, and design queues to survive restarts.