Invidious, Piped, Redlib, Nitter: 2026 Status

The Privacy Frontend Situation in 2026

You remember the dream. Scrape YouTube without feeding Google your watch history. Browse Reddit without the app begging you to log in every five minutes. Follow someone on X without creating an account just to read a tweet. Privacy frontends felt like a clean little hack — the content, none of the surveillance.

Platforms noticed.

Since 2023, Google, Reddit, and Twitter/X have all taken runs at these frontends. Some survived. Some got gutted. Some are technically alive but on life support. This is the honest 2026 state of the four big ones: Invidious, Piped, Redlib, and Nitter.

Short version for the impatient: self-hosted, behind Tailscale, for personal use. Public instances are an abuse magnet and a rate-limit roulette wheel. Don’t run them unless you enjoy moderating strangers’ traffic.

Invidious — YouTube’s Stubborn Cockroach

Status: Functional (barely), self-hosted with caveats

Invidious has been fighting Google since before it was cool. The project hit serious turbulence starting in 2024 when Google started actively blocking Invidious-sourced requests at the IP level. Public instances got hammered with CAPTCHAs, throttling, and outright blacklisting. Running a public Invidious instance in 2026 is an exercise in whack-a-mole.

Self-hosted, on a single IP that you rotate through your VPN or Tailscale? Still works. Still rate-limits you if you binge-watch. Still occasionally fails on age-restricted content. Still has comments (when it works). It’s not smooth, but it’s yours.

The project lives under invidious/invidious on GitHub. The invidious.io instances list is maintained by the community — most public instances have strict registration locks now precisely because open registration invites floods that burn out their API quotas.

Running Invidious in 2026

You need Postgres. You need an HMAC key. You want registration disabled unless you’re hosting for a known group of people.

services:
  invidious:
    image: quay.io/invidious/invidious:latest
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      INVIDIOUS_CONFIG: |
        db:
          dbname: invidious
          user: invidious
          password: changeme
          host: invidious-db
          port: 5432
        check_tables: true
        hmac_key: "replace-this-with-a-long-random-string"
        domain: "invidious.yourdomain.com"
        https_only: true
        registration_enabled: false
        login_enabled: true
        captcha_enabled: false
        default_user_preferences:
          local: true
          quality: dash:1080p
    depends_on:
      - invidious-db
    networks:
      - invidious

  invidious-db:
    image: docker.io/library/postgres:14
    restart: unless-stopped
    volumes:
      - invidious-db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: invidious
      POSTGRES_USER: invidious
      POSTGRES_PASSWORD: changeme
    networks:
      - invidious

volumes:
  invidious-db:

networks:
  invidious:

Throw Caddy in front of it:

invidious.yourdomain.com {
    reverse_proxy invidious:3000
}

What works, what doesn’t

Works: General video playback, subscriptions (without a Google account), search, most non-age-restricted content, playlists.

Flaky: Age-restricted videos (Google keeps tightening this), the local: true flag helps route video data through your instance rather than your browser hitting Google directly — but it hammers your bandwidth. Comments break occasionally when Google tweaks their internal API format.

Doesn’t work consistently: Live streams on public instances. Anything that requires a logged-in Google session for quality selection.

Mitigation: Set local: false if you’re bandwidth-constrained. Your browser still hits Google for the actual video stream, but your viewing habits stay out of Google’s logs (mostly). It’s a trade-off.

The honest take: Invidious is still the best option if you want YouTube with a UI that doesn’t actively fight you. But treat it as personal infrastructure, not a public service you run for the neighborhood.

Piped — The More Resilient Alternative

Status: Better than Invidious for video-only use

Piped takes a different architectural approach. Instead of one monolith, it splits into three components: the backend (Kotlin), the frontend, and a proxy service for video streaming. The separation helps because you can run the backend on a beefier server and scale independently.

For pure video playback in 2026, Piped holds up better than Invidious under Google’s blocking pressure. Comments? Hit or miss — often missing. The trade-off is that Piped’s UI is more stripped-down. It doesn’t try to be a YouTube clone, it tries to be a YouTube alternative, and there’s a difference.

services:
  piped-backend:
    image: 1337kavin/piped:latest
    restart: unless-stopped
    volumes:
      - ./config/piped.properties:/app/config.properties:ro
    depends_on:
      - postgres
    networks:
      - piped

  piped-frontend:
    image: 1337kavin/piped-frontend:latest
    restart: unless-stopped
    environment:
      BACKEND_HOSTNAME: "pipedapi.yourdomain.com"
    networks:
      - piped

  piped-proxy:
    image: 1337kavin/piped-proxy:latest
    restart: unless-stopped
    environment:
      - UDS=1
    networks:
      - piped

  postgres:
    image: postgres:15
    restart: unless-stopped
    environment:
      POSTGRES_DB: piped
      POSTGRES_USER: piped
      POSTGRES_PASSWORD: changeme
    volumes:
      - piped-db:/var/lib/postgresql/data
    networks:
      - piped

