Karaoke Eternal: a self-hosted queue server for MP3+G and MP4 karaoke nights
Open karaoke party system
At a glance
- What is it?
- Karaoke Eternal splits a karaoke night into a Node server, a mobile browser app and a fullscreen player. The README promises MP3+G and MP4 playback plus dynamic queues, but the docs, not the README, carry the installation detail.
- Who is it for?
- Adopt Karaoke Eternal if you already hold a library of MP3+G or MP4 karaoke files and want guests to queue from their own phones without an account on someone else's service. Skip it if you need a hosted product with no server to maintain, or if your library is in a format the player does not list.
- Can I use it commercially?
- Yes. ISC is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 28 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The queue problem Karaoke Eternal is built to solve
A karaoke night has a logistics problem before it has an audio problem. Someone has to collect requests, decide an order, and keep the order from being dominated by whoever is loudest or fastest to the laptop. Karaoke Eternal treats that as the product. The README describes a system where guests find and queue songs from their phone's browser, and it lists dynamic queues as a feature intended to keep parties fair. Joining is handled with QR codes and guest accounts, so a singer does not need to install anything or register on a third-party service. Multiple rooms and queues can run at once, optionally behind a password. The intended operator is someone hosting at home, in a bar back room, or at a recurring event, who is willing to run a server. The project is self-hosted, and the README states there are no ads and no telemetry, which matters if you are pointing a room full of guests at a web app you control.
Three parts: server, app, and a player that is part of the app
The README is explicit that Karaoke Eternal has three parts, and the split explains most of the deployment decisions. The server serves the web app and the media files, and the documentation says it runs on a Windows PC, a Mac, a Raspberry Pi, or a Synology NAS. The app is the mobile browser interface guests use to search and queue. The player is not a separate binary: the README calls it just another part of the app, meant to run fullscreen on whatever system handles audio and video for a room. That means the machine driving the speakers loads the same web app in a browser and enters player mode. Rooms are an admin-only concept in the docs, and each room has its own queue. The storage layer is SQLite, which matches the single-server design: one process, one database file, no external service to run alongside it. The media files themselves are served by the server, so the player is streaming from your host rather than from a cloud bucket.
MP3+G, MP4, and the visualization path
The playback formats are listed plainly: MP3+G, which is an MP3 paired with a CDG lyrics file, including zipped versions of that pair, and MP4 videos. There is also a visualization mode described as music-synced, with automatic lyrics background removal, which suggests the player can generate a background for lyric display rather than requiring a video file per song. That last feature is the one most likely to depend on browser WebGL support, since the README refers to WebGL visualizations. If your library is CDG-based, the relevant question is how the files are named and organized on disk, because the server has to match the CDG to its MP3. The README does not describe a naming convention or a scanning step, so treat library import as something to confirm in the server documentation before you point it at a large collection. Formats outside the listed set, such as a proprietary karaoke container, are not covered here and should not be assumed to work.
Getting it running from the repository
For a deployment, the README points at the installation methods listed in the server documentation rather than repeating them, so the exact package or container command depends on which method you pick and is not in this material. What the README does give is the development path. You need Node.js v24 or later. Fork and clone the repository, run npm i, then run npm run dev and look for the line beginning "Web server running at", which prints the server URL. That is the loop for working on the code, not the recommended way to run a party. For an actual event, the server documentation is the source, and it covers the Windows, Mac, Raspberry Pi and Synology cases separately. The one configuration concept the README names directly is rooms, which are admin-only and can be password-protected. Everything else about configuration lives in the linked docs rather than in the repository README.
Where the design puts work on you
The player outputs music only. Microphones are explicitly not required, and the README frames this as a feature: your audio setup can be as simple or as complex as you like. Read it as a boundary instead. Karaoke Eternal does not mix vocals, does not apply effects, and does not manage a microphone chain. You are supplying a mixer, an interface, or a separate karaoke amplifier, and you are responsible for getting the music and the microphones to the same place without feedback. The FAQ is where the project discusses a recommended audio and microphone setup, which tells you the maintainers consider this out of scope for the software. The second boundary is operational: self-hosted means you own the uptime. If the server process dies mid-party, the queues die with it, and there is no hosted fallback. The third is scale. SQLite and a single Node process fit a room or a few rooms. The README advertises multiple simultaneous rooms, but nothing in the material describes clustering or a shared database, so treat a multi-venue deployment as unproven here.
How this differs from hosted karaoke services
The obvious alternative is a commercial hosted karaoke platform, where the song catalog, the queue and the playback all live on the vendor's infrastructure and you open a page. The difference is not just where the code runs. A hosted service supplies the catalog, so you are limited to what it licenses, and it can change its terms, its pricing or its catalog at any time. Karaoke Eternal inverts that: you supply the media, the server and the network, and in exchange nobody inserts ads, collects telemetry, or decides which songs exist. For an engineer with an existing CDG or MP4 collection, the hosted route means either re-buying content or abandoning it. For someone with no collection and no interest in running a machine, the self-hosted route is strictly more work. A second comparison point is a plain media server with a queue plugin. That gets you playback, but the queue is a shared playlist rather than a party mechanic with guest accounts, QR joining and per-room queues. Karaoke Eternal's value sits in that queue layer, not in the decoder.
Maintenance, releases and the ISC licence
The project is TypeScript and licensed under ISC, a permissive licence that is functionally close to MIT: it allows use, modification and redistribution with a copyright notice and a liability disclaimer. That is a summary of the licence family, not legal advice, and if you plan to redistribute a modified server you should read the LICENSE file in the repository. The release history shows v2.0.0 in December 2025, then v2.0.1 in January 2026 and v2.0.2 in February 2026, with repository activity continuing into August 2026. Two patch releases after a major version suggests the 2.x line is being maintained rather than abandoned, but the material here does not describe a support policy, a deprecation window, or a migration path between majors. The practical upgrade cost is the usual one for a self-hosted Node app: the README requires Node.js v24 or later for development, so your host needs a runtime you can update, and a Synology NAS or Raspberry Pi install may pin you to whatever the package method provides. Back up the SQLite database before a major upgrade, because queues and rooms live in it.
Editorial conclusion
Adopt Karaoke Eternal if you already hold a library of MP3+G or MP4 karaoke files and want guests to queue from their own phones without an account on someone else's service. Skip it if you need a hosted product with no server to maintain, or if your library is in a format the player does not list. Before committing a party to it, verify three things: that the server installs on your target machine using one of the documented methods, that the player renders your specific files (the README names MP3+G, zipped MP3+G and MP4, and nothing else), and that your audio and microphone routing works with a player that only outputs music.
Community notes