Playlet: an unofficial, ad-free YouTube client for Roku

A BrightScript YouTube client built for the television

Playlet is an unofficial YouTube client for Roku, written in BrighterScript, the transpiled dialect of BrightScript that Roku developers use. The project description calls it an unofficial, privacy driven YouTube client for Roku, and the repository topics list the technology in plain terms: brighterscript, roku, roku-tv, innertube, invidious, sponsorblock, adblock and privacy.

What the client does is straightforward once you understand the division of labour. Playlet is a frontend. It does not host video, and the disclaimer in the README is explicit that it does not serve or distribute material from unauthorized sources. It talks to YouTube through the same InnerTube interface the official clients use, or to an Invidious instance, and it renders the result on a television. The README's own framing of the project is that it brings the watching experience to the TV, where the existing frontends are web and mobile focused.

The feature list is short enough to read as a design statement: no ads, no tracking, a privacy driven mode that can use an Invidious backend, sign-in with either YouTube or Invidious accounts, SponsorBlock integration that skips sponsored sections in videos, browsing, searching and casting from a phone, picture-in-picture mode, and translation through Weblate. The speed claim is comparatively modest in tone, with a link to a video comparing the app against the official YouTube application rather than a number in the text.

The project is licensed under AGPL-3.0, which is a deliberate choice for a client that people are likely to fork, and that licence has consequences discussed further down.

Two backends: YouTube directly or an Invidious instance

The backend choice is the mechanism that makes the privacy claim work, and the README presents it as a feature in its own right rather than a hidden setting.

With the YouTube backend, the app signs in with a YouTube account and talks to YouTube's own InnerTube API, which is what the official apps do. The client library in the package manifest is youtubei.js, at version 18.1.0 or newer, which is the Node library that implements that interface, and the InnerTube topic tag in the repository reflects the same thing.

With the Invidious backend, the app talks to an Invidious instance instead. Invidious is a third-party front end for YouTube that the README links to, and pointing Playlet at one of those instances is the privacy-driven path, since the traffic goes to a server that is not Google and is operated by someone other than the app author.

The consequence of that design is dependency, and the README is unusually candid about it. Playlet could run on a variety of devices with different capabilities and screen sizes and different Invidious instances, in addition to the experimentation YouTube does based on the account or the IP address, and the project collects diagnostics partly to understand those variations. In other words, the behaviour you get depends on a third party, and the author knows it.

The SponsorBlock integration works the same way, as a service call to the SponsorBlock instance rather than a local filter, and the same applies to the account sign-in, which is a genuine privacy trade the user makes explicitly.

Installing from the channel store, or sideloading the app

The normal installation route is the Roku channel store. The README links the Playlet listing there and says to search for Playlet in the channel store on the device. That path matters more than it might seem, because the repository also publishes a canary build and tagged releases, and the store listing is how a user gets the maintainer's packaged channel rather than a copy of unknown provenance.

For devices where the store route does not work, the README points to a discussion thread with instructions for installing Playlet as a sideloaded or development app. That is the standard Roku developer route, which means putting the device into developer mode and loading a signed package, and it is documented outside the repository proper, in the discussions area.

The project publishes package artifacts alongside the releases. The release workflow in the repository is referenced by a build status badge, and the releases include a packaged image for the device, with the downloads badge pointing at the latest package file. The canary tag is updated on every push to the default branch, while the numbered releases such as v0.48.10 and v0.48.9 mark the stable line, so the distinction between a canary and a release is part of the release naming rather than a separate channel.

Casting from a phone without a companion app

The phone casting feature is the part that makes Playlet more than a player on the television, and the README describes three ways to pair.

The first is the Remote tab inside Playlet, which shows a QR code to scan with the phone, after which the browser on the phone takes over for browsing and searching. The second is to use the YouTube app on the phone, connecting over the same Wi-Fi network. The third is a code based route, with a Link with TV code option in the same remote tab.

The design goal is visible in the feature list: browse, search and cast from a phone using the YouTube app or the browser. The phone is a remote control and a discovery surface, and the television does the playing, including in picture-in-picture mode.

