OuonnkiTV: a self hosted search and playback frontend for video sources you configure

What the project is, and what it explicitly is not

OuonnkiTV is described as a modern video aggregation search and playback frontend, built on top of LibreTV, and the repository is set up for one click deployment to Vercel. The feature line in the README is a list of capabilities: aggregated search, smooth playback, TMDB intelligent matching, favourites management, video source subscription, watch history, responsive design, high performance, multi device support and a good interface. The disclaimer section, however, is the most defining part of the project and is worth reading before the feature list. It says the project is open source source code for a video search aggregation front end, that it only provides code implementing the display and playback of search results, and that it does not provide any directly usable finished software, online service or hosting platform, so the user has to obtain the source and deploy it themselves. It states that the project does not provide, host, upload, store, distribute or cache any video, audio, images or other copyrighted content, that the source code contains no video source addresses or content data, and that all search results and playback content come from third party video source APIs that the user configures, with the developers accepting no responsibility for the legality, availability, security or content quality of those third party services.

Six deployment routes, one set of environment variables

Deployment is the first thing the README teaches, and it offers a Vercel button with the build command, the install command and the output directory filled in, plus a documentation file with guides for Docker, Vercel, Cloudflare, Netlify, local development and update syncing. The other documentation covers configuration management with environment variables and TMDB configuration and full configuration import, how to request a TMDB key, how to import video sources including the JSON format, and a developer guide covering the tech stack, the project structure, the proxy architecture and the `@ouonnki/cms-core` package. The environment variable set is where the behaviour lives. `OKI_INITIAL_VIDEO_SOURCES` seeds the source list and accepts three shapes, a single line JSON, a multiline JSON, or a remote JSON file URL, with an empty value meaning nothing is preconfigured and the user adds sources in the app. `OKI_TMDB_API_TOKEN` is a TMDB read access token using v4 auth. `OKI_TMDB_API_BASE_URL` and `OKI_TMDB_IMAGE_BASE_URL` override the official TMDB endpoints, with the examples showing relative paths such as `/tmdb-api` and `/tmdb-image`, which is the hint that a self hosted instance can proxy TMDB rather than calling it directly.

Why there is a proxy in the Docker image

The Docker image is not just nginx serving static files, and the reason shows in the runtime stage. The production image is based on node:20-alpine, installs nginx and supervisor, and copies in a `proxy-server.js` file along with a `shared/` directory and a runtime configuration generator script, and it installs only the dependencies the proxy needs, which are express and cors, installed with npm rather than pnpm so that pnpm is not needed at runtime. The proxy exists because the browser has to reach the third party source APIs and the TMDB endpoints, and a self hosted instance usually needs a same origin path for those requests, both to avoid cross origin problems and to keep the base URL configuration working with relative paths. There is also a `functions/` directory and an `api/` directory at the repository root, which is the shape of a project that has to serve both static hosts and a Node runtime, and the Vercel configuration file sits alongside a Netlify one and a nginx configuration. The `cors` dependency in the proxy is the visible acknowledgement that this is the layer responsible for making cross origin calls work.

The container, and how it is expected to behave

The Dockerfile is a conventional multi stage build. The builder stage is node:20-alpine, installs pnpm at a pinned version, copies the workspace manifests and the lockfile and the `.npmrc` before installing, with a comment explaining why, since for a pnpm workspace the workspace manifests have to be present before the install or the sub package dependencies are missed, and the install uses `--frozen-lockfile` so the build matches the lockfile exactly. The production stage labels the image with the usual OpenContainers metadata, title, description, version, created date, revision and source, sets the analytics opt out by default, and wires nginx and supervisor together. The compose file exposes port 3000 on the host to port 80 in the container, sets the environment variables with defaults, restarts unless stopped, rotates logs with a 10 megabyte limit and three files, limits resources to 512 megabytes of memory and one CPU, and defines a health check that runs wget as a spider against the local server every 30 seconds with a 40 second start period. Those numbers are the practical ones, since a container that renders a video frontend on a small VPS is usually memory bound.

The front end stack, and the workspace layout

The application is a React front end built with Vite and Tailwind, with a large set of Radix UI primitives, drag and drop handling from the dnd-kit packages, the artplayer component for video, embla for carousels, Phosphor icons, the Inter font package, dayjs for dates, class variance authority and clsx for styling helpers, and Vercel analytics with speed insights. The manifest pins the toolchain, with Node 20 or later required and pnpm 10.15.1 as the package manager, and the scripts are the familiar ones, a dev server on the host network, a build that runs the TypeScript project build and then vite build, tests with vitest, linting with eslint, and a set of docker compose scripts for build, up, down and logs. The repository is a pnpm workspace with a `packages/` directory, and the workspace dependency `@ouonnki/cms-core` is built first by a prebuild step, which is why the Docker builder copies the workspace manifests and the sub package manifest before installing. The `shared/` directory holds code shared between the front end and the proxy, and there is a `scripts/` directory with the runtime configuration generator.

The disclaimer, the licence and what a self hosted instance owes you

The closing paragraphs of the README set out the rules for anyone who deploys it. The user is expected to comply with the laws of their own country or region, to bear the full legal responsibility for deploying, configuring and using third party video sources, to respect the intellectual property rights of content creators, not to use the source code for anything unlawful, infringing or commercially infringing, and to take full responsibility for their own deployed instance and everything it does. If infringing content is found, the README says to contact the original content provider, that is the third party source operator, because the developers only provide source code and have no ability or obligation to review, monitor, delete or control instances or third party content. The source is provided as is, without warranties including merchantability, fitness for a particular purpose and non infringement, and the developers keep the right to modify, suspend or end the project at any time without notice. The licence itself is Apache 2.0, and contributions are invited through issues and pull requests. The last push was on 2026-08-17 and the repository publishes no GitHub releases, so there is no version history to consult.

Editorial conclusion

Adopt OuonnkiTV if you want a personal, self hosted front end over video source APIs you control, and you are comfortable configuring endpoints, a TMDB token and an optional access password. Do not adopt it expecting a hosted service, since the README states the project provides no finished software, no online service and no hosting, and the developer reserves the right to suspend or end the project at any time. Before you deploy, decide what your sources are and where they are reached from, because the API base URL and image base URL settings exist so the frontend can talk to a proxy you control, and set `OKI_ACCESS_PASSWORD` if the instance should not be public. The licence is Apache-2.0, the last push was on 2026-08-17, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Ouonnki/OuonnkiTV on GitHub
4. Project website
5. README