Cinephage folds the arr stack into one SvelteKit app with a single database

One application standing in for five separate services

The pitch in the README is direct. Cinephage is a single app for a whole media setup, and instead of running multiple services that do not talk to each other, you get one tool that handles everything. The header line names the stack as Node.js 22+, Svelte 5, SQLite and TypeScript.

The list of what it replaces is the clearest statement of scope in the project. Radarr and Sonarr for movie and series management, Prowlarr for indexer management with supported trackers, Bazarr for multi-provider subtitle management, Overseerr for content discovery and smart lists, and FlareSolverr, which it says is replaced by built-in Cloudflare handling so no external service is needed. The README also lists live TV and IPTV management and usenet streaming under an additional features line.

The stated reason for the consolidation is architectural rather than commercial. The README says the arr projects are good at what they do, and that this project took a different path, one unified codebase instead of separate services that need to sync with each other.

That is the whole promise and the whole risk in one sentence. The sync problem disappears when there is nothing to sync, and the blast radius of a failure becomes the entire application rather than one component. The README frames the four properties as one database, one interface, one configuration and one place, covering movies, series, live TV channels, subtitles and indexer configuration in the same store.

The licence is GPL-3.0, with the terms in the `LICENSE` file, and the repository also carries a `THIRD-PARTY-NOTICES.md` file.

SQLite and a SvelteKit server, with a plain Node entry point

The stack is visible in the build files, and it is a good deal more conventional than the feature list suggests.

The package manifest describes an ES module project with a version field that reads `0.0.0-development` in the source tree, and the scripts show the shape of the application. The build is a Vite build with an SSR flag and a raised heap limit, and the production entry point is a plain Node server.

		"start": "node server.js",

There is a `server.js` at the top of the tree, a `svelte.config.js`, a `vite.config.ts` and a `tsconfig.json`, so the server is a SvelteKit application with a custom Node entry point rather than a generated adapter setup. The check script runs `svelte-check` against the TypeScript configuration, and the unit tests run on vitest.

The database is SQLite, stored as `data/cinephage.db` in the source tree, and the manifest has a script that deletes it and prints a message that the database will be recreated on the next startup.

		"db:reset": "rm -f data/cinephage.db && echo 'Database deleted. Will be recreated on next startup.'",

The rest of the script list is a good index of the maintenance work the project expects. There is a script to reset the admin password, one to fix TV subtitle paths, one to repair episode file links, one to backfill release metadata, one to export a release metadata audit, and one to generate language data. A single `db:info` script queries the settings table for a schema version, which is how you check what the database thinks its state is.

That is the practical face of the single-database design. The database is the contract between every feature, and the tooling exists to repair it when a feature changes the shape of a record.

Streaming, usenet and live TV without a download client

The feature list divides into a download path and a streaming path, and the streaming path is where the project departs most from the arr applications it replaces.

The `.strm` route creates text files that point at online sources so that a media server can play them without storing anything, with no disk usage, no waiting and no seeding. The README says it works with Jellyfin, Emby, Kodi or any player that supports `.strm` files. That is the standard mechanism for pointing a library at remote media, and here it is built into the same application that manages the library.

Usenet streaming goes further, playing directly from NZBs without downloading the whole file first, described as a seekable stream implementation with adaptive prefetching and segment caching. Seekability is the hard part here, since a usenet article stream is a sequence of parts rather than a seekable file, and a prefetching layer is what makes seeking tolerable.

Live TV support connects Stalker portals and discovers working MAC addresses automatically, with EPG support, channel management and HLS streaming. The MAC discovery is the piece worth understanding, since portal access is usually tied to a device identifier and the application handles that negotiation rather than asking you to find one by hand.

Discovery and quality come next. Smart lists import from IMDb, Trakt and TMDb lists or run custom queries, with auto-add to the library, and the README's example is adding every 2024 movie rated 7.5 or above automatically. Quality scoring uses more than fifty factors covering codec efficiency such as x265 and AV1, HDR formats, audio quality and release group reputation, and custom formats let you define your own scoring rules.

Deploying with the compose file and an environment file

Docker is the recommended route, and the quick start is short enough to follow exactly.

mkdir cinephage && cd cinephage
curl -O https://raw.githubusercontent.com/MoldyTaint/Cinephage/main/docker-compose.yaml
curl -O https://raw.githubusercontent.com/MoldyTaint/Cinephage/main/.env.example
cp .env.example .env

The compose file pulls a published image and lets you pin a tag.

    image: ghcr.io/moldytaint/cinephage:${IMAGE_TAG:-latest}

