Materialious puts a Material Design front end on YouTube and Invidious

YouTube on the front, Invidious optional on the back

Materialious describes itself as a modern material design frontend for YouTube and Invidious, focused on a clean, privacy friendly YouTube experience, and it supports local video fallback when Invidious fails. The homepage is materialio.us and the primary language is TypeScript.

The most interesting line in the feature list is that Invidious is optional. The frontend can be used without an Invidious instance, through the project's own YouTube backend, and it also supports an Invidious companion setup and integrates with Invidious subscriptions. Add to that a local video fallback if Invidious fails loading videos, and you have a frontend that is designed to keep working when the instance you depend on does not.

That is a genuinely different design from a typical Invidious frontend, which is a thin client that is only as available as the instance behind it. Materialious is a client that can talk to YouTube directly, to an Invidious instance, or to a mix, with a fallback for local files when neither delivers the video.

The other half of the feature list is the parts people actually wanted from a YouTube client and did not have. There is no ads and no tracking, there are light and dark themes plus custom colour themes, and there is PWA support. There is Android TV support, which is the difference between this being a browser tab and this being a living room client. There is also YT path redirects, and support for disabling certificate validation for homelab users, which is a feature aimed squarely at people running their own services on a local network.

The audience is a self hoster who wants a television friendly YouTube client without the advertisement and tracking surface of the original, and who is willing to run a container for it.

Two Docker deployments that are not the same product

The README documents two container deployments, and the difference between them is the single most important thing to understand before you deploy.

The first is the current one. This version of Materialious is feature rich, has its own account system, which is optional, and is easier to setup. The guide is in docs/DOCKER-FULL.md.

The second is the legacy one, Invidious only. The README says this version is still fully supported, but is purely just an Invidious frontend without any fancy bells and whistles, and that this version is harder to deploy. The guide is in docs/DOCKER.md.

So there is a full deployment with a YouTube backend of its own and an optional account system, and a simpler architecture that is only a client for an Invidious instance you run yourself. The legacy path is harder to deploy precisely because you have to find, run and maintain an Invidious instance, and the full path removes that dependency.

The optional account system is worth understanding on its own, because it is the piece that makes the full deployment a multi user service rather than a personal front end. It is an internal account system, and it is optional, which means the deployment works for a single person with no accounts at all.

What the accounts add is syncing. History and watch progress are synced, and you can sync your watch progress between Invidious sessions, so moving from one Invidious instance to another does not lose your place. Subscriptions can be imported and exported, with automatic Invidious and Materialious import and export, which is the practical way to move a subscription list from an existing Invidious setup into the new one.

And the subscriptions themselves are end to end encrypted, with a proof of work captcha based on the altcha project. That is a meaningful design choice: the account system does not need to read your subscription list to serve it, which is the difference between a self hosted YouTube client and a convenience wrapper.

SponsorBlock, Return YouTube Dislike and DeArrow are in the box

Three of the most requested features of any alternative YouTube client are built in rather than bolted on.

SponsorBlock is built in, which is the project that marks segments of a video as a sponsor, a self promotion or an interaction and skips them. Return YouTube Dislike is built in, which restores the dislike count that YouTube removed and which the community maintains as its own estimate. DeArrow is built in, which replaces thumbnail images with ones that are less clickbait, by re-embedding a cropped frame of the video instead.

Each of these is a separate project with its own upstream, and all three are included rather than requiring you to install an extension. That is the difference between a browser extension and a client: in the extension case, you need the extension, and on a television there is no extension to install.

The player side is smaller but relevant for a living room use case. There are chapters, a mini player in picture in picture mode, and playlists.

And the account system has a proof of work captcha, using the altcha project, which is a deliberate choice: it means a self hosted service that registers accounts does not have to embed a third party captcha service, and the work factor is something the browser does rather than something you pay for per request.

Six ways to install it, from Flatpak to a deb

The installation table in the readme is the widest in any project of this kind, and it is worth reading because each target is a different commitment.

On Windows there is a single installer executable, Materialious-win32-x64.exe, linked from the latest release. On macOS there is a universal dmg covering x64 and arm64. On Android the same signed universal APK is available from GitHub, through Obtainium, on F-Droid and on IzzyOnDroid, and for Android TV the readme points at APKUpdater rather than shipping a separate TV build. The app also exists on F-Droid under the package id us.materialio.app, and there is a Matrix room badge, so the community is not only on Discord.

