AuroraHigh-end cinematic Jellyfin frontend

Install with Docker Compose

Aurora ships as a single container that listens on port 3000. This service definition assumes Jellyfin is on the same Compose network under the hostname jellyfin:

services:
  aurora:
    image: getcoral/aurora:latest
    restart: unless-stopped
    depends_on: [jellyfin]
    ports:
      - "3000:3000"
    environment:
      AURORA_DATA_DIR: /data
      JELLYFIN_URL: http://jellyfin:8096
      JELLYFIN_API_KEY: ${JELLYFIN_API_KEY}
      JELLYFIN_USER_ID: ${JELLYFIN_USER_ID}
      JELLYFIN_USERNAME: ${JELLYFIN_USERNAME}
      JELLYFIN_PASSWORD: ${JELLYFIN_PASSWORD}
    volumes:
      - ./aurora-data:/data
    networks: [coral]
    healthcheck:
      test: ["CMD", "node", "-e", "fetch('http://127.0.0.1:3000/healthz').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 20s

JELLYFIN_USER_ID is the user’s UUID, not their username — you can read it out of the URL when you open that user in the Jellyfin dashboard. The API key alone is enough to browse the library; adding the username and password is what lets Aurora open a real playback session so watch progress syncs back.

If you would rather not put anything in a .env file, every one of those variables is optional. Start the container with no configuration at all and Aurora will walk you through connecting to Jellyfin on first run, storing the result in /data/aurora.sqlite:

docker run -d -p 3000:3000 -v aurora-data:/data getcoral/aurora:latest

For the full stack — Jellyfin, Aurora, Tide and Librarian in one file — see the Jellyfin Docker Compose stack guide.

How Aurora fits alongside Jellyfin

Aurora deliberately does not own any state that Jellyfin already owns. It has no user database, no separate watch history and no second metadata store. Everything it displays is fetched from the Jellyfin API at request time, and everything you do in it — marking a favorite, resuming an episode, finishing a film — is written straight back.

The practical consequence is that Aurora is safe to try and safe to delete. It sits beside the official web client rather than replacing it, so you can run both on different ports and let people in the house pick. If you decide Aurora is not for you, stopping the container leaves no trace on the server.

The one piece of state Aurora does keep is its own: the Jellyfin connection details, and any UI preferences, in a SQLite file under AURORA_DATA_DIR. Mount that directory if you want the setup to survive a container rebuild.

Aurora vs the default Jellyfin web client

The stock Jellyfin web interface is built to be a complete administrative surface. It exposes the dashboard, library management, user settings, plugin configuration and playback in one app, and the design reflects that breadth. Aurora makes the opposite trade: it is a consumption client only. There is no dashboard, no library editing and no server administration in it at all — for those you open Jellyfin.

What you get in exchange is a browsing experience built for a sofa and a large screen: full-bleed backdrops, rails for continue-watching and recommendations, detail pages with cast and related titles, and transitions that hold up on a TV browser. If what bothers you about Jellyfin is the interface rather than the server, that is precisely the part Aurora replaces.

The honest counterpoint: the official client is feature-complete, has years of bug reports behind it, and supports Live TV, SyncPlay and the full plugin surface. Aurora is marked In Progress for a reason, and it covers the browse-and-play path rather than every corner of Jellyfin. Running both costs one extra container.

A fuller breakdown lives in Aurora vs the Jellyfin web client.