volumes:
  piped-db:

networks:
  piped:

Your piped.properties config goes in ./config/piped.properties:

PORT: 8080
HTTP_WORKERS: 2
PROXY_PART: https://pipedproxy.yourdomain.com
API_URL: https://pipedapi.yourdomain.com
FRONTEND_URL: https://piped.yourdomain.com
postgres_url: jdbc:postgresql://postgres:5432/piped
postgres_username: piped
postgres_password: changeme

Three subdomains, three Caddy entries. It’s more setup than Invidious but the payoff is that Piped degrades more gracefully when Google applies pressure. When Invidious throws a 403, Piped often still delivers the stream through its proxy layer.

The verdict: If you’re primarily watching videos and don’t need comment sections, Piped is the more reliable YouTube frontend in 2026. Invidious is better if you want the full experience — subscriptions, comments, playlist management — and are willing to deal with more breakage.

Redlib — Reddit Without the Redesign Trauma

Status: Functional, occasionally breaks, actively maintained

Libreddit died when Reddit’s 2023 API crackdown made the old approach untenable. Redlib forked from it and pivoted to parsing Reddit’s public JSON endpoints — the ones the website itself uses — rather than the official API. It’s a clever workaround, and it still works in 2026.

The catch is that Reddit keeps tweaking their site, which occasionally breaks Redlib’s parsers. The maintainers are active and usually push fixes within a few days, but you’ll notice breakage when it happens. Subreddits load but posts don’t. Images 404. That kind of thing.

The other catch: Reddit has been progressively pushing users toward logged-in experiences. Some subreddits are effectively inaccessible to non-logged-in scrapers because Reddit gates them behind “you need an account to view this NSFW community” or “this community requires an account.” Redlib can’t do much about that — it’s Reddit’s content, Reddit’s rules.

For the vast majority of public subreddits? It works great.

services:
  redlib:
    image: quay.io/redlib/redlib:latest
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      REDLIB_DEFAULT_SUBSCRIPTIONS: "selfhosted+homelab+linux+docker"
      REDLIB_DEFAULT_THEME: "black"
      REDLIB_DEFAULT_FRONT_PAGE: "default"
      REDLIB_DEFAULT_USE_HLS: "on"
      REDLIB_DEFAULT_HIDE_HLS_NOTIFICATION: "on"
      REDLIB_DEFAULT_WIDE: "off"
      REDLIB_DEFAULT_COMMENT_SORT: "top"
      REDLIB_DEFAULT_SHOW_NSFW: "off"
      REDLIB_SFW_ONLY: "off"
    networks:
      - redlib

networks:
  redlib:

That’s genuinely the whole setup. No database, no persistent state (unless you add it). Redlib is stateless by design — user preferences live in cookies, subscriptions are a URL query parameter or cookie. It’s refreshingly simple.

REDLIB_DEFAULT_SUBSCRIPTIONS sets the default front page for logged-out users — useful if you’re hosting for yourself and want your regular subs without logging in. REDLIB_DEFAULT_USE_HLS handles video playback (Reddit’s v.redd.it videos); leave it on unless you’re seeing issues.

What works, what doesn’t

Works: Post listings, comments, search, media (images, galleries, most videos), direct subreddit browsing.

Flaky: v.redd.it videos sometimes break, awards/karma counts are occasionally wrong (who cares), live thread updates.

Doesn’t work: Gated subreddits requiring login, private communities, quarantined subreddits.

Pro tip: Redlib has zero rate-limiting of its own — it rate-limits based on what Reddit allows from its IP. If you’re sharing your instance, heavy usage will eventually get your instance’s IP throttled by Reddit. Personal use behind Tailscale sidesteps this entirely.

Nitter — Mostly Cooked

Status: Mostly dead for public instances, personally-hosted with token rotation is technically alive

Let’s not sugarcoat this. Nitter took a body blow when Twitter/X nuked guest API access in 2023, and it’s never fully recovered. The project exists. Self-hosting is technically still possible. But “technically possible” and “works reliably” are doing a lot of separation here.

The approach that some self-hosters use in 2026: rotating authenticated guest tokens. X’s app still generates guest tokens internally for non-logged-in browsing, and if you can capture and rotate those tokens across your Nitter instance, you get limited but functional access. It’s fragile. It breaks when X updates their app. It requires a script or cron job to refresh tokens.

