Case Study
Watch your subscriptions privately without touching Google
YouTube knows a lot about you. This is a self-hosted frontend where the server proxies every stream, thumbnail, and piece of metadata. The browser never makes a single request to Google. No account, no tracking, no algorithm. Just a chronological feed of channels I chose.
Every screenshot below is a live capture from a running instance with imported subscriptions, real feed, and real playback.
Walkthrough
The Today page lists new videos from subscribed channels in plain chronological order. Durations, titles, and thumbnails are all served through the proxy. Subscriptions come in via OPML/CSV import or straight from your browser session, so leaving YouTube proper is a five-minute move, not a fresh start.
The watch page shows the hard part working: the server extracts the stream (the badge in the header reads "innertube/dash, 0.78s"), and Shaka Player plays adaptive DASH through the proxy with a progressive MP4 fallback. Metadata, subscriber counts, and comments all arrive server-side. This frame was captured mid-playback.
The import surface handles the messy reality of leaving a platform: fetch subscriptions from your logged-in browser, upload a cookies.txt, import OPML/CSV, and refresh extraction cookies when YouTube’s bot detection bites. Operational edge cases are treated as first-class UI, not error messages.
Swappable by design
The premise is privacy: the server proxies every stream, thumbnail, and byte of metadata, so the browser never makes a request to Google. The hard part is extraction — pulling a playable stream server-side and handing it to the player through the proxy — and that is where most of the engineering went.
Everything beyond Node is optional and chosen by an environment variable, not baked in. The store is SQLite by default or PostgreSQL; downloads live on local disk or any S3-compatible bucket; extraction runs in-process or on a Redis/BullMQ queue with worker replicas. One code path serves a single laptop process and a clustered deployment.
And it is built to actually run somewhere. Playwright suites cover the end-to-end flows, the player, and resilience — the failure paths, not just the happy ones — and the repo ships a real deploy tree: Dockerfile, nginx, Terraform, Ansible, systemd units, and a Varnish cache. It reads like something meant to be operated, not just demoed.
In the repo
extractors.tsThe proxy’s hard part: extracting a playable stream server-side, with fallback backends, so the browser never calls Google.db.tsThe data store behind one interface — SQLite by default, PostgreSQL (db-pg.ts) via a single env var.lib/storage.tsDownloads on local disk by default, or any S3-compatible bucket when STORAGE_URL is set — one abstraction, two backends.extraction-worker.tsExtraction runs in-process, or on a Redis/BullMQ queue with worker replicas when you scale out.cluster.tsThe single-process-to-clustered switch: the same code path runs on a laptop or across worker replicas.deploy/Infrastructure as code: Terraform, Ansible, systemd units, and a Varnish config — a real deploy path, not a toy.tests/resilience.test.mjsPart of the Playwright coverage: e2e, the player, and resilience — the failure paths get exercised, not just the happy ones.How it's built