Invidious

Last reviewed Sep 13, 2026 · 806 words

Budget for an Invidious instance that stops playing video roughly once a month and needs an update or a restart to recover. That is not a criticism of the project, which at 24,169 stars is the most complete alternative YouTube front-end there is; it is the cost of building on a platform that actively works to stop you. If you go in expecting a set-and-forget service, you will abandon it within a quarter. If you go in expecting to run git pull on a schedule, it delivers something no browser extension can: subscriptions, playlists, RSS feeds, and playback with no Google account, no ads, and no tracking, from a process that idles at about 50 MB.

Why it breaks, and why it keeps getting fixed

Invidious fetches video metadata and stream URLs from YouTube's internal endpoints rather than the official API, which is what lets it work without a key and without quota. YouTube changes those endpoints, adds bot checks, and rate-limits datacentre IP ranges, and each change lands in the Invidious issue tracker within hours. The project's answer has been to split the fragile part out: a companion service now handles the stream-fetching and token dance, so the main server survives most changes and the companion gets patched. A Crystal codebase also means fewer drive-by contributors than a Go or Python project would attract, which is a real con, but the core team has kept pace with YouTube for years.

The stack is three containers, not one

Invidious needs PostgreSQL, the main server, and the companion. The project ships a compose file that wires them together, and although bare-metal installs are documented, I would not do one; the container path is what the maintainers test.

services:
  invidious:
    image: quay.io/invidious/invidious:latest
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      INVIDIOUS_CONFIG: |
        db:
          dbname: invidious
          user: kemal
          password: kemal
          host: invidious-db
          port: 5432
        check_tables: true
        hmac_key: "generate-a-long-random-string"
        domain: yt.example.com
        https_only: true
    depends_on:
      - invidious-db
  invidious-db:
    image: docker.io/library/postgres:14
    volumes:
      - postgresdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: invidious
      POSTGRES_USER: kemal
      POSTGRES_PASSWORD: kemal
volumes:
  postgresdata:

Add the companion block from the upstream compose file and its secret key, set hmac_key to something long and random, and put a reverse proxy with TLS in front. The 50 MB figure is the Invidious process alone; Postgres adds its own footprint, so plan for a 1 GB box in total.

Keeping it alive is a maintenance schedule, not a fix

Three habits cover almost every outage. First, the project recommends restarting the Invidious container on a timer because memory grows over days; a nightly docker restart is the usual answer. Second, update on a schedule rather than waiting for a failure, because the fix for the current YouTube change is usually already merged by the time you notice. Third, if you are on a VPS, expect that its IP range is more likely to be challenged than a home connection; running the instance at home behind Tailscale sidesteps the worst of the rate limiting and keeps the instance private.

Private beats public

A public instance is a gift to strangers and a headache for you: it draws traffic that triggers YouTube's limits faster, it attracts abuse reports, and the public instances list has seen more than one operator burn out or receive legal correspondence. Keep registration closed, keep it on the VPN or behind an auth proxy, and share it with your household. The same rule applies to the sibling projects for other platforms, Redlib for Reddit and Nitter for X, both of which live in the social category and break for the same reasons.

The alternatives fail in different ways

Piped is the other serious front-end: Java and a proxy component instead of Crystal, a somewhat lighter footprint, and a comparable breakage cadence. Neither is more reliable than the other for long. If watching later matters more than browsing now, the archive-first tools sidestep the whole problem: Tube Archivist and Pinchflat download subscriptions with yt-dlp and serve local files, which never break mid-video. The YouTube alternatives page lays out that split.

What I'd do

Run Invidious at home in the compose stack above, registration off, reachable only over Tailscale, with a nightly restart and a weekly image pull in a cron job. Export subscriptions from your Google account once via Takeout, import them, and use the RSS feed per channel from your reader so the day the instance breaks you still see what was posted. For the channels you actually care about, add Pinchflat alongside it. That pairing has survived every YouTube change I have seen with at most a day of downtime.