Here’s a minimal Nitter compose setup, but understand what you’re getting into:

services:
  nitter:
    image: zedeus/nitter:latest
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./nitter.conf:/src/nitter.conf:ro
    networks:
      - nitter

  nitter-redis:
    image: redis:7-alpine
    restart: unless-stopped
    networks:
      - nitter

networks:
  nitter:

[Server]
hostname = "nitter.yourdomain.com"
title = "nitter"
https = true
httpMaxConnections = 100

[Cache]
listMinutes = 240
rssMinutes = 10
redisHost = "nitter-redis"
redisPort = 6379

[Config]
base62Media = true
enableRSS = true
enableDebug = false

The token rotation piece — capturing guest tokens from X’s app and feeding them to Nitter — is something you’ll need to sort out separately. There are scripts floating around GitHub for it; search nitter-token and filter to repos updated in the last six months. Don’t bother with anything older.

Honest assessment: If you genuinely need X content without an account, use a browser extension like LibRedirect to redirect to a maintained public instance and accept that it’ll sometimes break. Running your own Nitter is a weekend of setup for something that might go down for a week every time X sneezes. Unless you’re technically invested in the problem, it’s probably not worth your time in 2026.

The Public Instance Problem

Running any of these publicly — where strangers can use them — changes the math significantly.

Every anonymous user on your public Invidious instance burns YouTube quota against your IP. Every Redlib visitor is a Reddit scrape on your behalf. You become the rate-limit sponge for the entire internet, and platforms know this. They don’t block individual users; they block IPs. Your public instance’s IP ends up in blocklists faster than you can rotate.

Abuse is the other issue. Open registration on Invidious? Someone will use it to download at scale. Public Redlib with no rate limiting? Script kiddies will hammer it.

The setup that actually works in 2026:

• Self-host behind Tailscale or WireGuard
• No public access
• Registration disabled (Invidious)
• Personal use or a small trusted group (family, friends)
• Rotate your VPN exit IP if you hit rate limits

This isn’t the open-web privacy utopia the projects originally aimed for. It’s more like a personal media bunker. That’s fine. It still works, and it still keeps your browsing history out of platform logs.

Browser Extensions: The Force Multiplier

The missing piece in most setups: auto-redirection. You don’t want to manually copy YouTube URLs to your Invidious instance every time. Let the browser handle it.

LibRedirect (Firefox, Chrome): Automatically redirects YouTube → Invidious/Piped, Reddit → Redlib, Twitter → Nitter, and a dozen other platforms. You set your instance URLs once, and it silently redirects in the background. It’s the glue that makes the whole stack usable.

Privacy Redirect (Firefox): Simpler version of the same concept. LibRedirect has more granular controls; Privacy Redirect is easier to configure. Either works.

Point them at your self-hosted instances and you’re done. You click a YouTube link, it opens in Invidious. You click a Reddit link, Redlib. The experience becomes seamless enough that you forget the redirect is happening.

Should You Bother?

Depends on what you’re optimizing for.

If you want Google out of your YouTube habits: Yes, run Invidious or Piped. Personal use behind Tailscale is the sweet spot. Accept that age-restricted content is a coin flip and live stream support is minimal. For 80% of YouTube use cases, it’s fine.

If you want Reddit without the app nonsense: Redlib is genuinely good. It’s faster than the Reddit website, has no ads, and the setup is trivially simple. Run it. It’ll break occasionally. Update the container when it does.

If you want X without an account: Temper expectations. Nitter is alive but unreliable. If you only occasionally need to read a tweet someone linked you, use a public instance and accept breakage. If you’re trying to follow accounts regularly, Nitter isn’t a sustainable solution in 2026.

The bigger picture: These frontends exist because platforms extracted value from users without giving them control over the relationship. The platforms have pushed back hard. The frontends have adapted, forked, and survived — just not in the form their original authors imagined. They’re personal tools now, not public infrastructure.

That’s not a failure. That’s just the current equilibrium. Self-host smart, keep your VPN close, and update your containers when the parsers break. The platforms aren’t winning — they’re just making it mildly more annoying.

Your 2 AM self will appreciate having YouTube available without ads and without Google knowing exactly which rabbit hole you fell down.

Related Reading

• AdGuard DNS Sync Across Two Instances
• Anubis: Anti-AI-Crawler Proof-of-Work
• BTCPay Server: Self-Hosted Crypto Payments
• Blog Comments: Self-Host or SaaS?
• CryptPad vs EtherCalc: Privacy Collaboration