The README lists the tag scheme: `latest` for stable, the usual semver forms for a specific version, and `dev` plus a dated `dev-YYYYMMDD-RUN` tag for previews. The compose file maps the container port to the host.

      - '3000:3000'

Cinephage runs on port 3000 by default. The compose file also sets a shared memory size of 256m, and the comment next to it explains why: the headless Firefox used for challenge solving needs more than the container default of 64MB, or it crashes. It also enables `no-new-privileges` and `init`, and mounts three paths, `./config` for persistent data, and your media and download directories.

Two warnings from the README matter operationally. Persistent data lives in `./config` and is created automatically, and you should never mount `/app`, because that directory holds application code. If you later reach the app through a hostname or a reverse proxy, you have to update `BETTER_AUTH_URL` in the environment file to that public URL, or set the External URL in the interface under Settings and System.

Start it and open the port.

docker compose up -d

The setup wizard then walks you through configuration. The stated requirements are a TMDB API key, which is free, and a download client, which is optional because the streaming mode needs no client at all.

Bare metal, the origin variables, and the auth secret

The bare metal path assumes Node.js 22 or newer, npm, git and optionally ffmpeg for media information.

git clone https://github.com/MoldyTaint/Cinephage.git
cd Cinephage
npm ci
npm run build
cp .env.example .env

The environment file then needs at least three values.

BETTER_AUTH_SECRET=<your-secret>
ORIGIN=http://localhost:3000
BETTER_AUTH_URL=http://localhost:3000

The `ORIGIN` variable is the trusted origin for CSRF protection, and the example environment file notes that it is required if you access the app by IP or FQDN rather than through localhost. The `BETTER_AUTH_URL` is the base URL used for callbacks, redirects and auth links, and the example file explains that if it is left unset the application falls back to the External URL saved in Settings and System, and then to localhost for local bootstrap. There is also an optional `BETTER_AUTH_TRUSTED_ORIGINS` for reaching the app through more than one hostname, and a `BETTER_AUTH_DISABLE_SECURE_COOKIES` switch, which the file says should be set only if you terminate HTTPS at a reverse proxy but serve HTTP internally.

The secret matters. The quick start says to generate it with `openssl rand -base64 32`, and the environment file carries a comment that the app key is a fixed value for this app.

Bare metal differs from the container in one documented way, and it is the data location. On bare metal the data lives in `./data` by default and no `/config` mount is needed, while in Docker the persistent data lives in `./config`.

The environment file also documents container-only settings, such as `PUID` and `PGID` for dropping privileges and fixing ownership on mounted volumes, and `HOST`, which binds to all interfaces by default and should be set to `127.0.0.1` behind a reverse proxy on the same machine.

What a single codebase costs you, and what the licence allows

Two things to weigh before committing.

The first is the loss of service boundaries. With separate applications, an indexer outage does not take down your subtitle provider, and each component has its own release cadence. Here, one codebase means one release cadence and one blast radius, and the README is candid that this is a deliberate architectural choice rather than a set of independent tools that happen to share a UI. The offsetting gain is stated just as clearly: no sync issues, and one configuration that applies across movies, series and streaming.

The second is the maturity of the project itself. The version numbers are still in the 0.x range, with v0.15.1 and v0.16.0 both published on 2026-08-08 and v0.17.0 on 2026-09-10, and the last push was on 2026-10-20. The source tree carries a `0.0.0-development` version placeholder, and the release tooling in the repository, with a `.releaserc.json`, a `cliff.toml` for changelog generation and a `renovate.json` for dependency updates, points to a project that ships regularly rather than one that stopped.

The licence is GPL-3.0, and the repository carries a `SECURITY.md` and a `CODE_OF_CONDUCT.md` alongside the contribution guide. GPL-3.0 is a copyleft licence, and it matters for a project that replaces services some people run commercially. Any deployment that ships the application to other users, or that modifies it and hands it on, falls under its terms, and that is a conversation to have before deploying rather than after.

Editorial conclusion

Cinephage fits a self-hoster running a large media library who is tired of keeping several services in sync and wants one database, one interface and one configuration across movies, series, live TV and subtitles. Skip it if you rely on the isolation between separate services, or if you need a proven long-running deployment rather than a fast moving 0.x project. Verify first that your indexers, download client and media server all work through the setup wizard, and that the Docker volume mounts point at your existing library before you import anything.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. MoldyTaint/Cinephage on GitHub
4. README
5. Releases