Skip to content
Go back

Invidious, Piped, Redlib, Nitter: 2026 Status

· Updated:
By SumGuy 11 min read
Invidious, Piped, Redlib, Nitter: 2026 Status
Contents

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 iv-org/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.

docker-compose.yml
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.

docker-compose.yml
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:

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.

docker-compose.yml
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 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, Dead for Real This Time

Status: Dead. X Corp sent a cease-and-desist in August 2026, the maintainer took the flagship instance offline, and the GitHub repo is archived.

Let’s not sugarcoat this. Nitter took a body blow when Twitter/X nuked guest API access in 2023, and it limped along for a couple of years on rotating guest tokens. Then on August 24, 2026, X Corp sent cease-and-desist letters demanding “a permanent takedown of Nitter instances and the project’s repository,” citing scraping and unauthorized account access. Maintainer zedeus took nitter.net offline, archived the zedeus/nitter repository on GitHub, and said he was seeking legal advice. Other public instances, including XCancel, got hit with the same letters and folded too.

The code still exists in the archived repo, so self-hosting from it is technically possible. But you’d be standing up unmaintained code against a platform that just sent legal threats over this exact use case, not a garden-variety maintenance problem anymore.

Here’s the compose setup that used to be the standard self-hosted approach, kept here for reference. Understand that the upstream project is archived and this is running against active legal risk, not a supported path:

docker-compose.yml
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:
nitter.conf
[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, was already fragile before the takedown. Now you’re also building on a frozen codebase with nobody left to fix it when X changes something.

Honest assessment: If you need X content without an account, a browser extension like LibRedirect can still point you at whatever public mirror survives, but don’t count on one existing for long. Running your own Nitter now means reviving archived code under an active legal threat aimed squarely at that activity. It’s 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:

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): The simpler ancestor LibRedirect was forked from, but it’s been unmaintained for years, with stale instance lists and broken redirects. Skip it and just use LibRedirect, which is what everyone migrated to anyway.

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 gets smooth 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 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: Nitter is dead. X Corp’s August 2026 cease-and-desist got the repo archived and the flagship instance taken offline. If you only occasionally need to read a tweet someone linked you, a browser extension pointed at whatever mirror still survives is your only option, and it may not survive long either. Following accounts regularly through Nitter isn’t a plan for 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.


Share this post on:

Send a Webmention

Written about this post on your own site? Send a webmention and it'll show up above once verified.


Previous Post
Joplin Server vs Trilium vs Standard Notes
Next Post
cgroups v2 in Practice: Limits, Pressure, Containers

Discussion

Powered by Garrul . Sign in with GitHub or Google, or post anonymously.

Related Posts