Invidious replaces YouTube's interface, not its video source
Invidious presents YouTube videos through its own web interface. Users get subscriptions independent of Google, notification feeds, audio-only playback, themes, history and subscription import, embeds, and a developer API. JavaScript is optional for basic use. The service does not use the official YouTube API, which frees it from an API key but ties its behavior to interfaces that YouTube can change without supporting third-party clients.
That distinction determines who should run it. A household or community can keep account data on its own instance and offer a calmer viewing interface. The same operator then owns breakage when upstream responses or player rules move. GitHub listed 477 combined open issues and pull requests when we checked. One current bug reports a missing commentsEnabled key, while another reports empty description fields in API search results. Neither issue means every request fails, but both concern live data parsing.
The production path is a 3-service deployment
The official Compose example runs Invidious, Invidious Companion, and PostgreSQL 14. Invidious handles the web application, PostgreSQL stores user and application data, and Companion supports playback work that older helper services used to perform. Operators generate separate secrets for the HMAC setting and Companion communication. The docs explicitly warn against reusing the same value. A reverse proxy normally provides the public HTTPS endpoint.
Hardware guidance is candid. The installation page asks for at least 20 GB of disk and 2 GB of free RAM for a private setup, with regular restarts. A public instance is described with 60 GB of disk, 4 GB of RAM, 2 virtual CPUs, a 200 Mbps connection, and about 20 TB of traffic or no cap. Those are project recommendations, not numbers from our performance lab, but they rule out many bargain hosting plans.
What happened when we ran it
Our sandbox installed 35 Python packages in 19 seconds, occupying 37 MB on disk. The build completed successfully in 8 seconds. The measured checkout at commit 34173a3 had 381 files, roughly 3,287 source lines, and used 10.2 MB before dependencies. Pip-audit found 0 known vulnerabilities in the environment produced by that run.
Tests did not pass. Pytest exited with code 5 after 11 seconds because it collected 0 tests, reporting no tests ran in 0.05s. That is different from a suite with zero failures: no test exercised the application. The scan found a tests directory and 6 CI workflow files, plus a Compose file but no Dockerfile. We do not know from the log why collection returned nothing, so we are not assigning a cause.
The measurement also deserves a scope warning. Our harness classified that checkout as Python, while the current repository and official manual installation describe the application as Crystal. The current docs list Crystal 1.14.x through 1.19.x and a set of native Linux packages. Our 19-second dependency result does not measure that manual production stack, its PostgreSQL migration, Companion, video playback, or response to live YouTube traffic.
Frequent restarts are part of the documented operation
The post-install guide says Invidious must be restarted often, at least once a day and ideally every hour. It also asks public instances to enable PubSub feeds and an InnerTube caption setting, then configure the domain, external port, and HTTPS flag behind a proxy. That is unusually direct operational advice. It should enter the deployment design as a service policy, with health checks and controlled restarts, rather than remain a note someone discovers after an outage.
Unsupported hosting is another firm boundary. The docs warn that PaaS and SaaS products may have trouble with a bandwidth-intensive proxy and might suspend the account for abuse. Windows is not a supported native Crystal route; Docker Desktop or WSL is the practical choice. The Compose image comes from Quay, and the repository must currently be cloned because SQL initialization files are mounted into PostgreSQL. The guide says removing that cloning requirement is a hope for the future, not a delivered feature.
Privacy gains still depend on the instance operator
The README promises no ads or tracking in Invidious itself and supports subscriptions without Google. A public instance, however, is run by somebody else. Its administrator controls logs, retention, domain security, updates, and database access. Privacy-sensitive users should read an instance's policy or run their own. Import and export support makes moving subscriptions and user data easier, but it does not certify the host.
The AGPL-3.0 license is relevant for modified network deployments because it requires corresponding source availability under its terms. Teams embedding Invidious into another service should review that obligation instead of treating it like a permissive library. The README also asks users to follow local rules and rejects responsibility for illegal downloading. Invidious changes the interface and account relationship; it does not change rights attached to the videos.
August 2026 activity shows an actively repaired service
The repository was pushed on August 23, 2026, and release v2.20260804.1 arrived on August 5. That patch restored debug information in container images after a build regression, specifically to improve stack traces and crash diagnosis. GitHub showed 22,824 stars. The recent push, release, translation work, and active parser issues together describe a maintained project under continuous upstream pressure, not a finished appliance.
For a shared browser-based alternative, Invidious remains the most recognizable choice here. Its features are useful and its operator documentation does not hide the costs. Adopt it with monitored restarts, pinned images, backups, secrets, and enough bandwidth. If only one person needs private viewing, a local FreeTube or NewPipe installation removes PostgreSQL, Companion, proxy configuration, and the public-instance trust question.