The Pinchflat-ngx fork picks up the YouTube manager its maintainer left behind

Friday, 2 October 2026. The selfh.st newsletter flagged that a “wild” fork has appeared around Pinchflat, the self-hosted YouTube media manager: Pinchflat-ngx, run by a developer under the handle TheBadFella, shows 808 commits and 139 stars. Ten months of silence. The original project, kieraneglin/pinchflat, has seen no activity for about ten months. A continuity plan. The fork is not a copy: it adds PostgreSQL 18, OIDC authentication, disk staging for NAS boxes, and a PO-token provider against YouTube blocking.

What happened: a dormant project, a fork in 808 commits

Pinchflat is a YouTube download manager built in Elixir/Phoenix LiveView, relying on yt-dlp to fetch channels, playlists and podcasts and file them into a media library, with SponsorBlock and retention profiles. It is one of the reference apps for archiving your YouTube subscriptions on your own server — a job that demands constant attention, because YouTube keeps evolving its anti-automation protections.

When a sole maintainer stops, that attention stops with them. selfh.st notes the original repository has not moved in about ten months; for an app whose survival depends on continuously updating yt-dlp and its workarounds, ten months is an eternity. The Pinchflat-ngx fork is the classic self-hosted answer to that void: take the code, keep maintaining it, and use the opportunity to modernise what the original left unfinished.

What the fork actually changes

The comparison the fork’s README provides comes down to five differences, all aimed at real homelab use.

• PostgreSQL 18, optional. The latest image keeps SQLite; a latest-postgres image adds PostgreSQL 18 for those who want a shared database and built-in pg_dump backups.
• OIDC / SSO. On top of HTTP Basic Auth, the fork supports OAuth2/OpenID Connect — Authentik, Authelia and the like — with provider discovery, PKCE and state/nonce validation.
• Local disk staging. The DOWNLOAD_STAGING_PATH variable lands downloads on a fast local disk before an atomic transfer to the library, avoiding direct writes to a slow NFS share or NAS.
• PO-token provider. An integration with the bgutil-ytdlp-pot-provider service works around YouTube SABR blocking when the instance hits authentication errors.
• Single-video downloads. Where the original only handled channels and playlists, the fork accepts the URL of a one-off video.

Comfort features round this out: cookie management from the UI, control over the yt-dlp version (stable, nightly, pinned), queue diagnostics, separate concurrency limits for download, indexing and metadata workers, and a Material 3 interface in AMOLED dark mode.

The migration: what is compatible, what is not

The decisive point for an existing Pinchflat user is database compatibility. The fork’s latest image stays on SQLite: it keeps the original’s format, which makes the switch low-risk — you swap the container image, keep the config and downloads volumes, and the app comes back up.

The PostgreSQL path is another story. The README is explicit: the latest-postgres image “creates and migrates its own schema, but it does not copy data from an existing SQLite database”. In other words, moving to PostgreSQL is not an upgrade, it is a reinstall — a new database, re-indexed sources, re-configured profiles. The fork documents pg_dump backups with retention once you are there, but the initial switch is manual, and a PostgreSQL 16 or earlier volume is not compatible as-is with the 18 server.

services:
  pinchflat-ngx:
    image: ghcr.io/thebadfella/pinchflat-ngx:latest
    environment:
      TZ: Europe/London
    ports:
      - '8945:8945'
    volumes:
      - ./config:/config
      - ./downloads:/downloads
    restart: unless-stopped

That is the starting deployment for someone coming from Pinchflat: same port 8945, same volumes, image swapped. For OIDC with Authentik or Authelia, the fork notes that OIDC replaces HTTP Basic Auth on browser routes, while podcast feed endpoints keep Basic Auth and route tokens so existing clients do not break.

The deeper issue: the fork as a continuity plan

The Pinchflat-ngx story goes beyond one YouTube tool. It illustrates the structural risk of single-maintainer self-hosted software: an app’s value is not only in its code but in the ongoing attention it requires — here, the arms race against YouTube protections. When that attention stops, the app does not “break” all at once; it degrades silently, until the day yt-dlp no longer gets past a new mechanism.

A fork is then less a rebellion than a survival mechanism of the model: someone picks up the maintenance burden and, along the way, fixes the blind spots the original carried — no SSO, a single-file database, direct writes to the NAS. The question a self-hoster should ask is therefore not “should I switch to the fork?” but “how much do I depend on a single maintainer, and what do I do if they disappear?”

Verdict

If you already run Pinchflat and it works, switch to Pinchflat-ngx’s latest image: same SQLite database, same port, same volumes, and you gain an actively maintained project without reinstalling. If you want PostgreSQL, OIDC or disk staging, treat the move to latest-postgres as a new deployment — new database, re-indexing — and schedule time to reconfigure profiles and sources, rather than hoping for a seamless switch. If you are still weighing the principle, remember the real cost of a fork is not technical but trust: check the repository’s activity, the commit history, and the existence of a path back to the original before handing your archive to a project run by one person. For a tool whose raw material is your YouTube library, maintenance continuity matters more than feature novelty.

References

• selfh.st — Self-Host Weekly (2 October 2026)
• GitHub — TheBadFella/Pinchflat-NGX
• GitHub — kieraneglin/pinchflat (upstream project)