For Linux there are four routes. Flatpak is a single command, flatpak install flathub us.materialio.Materialious. The AppImage is a single downloadable file. The Debian and Ubuntu route is a .deb, and the readme gives the install line explicitly:

sudo apt install ./Materialious-linux-amd64.deb

And Fedora and openSUSE get an rpm. There is also a PWA route for the web deployment, since the PWA support means the container deployment can be installed to a home screen on a device that has no native build for it.

The repository shows how the Android side is handled. There is a fastlane directory, which is the standard tool for automating Android release builds and for the Play Store listing, and an update_versions.py script at the root, which is the kind of small utility that exists because keeping version numbers in several places in sync is otherwise a manual chore. There is also an unraid directory, for the people who run Unraid as a NAS operating system.

The privacy story has one deliberate exception

The Platform and Privacy section is short, and one entry in it deserves more attention than the others.

The entries are: no ads, no tracking, light and dark themes, custom colour themes, PWA support, YT path redirects, Android TV support, and support for disabling certificate validation for homelab users.

The last one is the exception, and the reason it exists is worth being explicit about. A homelab user running a service on a local network with a self signed certificate, or behind a proxy that re-signs traffic, needs the client to accept it. Disabling certificate validation is exactly the kind of switch that weakens the security of every other connection the app makes, so it is the right thing for the project to make it explicit and named rather than to hide, and the right thing for a reader to enable only for the instance that needs it.

The privacy claims themselves are narrow claims. No ads and no tracking mean the client does not run the advertising and measurement machinery that the original site does. They do not mean the client is anonymous, since it is talking to YouTube through a backend, and in the Invidious-only deployment it is talking to an Invidious instance, and either way requests reach someone. The end to end encryption claim is scoped to subscriptions, and that scoping is the point: the subscription list is the data the account system holds.

For a reader deciding whether to trust this deployment, the honest summary is that Materialious removes the client side advertising and tracking surface and keeps your subscription list encrypted on the server, and that everything else depends on the YouTube backend or the Invidious instance you point it at.

Releases every few days, and a licence that has consequences

The release history shows a project shipping continuously. Version 1.18.7 on 2026-09-17, 1.18.8 on 2026-10-03 and 1.18.9 on 2026-10-07, with the repository pushed to on 2026-10-11.

That cadence is typical of an application that has to keep pace with a moving upstream, because YouTube changes and a frontend for it has to change too. It also means the question of how you take updates is a real one. The readme lists the F-Droid, Obtainium, IzzyOnDroid and Flathub channels alongside direct downloads, and those channels handle updates for you with a lag, while the direct release assets are the newest thing available.

The licence is AGPL-3.0, and that is a deliberate choice with real consequences. The AGPL is the strongest of the common open source licences for network software, and the clause that matters here is the one about conveying modified versions over a network: if you run a modified Materialious and let other people use it, the source of your modifications has to be offered. For a self hosted service that only you use, that is not a constraint. For a homelab that a few friends connect to, or for anyone who plans to fork it and keep running a public instance, it is the thing to think about before deploying.

The repository also carries a CODE_OF_CONDUCT.md and a docs directory, and the two Docker guides are separate documents rather than one, which is a small sign of how much the deployment story has diverged over time.

So the practical evaluation is a short one. The feature set is genuinely ahead of a typical Invidious frontend, the two deployment paths cover both the simple and the complete case, and the licence is the part of the decision that needs a legal opinion rather than a preference.

Editorial conclusion

Materialious is worth adopting if you want a YouTube client you host yourself, on a television or a phone, with the privacy oriented integrations switched on and without depending on somebody else's Invidious instance, because the full Docker deployment gives you a YouTube backend of its own and the legacy one keeps the Invidious path available. It is the wrong choice if you want a maintained fork of the YouTube web client rather than a third party frontend, and it is the wrong choice if you cannot host a service at all. Before you deploy, read docs/DOCKER-FULL.md rather than docs/DOCKER.md, because they are different products, and note that the licence is AGPL-3.0, the newest release is 1.18.9 from 2026-10-07 and the last push was on 2026-10-11.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Materialious/Materialious on GitHub
3. Project website
4. README
5. Releases