KAPOW!Comic-book karaoke queue manager for bars and parties

Install with Docker Compose

KAPOW! listens on port 3000. Unlike the other Coral modules it has no SQLite volume, because its state lives in Supabase:

services:
  kapow:
    image: getcoral/kapow:latest
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      SUPABASE_URL: ${SUPABASE_URL}
      SUPABASE_PUBLISHABLE_KEY: ${SUPABASE_PUBLISHABLE_KEY}
      SUPABASE_DB_PASSWORD: ${SUPABASE_DB_PASSWORD}
      YOUTUBE_API_KEY: ${YOUTUBE_API_KEY}

Before the first run you need two external things: a Supabase project, which provides the realtime Postgres behind the room state, and a YouTube Data API key for song search. Both are free at the volumes a karaoke night generates, but do check your YouTube quota if you are running a busy venue several nights a week.

The published image is getcoral/kapow on Docker Hub. Note that the module’s own documentation currently walks through a local pnpm dev setup rather than the container, so the Compose service above is assembled from the image’s own configuration rather than copied from the docs.

How a night actually runs

The host opens a room. KAPOW! generates a join code and a QR poster you can put on the bar, on tables, or on the screen between songs.

Guests scan it with the camera app they already have and land in a browser. There is no download, no account, and no sign-up — which is the whole design constraint, because in a real bar any friction above “point your phone at this” means most of the room never joins. They search for a track, add it, and vote on what other people have queued.

The host works from a separate booth view: the running order, what is coming next, and direct control over promoting, reordering and dropping songs. Voting shapes the queue; the host still decides.

The TV route is the third surface — a full-screen display for the projector or the screen behind the stage, showing what is playing and who is up next.

Why Supabase rather than SQLite

Every other Coral module keeps its state in a local SQLite file, and KAPOW! is the exception. The reason is that a karaoke room is a realtime multi-device problem in a way that browsing a media library is not.

When someone adds a song, thirty phones, a host tablet and a TV all need to reflect it within a second or so. That is what Supabase’s realtime Postgres is for. A local SQLite file with polling would work badly at exactly the moment it matters — a full room, everyone queueing at once.

The trade is honest and worth stating: KAPOW! depends on a hosted service where the rest of Coral does not, and it needs an internet connection at the venue. If that is a dealbreaker for your setup, Karaoke Eternal is fully local and a better fit.

KAPOW! vs other self-hosted karaoke systems

The self-hosted karaoke space is small but real, and the existing options solve a meaningfully different problem. Karaoke Eternal and KaraokeParty are built around a local library — your own MP3+G or MP4 files, on your own disk, playing with no internet.

KAPOW! searches YouTube instead. For a bar that means you never have to curate a catalogue in advance and no guest ever hits “we don’t have that song”, which is the failure mode that actually ends a karaoke night. It also means you need connectivity and you are subject to a quota.

Where KAPOW! is distinctive is the social layer on top: collaborative voting, a booth view built for someone running a room professionally, and a comic-book presentation that was designed for a themed bar in Ghent rather than a living room.

The full comparison is in KAPOW! vs Karaoke Eternal. If you want moderated music requests rather than karaoke — guests suggesting tracks, host approving — that is Encore.