Choosing Your Discord Music Bot Stack: Lavalink, JMusicBot, or Red
Table of Contents
If you want a music bot in your Discord server, the path isn’t obvious anymore. The big public music bots (Groovy, Rythm, etc.) all got shut down. The remaining big ones are paid and rate-limited. So the answer keeps drifting back to “self-host one yourself.”
Witchly supports three different music-bot approaches on its Applications tier — Lavalink, JMusicBot, and Red — and they’re three genuinely different philosophies, not just three skins of the same thing. This post walks through what each one is, when to pick it, and the rough effort gradient.
The big-picture decision
Three honest options, in order of effort:
Easiest: JMusicBot. A standalone Java music bot that runs by itself. Configure once, invite to your Discord, done. No coding required.
Middle: Red-DiscordBot. A modular Python bot framework with a built-in audio cog. You get music plus dozens of other features, all behind a single bot. Some basic command-line usage.
Most flexible: Lavalink. A backend audio service that doesn’t include a Discord bot at all — you (or someone you trust) writes a custom bot that uses Lavalink as its audio engine. Most coding, most flexibility.
If you don’t want to think about it, JMusicBot is the right answer for 80% of small Discord servers. If you want a bot that does music and moderation and reaction roles and trivia and whatever else, Red is the answer. If you’re building something custom and need professional-grade music quality, Lavalink is your floor.
Let’s go through each.
JMusicBot: the no-thinking option
JMusicBot is a single Java application — a self-contained Discord bot whose only job is play music. It supports YouTube, SoundCloud, Bandcamp, direct URL streams, local files, and a few other sources out of the box.
What it does
- Plays music in voice channels via simple commands (
!play,!skip,!queue, etc.) - Handles a queue, playback controls, now-playing display
- One-bot-per-server pattern — your JMusicBot serves only your Discord
- Optional config knobs for prefix, max volume, owner-only commands, etc.
What it doesn’t do
- Multi-server hosting (one JMusicBot per Discord)
- Anything except music
- Slash commands (it’s a prefix-based bot, e.g.,
!play)
When to pick JMusicBot
- You want music in your Discord server and nothing else
- You don’t want to write code or maintain a custom bot
- You’re fine with prefix commands rather than slash commands
- Your community is small enough that one bot dedicated to one server is the right model
Setup difficulty
Lowest. Deploy from the dashboard’s Applications → JMusicBot option. The Configure step asks for your bot token (which you get by creating an Application in Discord’s developer portal), the owner ID, and a few config defaults. The Console tab streams the bot’s startup; once it connects to Discord, it’s ready.
You don’t write code. You don’t manage Lavalink yourself. You don’t deal with Python environments. It just runs.
The trade-off: you get exactly what JMusicBot provides — no more, no less.
Red-DiscordBot: the swiss-army-knife option
Red is a Python-based, modular Discord bot framework. The core bot is just an event loop and a command dispatcher; everything else is a “cog” (a module) you load.
What it does
- Music (via the built-in Audio cog)
- Moderation (Mod cog: kick, ban, mute, etc.)
- Reaction roles, trivia, leaderboards, custom commands, economy systems, leveling, alerts…
- A whole community-developed ecosystem of third-party cogs you can add via
[p]repo addand[p]cog install - Slash commands (modern Discord interaction style)
What it doesn’t do
- Single-purpose simplicity. Red is a system, and like any system it has surface area to learn.
When to pick Red
- You want a Discord bot that does many things, and music is just one of them
- You’re comfortable running occasional CLI commands to install/update cogs
- Your community will benefit from features beyond music (moderation, custom commands, leveling, etc.)
- You’re willing to invest a few hours up front in the initial setup, in exchange for years of low-maintenance feature richness
Setup difficulty
Medium. Deploy from the dashboard’s Applications → Red Discord Bot option, set up your bot token in the Configure step, and the Console becomes your interactive setup environment.
The first time Red runs, it asks you a series of setup questions in the console — owner ID, prefix, default cogs to load, etc. After setup, you typically:
- Use a Discord channel to issue commands (the bot reacts to
[p]load Audioto enable the music cog) - Add cogs from third-party repositories for whatever extra features you want
- Configure each cog as needed
Once configured, Red just runs. You restart it after cog updates or major Python-package upgrades.
How its music compares to JMusicBot
Red’s Audio cog uses Lavalink under the hood — Red is essentially “JMusicBot quality of music + a thousand other features.” But because Red expects a Lavalink node to talk to, you’d typically deploy a Lavalink instance alongside (which Witchly makes easy) and point Red at it.
Some Red distributions ship with a built-in (managed) Lavalink subprocess that just works — no separate Lavalink deploy. Confirm with your specific Red version which model it uses.
Lavalink: the backend for custom bots
Lavalink isn’t a Discord bot. It’s a Java service that provides audio streaming as a network API. You (or somebody on your team) writes a custom Discord bot in any language that can speak Lavalink’s protocol — Node.js, Java, Python, etc. — and Lavalink does all the heavy audio work for you.
What Lavalink gives you
- The same audio engine that powers Red, JMusicBot, and most modern music bots — but separated from any specific bot
- Source plugins for YouTube, SoundCloud, Bandcamp, HTTP streams, local files
- Queue management is delegated to your bot (you have full control)
- You can have multiple bots talking to the same Lavalink, sharing one audio backend
What you have to bring
- A custom Discord bot you wrote (or an existing bot codebase you’re maintaining)
- Code that handles slash commands, queue UI, error handling, etc. Everything user-facing is your responsibility.
When to pick Lavalink
- You’re building a Discord bot from scratch and want music as one feature
- You have an existing bot (you wrote in Node.js, Java, etc.) and want to bolt music onto it
- You want full control over the queue model, command UX, embed design, error messages
- You want to share one audio backend across multiple bots
Setup difficulty
Highest, but only because you have to write code. The Lavalink deployment itself is the easiest of the three — set the password in the Configure step, deploy, you’re done. The complexity is in your custom bot, where you handle:
- WebSocket connection to Lavalink
- Forwarding Discord voice state to Lavalink
- Sending play/pause/skip commands
- Handling track-end events to advance the queue
A working Lavalink-based bot in Node.js is roughly a few hundred lines of code. Most modern client libraries (lavalink-client, magmastream, etc.) handle the protocol details — you just write the command handlers.
If you’re building a serious bot you want to maintain for years, Lavalink is the right choice. If you just want music tonight, it’s overkill.
For more on Lavalink specifically, see the Lavalink-focused guide.
A realistic decision tree
Do you want a Discord music bot for ONE small community,
no other features, no coding?
└── JMusicBot. You're done in 10 minutes.
Do you want a single bot that does music PLUS lots of other things
(moderation, custom commands, etc.) for your community?
└── Red-DiscordBot.
Are you building/maintaining a custom Discord bot in code,
and want music to be one capability inside it?
└── Lavalink, called from your bot.
Do you want to host music for multiple Discord servers
without writing code?
└── Realistically: deploy one JMusicBot per server.
(Or write a custom bot that uses Lavalink, but at that point you're not "no-code" anymore.)Resource expectations
Each of these is a Java or Python application. Resource needs:
| Stack | Min RAM | Notes |
|---|---|---|
| JMusicBot | 512 MB | Light. Free or Helper plan is fine. |
| Red | 1 GB | Python, with Audio cog + Lavalink subprocess if used. The Helper plan is the floor. |
| Lavalink alone | 1 GB | Audio decoding is CPU-heavy during peaks. The Helper plan is fine for one bot in moderate use. |
| Lavalink + custom bot (separate) | 2-3 GB combined | Two services. The Daemon plan for the heavier of the two. |
CPU usage spikes during heavy concurrent music streaming. RAM usage stays mostly flat.
What about voice quality?
All three use the same underlying audio engine ultimately (lavaplayer fork). Voice quality is identical at the codec level. What varies:
- Network distance to Discord’s voice gateway. Witchly servers in Falkenstein have low-latency routes to European voice gateways and acceptable routes to NA East. APAC routes through US, so latency is higher (see the server location post).
- Buffer settings. All three let you tune buffering. Default 400ms is fine for stable connections. Bump to 1000-2000ms if you hear glitches.
- CPU pressure. A Lavalink node running 50 concurrent streams on a constrained plan will start dropping frames. Upgrade to a bigger plan, or scale to multiple Lavalink nodes.
Common pitfalls regardless of stack
YouTube source plugin breakages
YouTube periodically changes how its streams are tokenised, which breaks the YouTube source plugin shipped with each of these stacks. When this happens, every Discord music bot worldwide stops loading YouTube tracks at roughly the same time. The fix is always: update the source plugin to the latest version that handles the new tokenisation.
Witchly’s Discord support channel posts the latest known-good plugin versions as they emerge. Don’t panic when YouTube breaks — it’s industry-wide, not specific to your bot.
”It works but only joins voice channel and plays nothing”
Almost always: your bot’s voice_state_update and voice_server_update events aren’t being forwarded to the audio backend. For JMusicBot and Red, this is handled internally. For custom Lavalink bots, this is your responsibility — review your client library’s docs for how to wire forwarding.
”Audio cuts out periodically”
Either CPU saturation (check the dashboard’s resource graphs) or network jitter to Discord. CPU is fixable by upgrading the plan; jitter is fixable by bumping the buffer to 1000-2000ms.
”The bot worked yesterday and now won’t connect”
Token rotation. Discord invalidates tokens that have been leaked, posted publicly, or appeared in committed source code. If your bot stops working, check Discord’s developer portal for token-status warnings and regenerate if needed.
Wrapping up
You have three good options because they serve three genuinely different needs. JMusicBot is the get-it-working-tonight choice. Red is the “I want a real bot, not just music” choice. Lavalink is the “I’m building something custom” choice.
There’s no objectively “best” pick — pick the one that matches what you actually want to invest in your Discord setup.
Deploy any of the three from the Applications pricing page, or read the per-app docs: