Self-hosting a Nitter instance in October 2026 remains possible, but the revival announced in early September lasted about five days. X Corp’s cease-and-desist letters of 24 August 2026 set off a sequence in which the GitHub repository was archived on 25 August, the project was declared continued on 6 September, and the repository was archived again on 11 September; the README visible in late October carries a 10 October update in which the developer says he is seeking funding and legal help, per the zedeus/nitter repository and Wikipedia’s Nitter timeline. The mechanism is still documented: the project’s session-token wiki walks an operator through creating the registered-account sessions an instance now needs to serve anything at all. Installation remains a short dependency list and a build; staying online is a maintenance contract that includes rotating X account sessions X can ban, tracking a repository archived twice since late August, and personally weighing legal exposure from a dispute with no documented resolution. Whether to run one depends less on the install than on how much ongoing upkeep, and how much legal attention, you are willing to own.
The September comeback lasted five days
On 24 August 2026, X Corp sent cease-and-desist letters accusing Nitter of scraping and demanding the permanent takedown of Nitter instances and the project’s repository. According to the Nitter Wikipedia article, the developer said he was seeking legal advice and that “development has stopped for the time being,” and the XCancel instance announced it was offline “until further notice.” The GitHub project was archived on 25 August.
Then the picture whipsawed. On 6 September 2026 it was announced that the Nitter project would continue, and one day later XCancel became the first instance back online, per Wikipedia’s timeline. The revival held for less than a week: on 11 September the GitHub project was archived again, on 14 September XCancel announced it was offline again until further notice, and the main Nitter website went offline.
The latest word from the project itself is a README note dated 10 October 2026: “UPDATE 10 October 2026: I’m seeking funding and legal help. See nitter.net for more details,” per the project’s README. Read that carefully. It is not a development roadmap; it is a fundraising and legal-defense appeal, and it points readers to nitter.net, the site Wikipedia records as offline in mid-September. Neither page records whether the site has since returned or the repository has been unarchived. Anyone planning infrastructure around Nitter should re-check both before committing a weekend.
The timing pattern matters, because this is the second comeback cycle, and the project’s own operator documentation dates from the first one. Nitter was discontinued in February 2024 and resumed on 6 February 2025, when Zedeus announced on GitHub Discussions that development would continue, per Wikipedia’s Nitter history and that announcement. The current authentication model and the project’s own hosting cost model both come from that February 2025 revival. They predate the August 2026 letters by eighteen months, so treat them as history that explains the architecture, not as a statement about who is maintaining what right now.
Registered X accounts are the whole authentication model
Nitter works by authenticating with registered X account sessions, because the guest-account mechanism that powered it for years was removed by X in January 2024. Per Wikipedia, Nitter originally relied on a glitch that allowed the mass creation of “guest accounts” through proxy servers, letting instances serve content without any real X account behind them. When X removed guest-account creation and heavily restricted logged-out access, that model ended, and the revived project shifted to sessions from registered accounts.
The consequence for an operator is direct: the account behind your instance is a real X account, and X can ban it. When the project was declared dead in February 2024, Zedeus said instances could be self-hosted by having users supply their own account “at the risk of the account being banned,” according to Wikipedia. The session-token wiki puts the same risk in operational terms: it suggests proxies or VPNs when creating many sessions, then adds that “it’s unknown how much this affects your risk of getting banned.” Nobody, including the project, can tell you the ban rate.
This is the single most important architectural fact for anyone evaluating self-hosting today, and it is also the one most likely to be missed, because the copy on public instance pages is not guaranteed to be current. The nitter.ca instance, running commit 13a4580, still displays pre-2024 text claiming the unofficial API has “no rate limits or developer account required,” per its about page. That description was accurate under the guest-account regime. It is not accurate now, and the same page still invites readers to a Freenode IRC channel, which dates the copy well before the current architecture. One stale page is not a survey of every instance, but it is a warning: if you evaluate Nitter by reading instance about-pages, check the copy against the session-token wiki before you trust it.
What the setup involves
The stack is small: per the project README, the dependencies are libpcre, libsass, and redis/valkey, with Redis required for caching and the Valkey fork recommended because Redis stopped being open source in 2024. Compiling Nitter needs a Nim installation, compiling the scss files needs libsass, and a reverse proxy such as Nginx or Apache sits in front. Packaging is ordinary: a multi-arch Docker image, a docker-compose path that runs Nitter and Redis as separate containers, and a systemd unit.
The step that is no longer ordinary is authentication. Per the session-token wiki, “Nitter requires real accounts to authenticate API requests.” Sessions load from a sessions.jsonl file in the directory where the nitter binary lives, overridable with the NITTER_SESSIONS_FILE environment variable; each line is a JSON object holding an auth_token and ct0 cookie, with optional username and id fields that make sessions easier to troubleshoot and monitor. Two helper scripts in tools/ create them. create_session_browser.py drives a browser and handles TOTP two-factor automatically if you pass the secret; create_session_curl.py is faster but, in the wiki’s words, “may be more susceptible to bot detection,” so it is recommended only when speed is a priority or the browser script is not working. That is the real prerequisite list: a build toolchain, a cache, and one or more X accounts you are willing to lose.
Scale decides how many. The wiki opens with a warning: “Running a large public instance is difficult, and is not feasible with a small amount of accounts,” and it points anyone attempting one to the maintainer directly. The maintainer drew the same line in the February 2025 resumption announcement: “Hosting an instance now is difficult and expensive, but not impossible. For a small/private instance you can do it for free quite easily, but a large public instance is a different story.” Date that properly. It is February 2025 guidance, written before the August 2026 letters, and it is the project’s own cost model: small and private is cheap, large and public is a different job. The same announcement merged the authentication replacement (PR #1210, replacing #985), which ended the era of special branches and forks, and described a long-term plan to rewrite the codebase in Go because building on Nim had become painful. That rewrite was a plan, not a delivered migration, and it predates the dispute, so it tells you the maintainer found the codebase hard to extend; it is not a schedule you can build on.
Session rotation is the recurring cost
Running a Nitter instance costs you continuous session maintenance and upstream commit tracking, indefinitely. Together, those are the actual price of the service.
Session maintenance is the recurring one. Your instance authenticates through registered X accounts, and X can ban them. The February 2024 guidance recorded by Wikipedia, users supply accounts “at the risk of the account being banned,” describes a routine operational event, not an edge case. When a session dies you run the creation script again, append a line to sessions.jsonl, and restart. The wiki’s format supports exactly that workflow: multiple sessions are one JSONL line each, and the optional username and id fields exist so you can see which one failed. The practical mitigation is the obvious one: use disposable accounts created for this purpose, never an account you care about, and never a paying one, and keep the instance private, because the wiki’s own threshold is that a large public instance is not feasible with a small number of accounts.
Commit tracking is the second treadmill, and it has gotten worse since the cease-and-desist. Nitter works against X’s internal, unofficial API, so every time X changes that API, Nitter can break until a patch lands. The last tagged release listed on Wikipedia is 2026.03.15-7ce29bd, dated 15 March 2026, now more than seven months old. An operator is therefore not tracking releases; they are tracking commits on a repository Wikipedia records as archived on 25 August 2026 and again on 11 September, and whose README message is a request for funding and legal help. The correct posture is to pin a working commit, keep a local mirror of the source, and re-pull when X moves something. With the repository’s future resting on whether the developer secures legal help, assume you are the maintainer.
The table below prices the decision axes as they stand in October 2026, based on the repository documentation, the session-token wiki, and Wikipedia’s account of the mechanism change:
| Decision axis | What you get | What you carry |
|---|---|---|
| Auth mechanism | Registered account sessions in sessions.jsonl | Accounts X can ban; rotation is your job |
| Deployment | Nim build, or the multi-arch Docker image | A compile toolchain to maintain if you build |
| State store | Redis or Valkey, required for caching | Another service to run and back up |
| Maintenance | Upstream fixes when X’s internal API moves | Tracking commits on a repo archived twice since August |
| Features | Read-only timelines, search, chronological order | No login, posting, notifications; RSS often disabled |
| Legal | AGPLv3 code, community instances | Personal exposure after X Corp’s August 2026 letters |
It is a maintenance problem, not a setup problem
The install here is a short dependency list and a Nim build. The maintenance is an open-ended commitment to rotate banned sessions, chase upstream commits whenever X changes its internal API, and monitor a legal situation that has taken the repository offline twice since 24 August 2026. Nitter is a clean example of a general pattern: self-hosted services that are marketed, or remembered, as easy to install while being expensive to keep.
The setup-versus-maintenance asymmetry generalizes past Nitter. Most self-hosted software sold as “easy” is easy at hour one and priced at hour one thousand. The honest cost model for a scraping proxy specifically has three line items that setup guides omit: the consumable resource (here, X accounts with finite lifespans), the adversarial dependency (a platform that actively changes to break you), and the legal surface (an entity that sent enforcement letters in August 2026, after which the repository went read-only twice inside three weeks). A service with all three is not a weekend project; it is an operations role with no salary.
This is also why the performance pitch, while real as far as it goes, should not drive the decision. The project reports that for the @nim_lang account, Nitter serves 60KB versus 784KB from twitter.com, is on average around 15 times lighter, and in most cases serves pages faster, with timelines loading 2-4x faster, per the README. Those are the project’s own reported figures, and they describe the reader’s experience, not the operator’s costs. A 15x lighter page is a reason to use Nitter. It is not a reason to run Nitter.
The legal dispute is open and unrecorded
An operator carries personal exposure that follows X Corp’s cease-and-desist letters of 24 August 2026. The letters demanded the permanent takedown of Nitter instances and the project repository, per the project README and Wikipedia. What has happened since is documented: the repository went read-only a day after the letters, came back for five days in September, went read-only again, and the main site went offline. What is happening now is not documented: the sources reviewed here include no X Corp statement beyond the reported August letters, no court filing, and no settlement or withdrawal, so there is no basis here to call the dispute either escalating or resolved. The honest description is that it is open and unrecorded.
The developer’s own position sharpened on 10 October 2026, when the README began carrying the note “I’m seeking funding and legal help. See nitter.net for more details.” No legal defense fund or institutional backing appears behind the project; the developer is still trying to assemble both. Wikipedia records a past grant from the NLnet Foundation’s NGI fund, but that is historical project funding, not legal backing for the current dispute. If the person who wrote the code is soliciting legal help, an individual running an instance from their own hardware should not assume any umbrella exists above them.
The license side is clearer. Nitter is AGPLv3 with no proprietary instances permitted, per the README. The AGPL means that if you modify the code and serve it publicly, you owe source. That does not protect you from a cease-and-desist; it defines the compliance floor.
The practical read: X Corp has shown it will send letters, the project’s survival plan is a funding appeal, and no source reviewed here records how X Corp is treating operators now. An operator who keeps an instance private and small is a different target than a public instance listed on a tracker, but “different target” is a risk judgment you are making alone, without a reported outcome for a private operator to reason from. The “you” in “self-hosted” is doing real work in the legal section.
Should you self-host Nitter right now?
Self-hosting Nitter in October 2026 is viable for a reader who will run it privately, on disposable accounts, and treat it as a maintained system rather than an installed one, and not viable for anyone who needs it to be a stable dependency. The mechanism works: registered-account sessions in sessions.jsonl, a Redis or Valkey cache, read-only browsing and search behind your own reverse proxy, all documented on project pages that were live in late October. The costs are concrete: session rotation when bans land, commit tracking on a repository whose continuation depends on whether its developer secures funding and legal help, and legal exposure in a dispute with no recorded current state.
Two checks before investing any time. First, re-check the project’s own channels: the README points to nitter.net for details, and Wikipedia records that site as offline in mid-September, so check both the site and the repository and treat silence as information. Second, if the number of live public instances matters to your decision, verify it against a live tracker such as the status.d420.de page linked from Wikipedia’s Nitter article, since no instance count appears in the primary documentation and the public-instance picture has been changing week to week.
The limitation to keep in view is that nearly everything here comes from project-side sources: the README, the session-token wiki, the maintainer’s February 2025 announcement, Wikipedia’s summary of the reporting around the project, and one instance’s stale about-page. That is enough to describe what running an instance requires and what it costs. It is not enough to price the legal tail risk, to compare the economics against paying X for API access, or to promise the project exists in any particular state next month. Run it if the maintenance reads like work you will actually do; skip it if you were hoping the Docker command was the whole job.
Join the discussion
Share a useful perspective or ask a question about this article.