Self-Hosted Nitter: A Lightweight X/Twitter Front End (With Eyes Open)

Twitter became X, the default site got heavier, and logging in turned into a funnel of prompts and trackers. You still want to read a thread someone linked without handing over a fingerprint, a cookie wall, and half a megabyte of JavaScript. That is the niche Nitter (~14.5k stars, AGPL-3.0) carved out: a privacy-oriented front end that talks to Twitter's unofficial APIs on the server, so your browser never phones home to X directly.

Written in Nim, Nitter strips ads, works without client-side JS, proxies media, and can expose RSS feeds per user or search (if you leave them enabled). Pages are tiny compared to twitter.com — the README quotes ~60KB vs ~784KB for a sample profile. Invidious fans will recognize the pattern: alternate skin, same upstream chaos.

What self-hosting buys you

Privacy for readers. Timelines and profiles load through your instance; IP addresses and browser signals stay on your VPS, not X's analytics pile.

Control over abuse knobs. Turn RSS off if scrapers hammer you, rate-limit at the reverse proxy, and run behind your own domain so you are not dependent on a public instance that vanished overnight.

Lightweight embedding culture. Communities that link profiles in docs, status pages, or internal wikis can standardize on nitter.yourdomain/@handle instead of the main site.

Canadian hosting angle. The instance runs on hardware you choose — useful when policy says "no US social embeds on employee machines" but you still need to read public posts.

What it does not buy you

Be clear-eyed: Nitter is not a licensed Twitter API product. It scrapes/syndicates via guest sessions and cookies that break whenever X changes the rules. Operators maintain sessions.jsonl (account cookies) and watch rate limits; maxConcurrentReqs in config exists because parallel requests per session cause races.

Legal risk is real. The README notes cease-and-desist letters from X Corp in August 2026 demanding takedown of instances and the repo — the maintainer was seeking funding and legal help as of October 2026. Self-hosting may be technically straightforward and legally uncomfortable. Read AGPL obligations (no proprietary public instances) and get proper advice before exposing a production hostname.

Running it

Stack:

• Nitter — binary or Docker image zedeus/nitter:latest (amd64 and arm64)
• Redis or Valkey — caching; Valkey is the recommended fork since Redis's license shift
• Reverse proxy — nginx or Caddy for TLS; set https = true and a real hostname in nitter.conf so cookies behave

Minimal Docker flow (Redis separate or via compose):

cp nitter.example.conf nitter.conf
# edit hostname, hmacKey (openssl rand -hex 32), redisHost
docker run -v $(pwd)/nitter.conf:/src/nitter.conf -d --network host zedeus/nitter:latest

Compose users point redisHost at the Redis service name and mount sessions.jsonl when using cookie-based auth. Container listens on 8080 by default. Plan 512 MB–1 GB RAM for a small instance plus Valkey; CPU spikes when timelines are cold in cache.

Operational habits: refresh sessions when search breaks, keep enableRSS off if bots abuse feeds, and log via journalctl or docker logs — Nitter still prints errors to stdout more than structured logs.

Who should bother

Maybe: privacy clubs, open-source projects linking timelines, homelabbers who already run Valkey and a reverse proxy.

Probably not: enterprises that need a compliance story, teams without someone to babysit session files, or anyone who cannot accept upstream or legal uncertainty.

We host the Canadian VPS and proxy layer — not the relationship with X. If you still want an instance after weighing the risks, Docker on our metal plus firewall rules and rate limits is the boring part. Tell us expected traffic and whether RSS stays on and we will size the box and TLS hostname before you publish the URL.