For a reader weighing this against other options, that is the actual difference from the web frontends. Those work on the phone, and a Roku browser or a cast target can be pointed at them, but the experience of a television-native interface with its own large-font layout, picture-in-picture and the account sign-in is what the Roku app provides.

Telemetry: collected by default, switchable in the settings

The analytics section of the README is short and deserves a careful reading. Roku itself collects usage data, and the data made available to Playlet is described in the project wiki. On top of that, Playlet collects telemetry and diagnostics data, and the stated reason is to capture issues and fix them, given the number of device, screen size and Invidious instance combinations the app has to cope with.

Two things follow from that. The collection can be turned off in the settings, so the default is on and the privacy-minded user has to act. And the README asks users to report issues anyway, on the grounds that a report is more useful to the maintainer than an anonymous trace.

There is a PRIVACY.md file in the repository root next to the README and the licence, which is where the specifics are expected to be, and the wiki entry is described as the place to find what Roku makes available. A reader deciding whether to trust the client with a signed-in account should read those two before installing rather than after.

The tension with the no-tracking claim is real but narrow. The ad-free and tracker-free claims are about what YouTube and the ad networks do to a viewer. The diagnostics are about the client itself, sent from the user's own device, and they are optional once switched off.

The developer toolchain behind the app

The repository is a Node monorepo for a Roku application, and the manifest shows the stack in detail. The main packages are playlet-app, which is the Roku channel itself, playlet-lib, the shared library, and playlet-web, the companion web side used for the phone casting flow, plus a playground directory and an integration-tests directory.

The Roku-specific tools are the interesting part. brighterscript is pinned at 0.73.7 and is the language the app is written in, bslint from the Roku community is the linter, roku-deploy handles pushing the channel to a device, rooibos-roku at 5.17.0 is the test framework for BrightScript, and roku-test-automation drives end-to-end tests. The engines field requires Node 22.

The build scripts in the manifest show the shape of the pipeline. There is a prebuild step that clears the dist directory with node tools/rm.js dist, and separate production and development builds for the web, library and app packages. The release script chains the prebuild, a format fix, a lint fix, a version sync, a manifest git hash step and the production build, which is a sensible way to make sure the shipped channel carries the commit it was built from.

A single version number, 0.48.10 in the manifest, is shared by all of it, and a version-sync script in the release chain exists to keep that consistent across the packages. The release script in the manifest looks like this:

"build:release": "npm run prebuild && npm run format:fix && npm run lint:fix && npm run version-sync && npm run manifest-git-hash && npm run build:prod",

AGPL, the trademark note and the release cadence

The licence is AGPL-3.0, and for a client that many people will want to modify and redistribute on their own devices, that is a meaningful choice rather than a default. The AGPL is the copyleft licence designed for network services, and it requires that modified versions offered over a network carry the corresponding source. The practical reading for a Roku user is that a modified channel is expected to be shared back, and for a fork of the project the same obligation applies to the modifications.

The trademark note in the disclaimer is standard but worth stating, because the project sits close to a trademark line. The authors acknowledge that the trademarks mentioned in the repository and on related pages belong to their respective owners, and that the use of these names is for identification only and implies no endorsement, affiliation or sponsorship.

The release rhythm is fast, and the tag names show two tracks. The canary build was published on 2026-10-19, the same day as the last push, alongside v0.48.10 on 2026-10-17 and v0.48.9 on 2026-10-14. The numbering has not moved past 0.48, so the project is pre-1.0, and the CHANGELOG.md file at the root is where the detail of each change lives.

Translations are handled through Weblate, with the hosted project linked from the README, so the interface is translated by contributors rather than by the author, which is also the mechanism that keeps the localisation work out of the main development loop.

Editorial conclusion

Adopt Playlet if you watch YouTube on a Roku television, dislike the advertising on the official app, and are willing to sideload a third-party channel and turn off the diagnostics it collects by default. Do not adopt it if your only screen is a browser or a phone, since the project exists to fill a gap those frontends already cover. Before installing, read the telemetry section of the README and the linked wiki entry, because usage data is collected unless you disable it in the settings, and check the channel store listing rather than a sideloaded copy so you receive the canary and release builds the maintainer publishes.

Frequently asked questions

Official sources

1. iBicha/playlet on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases