HomeTube

A self-hosted web application that pulls internet video onto a home media server. AGPL-3.0, 1.3k stars, 73 forks, 4 open issues as of 2026-08-09, with a claimed 84% test coverage on testable modules. Streamlit front end, Python 3.10+ backend, yt-dlp as the download engine and FFmpeg for processing, shipped as an Alpine-based Docker image on GHCR with both bundled. The output is filed where Jellyfin, Plex or Emby will index it.

What it does

• Downloads from 1800+ sites, which is yt-dlp’s extractor coverage rather than HomeTube’s own.
• SponsorBlock integration strips sponsor segments from YouTube video automatically.
• Codec-aware quality selection — up to two candidate profiles per download, preferring AV1, then VP9, then H.264, with fallback unless the user forces best-quality-only.
• Playlist sync keyed on video ID, so a retitled video is not fetched twice, and removed entries can be moved to an Archives/ folder rather than deleted.
• Filename templating with {idx}, {title}, {channel} placeholders; clipping, subtitle embedding.

The pitch is stated plainly: “No cloud dependencies, everything runs locally.”

The contradiction is in the same README

The autonomy claim and its own refutation sit a few paragraphs apart, and this is the most instructive thing in the source. HomeTube tells the operator that cookies are “increasingly necessary” even for public video, and spells out why: they “access the best quality (AV1/Opus, high-res video, premium audio),” “unlock restricted content,” and “handle encrypted signatures.” The documentation’s own summary is “cookies are not just for private content — they’re the key to consistent, best-quality downloads.”

Read together: no cloud dependency, and also, bring an authenticated session from the cloud service or the tool degrades. What has actually been moved in-house is storage and playback — the library is yours, the player is yours, and nothing phones a vendor to watch what you already have. What has not moved, and cannot, is acquisition. The upstream platform still decides what a given session may fetch, at what quality, and for how long that keeps working.

This is the sharpest instance in the corpus of the pattern self-hosting names: hosting a service yourself relocates the dependency rather than deleting it, and the relocation is easy to mistake for independence. anysoftkeyboard is the contrast case — an offline claim with nothing upstream to depend on — and the difference is not virtue, it is whether the software needs a remote party’s resources to do its job at all.

Fragility worth recording

• The engine is someone else’s arms race. yt-dlp survives by tracking platform changes; encrypted signatures and quality gating are moved against it deliberately. HomeTube inherits both the 1800-site reach and the breakage cycle.
• Cookies are a durable credential in a container. The README recommends supplying them and does not, in what is held here, discuss the handling risk — a session cookie for a personal account, parked in a self-hosted service, is a real secret with no described lifecycle.
• 84% coverage is on “testable modules”, the project’s own qualifier. Untested-by-definition modules are unquantified, and coverage measures execution rather than correctness in any case.
• Legality is not addressed in the material held here, and it varies by jurisdiction and by platform terms. Recorded as absent rather than resolved.

Connections

The corpus’s first true self-hosting case, and one of two (ever-gauzy is the other, at wholly different scale — a media downloader for one household against an ERP for a company). Both are AGPL-3.0, which is becoming a pattern worth watching: the licence that makes a hosted fork give its changes back is the licence self-hosted projects keep choosing.