Vocard: a Discord music bot that keeps playback decisions off the bot process

Vocard is a thin bot in front of a Lavalink node

The architecture is visible in the requirements rather than hidden. Vocard needs Python 3.11 or newer and a Lavalink server running version 4.0.0 or newer. That second requirement is the design decision that shapes everything else. Lavalink does the audio streaming and decoding, and Vocard is the layer that turns Discord commands into Lavalink requests and returns playback state to the chat. The repository layout is consistent with that split. There is a voicelink directory that is the client side of the Lavalink connection, a cogs directory holding the command modules, main.py as the entry point, and function.py for shared helpers. The consequence for an operator is that a music bot with Vocard is not one process but a bot and a streaming node, and the node is the piece that consumes bandwidth and memory when a queue is playing.

The feature list is long, and the platform support is the part that matters

The advertised capabilities cover the usual ground for this kind of bot: fast song loading, smooth playback, a lightweight design, playlist support, lyrics, sound effects and multiple languages. Both command styles are supported, so slash commands and message prefixes work, which matters for servers that have migrated partially or have bots that only respond to one style. Settings are described as fully customizable, and the localization support is visible in the tree through a langs directory and a local_langs directory, the second presumably for translations contributed from outside the core project. The line that should drive your decision is the platform support, because it determines whether your users can queue anything at all. YouTube, SoundCloud, Spotify, Twitch and Apple Music are all named, and the phrasing is that many platforms are supported rather than that every platform is. A bot that claims Spotify support but cannot play a track because the source needs authentication will disappoint users quickly.

Docker deployment separates building from running

A Dockerfile is included, and it is a two stage build that tells you something about the dependency profile. The builder stage uses python:3.12-slim-bookworm, installs gcc and python3-dev, copies only the requirements.txt file so the dependency layer caches independently of the source, and then runs pip install against that file. The runtime stage starts from the same slim base, copies the installed site-packages directory from the builder, copies the application code, and runs python -u main.py as its command. The -u flag is the kind of detail that matters in containers, since without it Python buffers output and the container logs arrive in chunks rather than as they happen. The runtime image ends up with the application and its dependencies but no compiler toolchain, which is a reasonable size outcome for a bot that is mostly network traffic. The Python version in the image is 3.12, while the stated requirement for running the bot directly is 3.11 or newer. The dependency layer is installed from the pinned requirements file, and only that file is copied first so the image rebuilds quickly when only application code changes.

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

Those two lines are the whole installation step. Everything else in the builder stage exists to compile whatever needs a compiler, and nothing of that survives into the runtime image.

The dependency list is small and pinned

The requirements file is short, which is a good sign for a service that has to stay up. It lists discord.py at version 2.7.1 as the Discord client, motor at 3.6.0 for the asynchronous MongoDB driver, dnspython at 2.2.1, tldextract at 3.2.1 and validators at 0.18.2 for working with URLs, humanize at 4.0.0 for formatting, beautifulsoup4 at 4.11.1 for scraping, psutil at 5.9.8 for process and system information, aiohttp at 3.11.12 for HTTP, and python-dotenv at 1.1.1 for reading configuration from the environment. Every version is pinned to an exact number rather than a range, so an install is reproducible but also frozen, and you will be the one applying security updates. Nothing in the list is a Lavalink client library, which confirms the client for that connection is written inside the project, in the voicelink directory.

Two deployment routes, one of them automated

You have three practical ways to get Vocard running, and they differ in how much work you do and how much control you keep. The setup page in the documentation is the manual route, where you clone the repository, install the requirements and supply your own configuration. The Docker route packages that into an image built from the Dockerfile. The third route is the One Click Installer, which lives in its own repository, ChocoMeow/Vocard-Installer, and exists precisely so that the manual route becomes a few clicks. That separation is the pattern to notice across the project: the core bot, the installer and the dashboard are three separate repositories rather than one. For a customization dashboard there is a fourth option, the Premium dashboard in ChocoMeow/Vocard-Dashboard, which is a distinct product from the open source bot. A settings file named settings Example.json sits at the top of the tree, so the configuration format is a JSON file you supply.

What Vocard does not do, and what to check before trusting it

Two limits are worth naming. The first is that the audio pipeline depends on an external component you have to run and keep alive, and a Lavalink node that dies takes the queue with it while the bot stays online and appears to be working, which is a failure mode that is annoying to diagnose from the chat side alone. The second is that the platform support is only as good as the source services at the time, and YouTube in particular changes how extraction works often enough that a music bot of this kind can need updates to keep playing links. On the project side, the release history is not continuous. The tags are v2.7.3 from 2026-05-09, v2.7.2 from 2025-08-25 and v2.7.1 from 2025-04-19, so there is a long gap between v2.7.2 and v2.7.3, while the last push to the repository was on 2026-10-06. There is also an update.py at the top level of the tree, so updating is scripted rather than manual.

Editorial conclusion

Vocard fits a Discord community that wants a music bot with slash commands, lyrics and per-server settings without writing one, especially if you can run a Lavalink node, since the streaming work happens there rather than inside the bot process. It does not fit a server that expects the bot to be the only moving part on the host, because Lavalink 4.0.0 or newer is a separate requirement, and it does not suit you if you want the customization dashboard without paying, since the dashboard lives in its own repository. Before deploying, read the setup page in the docs, check your Python version against the 3.11 or newer requirement, and confirm that the Lavalink node your Lavalink version expects is reachable from the bot before you invite the bot to a large server.

Frequently asked questions

Official sources

1. ChocoMeow/Vocard on GitHub
2. License: MIT
3. Project website
4. README
5. Releases