Voice chat across Discord servers—without moving everyone into one server

Discord Voice Relay Bot is a self-hosted bot that connects voice channels belonging to different Discord servers.

The idea is simple: when two communities want to talk, neither side should have to leave its usual server and join a shared voice space. The bot joins a voice channel on each side and relays the conversation between them.

There is no separate website to operate. Pairing happens through Discord slash commands and a short-lived code.

How it works

The default flow takes four steps:

  1. A user in Server A joins a voice channel and runs /bridge create.
  2. The bot returns a pairing code that remains valid for ten minutes.
  3. A user in Server B joins another voice channel and runs /bridge join <code>.
  4. The bot connects to both channels and begins forwarding audio in both directions.

Users can inspect the connection with /bridge status and stop it with /bridge leave. The bot also cleans up the bridge when a channel no longer contains any non-bot users.

An experimental group mode can be enabled by the operator. It allows a third Discord server to join with the same unexpired code. This mode is disabled by default.

What I built

The main engineering work is in the voice path, not only the command interface.

The bot has to maintain several Discord voice connections, receive Opus audio from each endpoint, mix concurrent speakers, and transmit the result to the other channels. It must also avoid relaying its own output back into the bridge and respond to users leaving, bot moves, and connection-state changes.

The current implementation includes:

  • Bidirectional audio relaying between different Discord servers
  • Short-lived pairing codes and Discord-native slash commands
  • Multi-speaker mixing in each direction
  • Several unrelated bridges running in one process
  • Automatic cleanup for empty channels
  • Basic reconnect, move, and rejoin handling
  • Optional allowlists for servers, voice channels, users, and roles
  • An experimental three-endpoint group mode
  • Structured JSON lifecycle and error logs

Architecture

I organized the project as an npm workspace instead of placing every responsibility in one bot file:

  • bridge-core manages bridge lifecycle and audio-routing coordination.
  • discord-adapter handles commands, voice connections, and Discord audio.
  • config-provider-local loads local configuration and permission rules.
  • state-store-local stores bridge states and pairing records.
  • self-hosted-bot composes the packages into the runnable service.

The separation keeps the bridge core independent from Discord login, environment files, and storage details. A future deployment can replace the configuration or persistence layer without rebuilding the audio pipeline.

The runtime uses Node.js, discord.js, and @discordjs/voice. Incoming Opus audio is decoded to PCM, mixed, and encoded again before being sent to the other Discord voice channels.

Designed for self-hosting

The project is intended to be operated by the community using it. The repository includes a Dockerfile and Docker Compose configuration, while runtime state and pairing records are stored in a local JSON file.

Operators can restrict bridge access to selected Discord servers, channels, users, or roles. Pairing codes and detailed errors use ephemeral Discord responses by default so they are less likely to remain visible in public text channels.

The code is currently available under the MIT License, allowing developers to use, modify, and integrate it with minimal licensing requirements. The project name, logo, domains, and other brand assets are not automatically licensed with the source code.

Current state

The repository contains a runnable self-hosted MVP.

As of July 13, 2026, its JavaScript checks, all 17 automated tests, and Docker Compose configuration validation pass. The tests cover normal and group pairing-code behavior, expiry and duplicate joins, bridge topology rules, and local state storage.

The project is still in development. It does not yet have a confirmed public product URL or release tag, and the repository contains no publishable latency, CPU, or long-running stability measurements. Live Discord voice behavior and audio quality still require further real-server testing.

There is also no dashboard, public server discovery, recording, transcription, Stage Channel support, or same-server channel bridging.

At this stage, the project demonstrates a focused technical path: separate Discord communities can remain in their own voice channels while a self-hosted bot carries the conversation between them.