A community-maintained inventory now lists 13 working Nitter instances, 12 days after Nitter's maintainer said X Corp. sent cease-and-desist letters demanding that the project's repository and instances come down. Ten are ordinary web addresses and three are Tor services. At 07:30 UTC on September 5, the story had drawn 345 points and 125 comments on Hacker News. The useful developer angle sits behind that burst of attention: copying the code was straightforward, while keeping it connected to X has become the costly part.
MrKeyoor made one request to each of the ten public web addresses in the new instance list, and all ten returned HTTP 200 on September 5. That check confirms that their front doors answered. It does not establish that every profile, search, RSS feed, or timeline request succeeds under load. We did not test the three Tor addresses. The same inventory puts another eight services in an active but rate-limited bucket, a warning against reading 13 as a settled capacity figure.
The code moved after the original project stopped
The original Nitter repository is archived on GitHub. Its README says X sent cease-and-desist letters on August 24, 2026, seeking a permanent takedown of Nitter instances and the repository. The README does not reproduce those letters, so the stated date and demand come from the maintainer rather than an independently available legal filing. GitHub still exposes the AGPL-3.0 code and its history, but the archived state makes the upstream read-only.
A project on Codeberg now describes itself as a fork of zedeus/nitter. It retains the Nitter name in the README and the same basic installation path, while replacing repository links and removing the original donation section. Its visible commit history shows two fork-specific replacement commits dated September 1 above inherited Nitter commits. That proves the source and documentation have been relocated. It is too early to infer a sustained maintenance team from those changes.
The instance tables show the operational move more clearly. The older GitHub wiki inventory contains one official address, seven public web instances, one Tor service, and one I2P service. The Codeberg fork's current page has ten web addresses and three Tor addresses in its working section. It separately names six services as formerly active or taken down. One address, nitter.kareem.one, appears on both working lists; many of the current names are different.
That comparison gives the Hacker News headline some support, although it is not a controlled uptime study. The old and new pages use different categories, were edited at different times, and depend on volunteer status reports. The Codeberg page had accumulated 975 revisions and was last edited on September 3 when we read it, which shows how quickly an address can move between buckets. The defensible claim is narrower: the successor list currently contains more working entries than the older GitHub list, and its ten web front pages answered during our check.
Real X accounts are now infrastructure
Nitter was built as a server-side alternative front end for Twitter, now X. According to the original README, the browser runs no Nitter JavaScript or ads, requests go through the Nitter backend, and the service can expose profiles and RSS feeds through X's unofficial API. That arrangement keeps a visitor's direct IP address and browser fingerprint away from X. It also places the instance operator between the visitor and a platform that can change access rules without coordinating with the project.
The successor fork says an operator now needs real X accounts because the earlier access methods were removed. Its session-token guide loads account cookies from a JSON Lines file and expects values including an authentication token and X's ct0 cookie. The guide warns that a large public instance is difficult to run with only a small number of accounts. A private installation may work with one session; a busy public host needs a pool that can survive limits and account loss.
This changes the job of running the software. A conventional reverse proxy, Nitter process, and Redis or Valkey cache are only part of the stack described in the fork's installation guide. Operators must protect live account credentials and replace sessions when X rejects requests. The eight rate-limited entries in the instance inventory are a visible result of that dependency. An address can be online while the service behind it cannot reliably fetch the page a reader asked for.
The session requirement also creates a shared failure mode across otherwise separate hosts. More domains reduce the damage when one operator goes offline or receives a complaint. They do not give the network control over X's internal endpoints or account enforcement. The Nitter README says the software uses an unofficial API without a developer account; the fork documentation now makes clear that ordinary account sessions have taken the place of the old guest access.
Privacy now comes with an operator question
For readers, Nitter still has a simple appeal. Its documented design removes X's client-side scripts and ads, lets the backend fetch public material, and produces much smaller pages. RSS support also turns a profile into something that can be followed without keeping an X tab open. Those benefits survive in the fork because the application architecture and user-facing routes have been copied along with the source.
That design transfers trust to the instance host. Each request reaches a Nitter server first, so that server can receive connection metadata even though X does not receive it directly from the visitor. This follows from the backend proxy model described in the project README. A public instance may have a careful operator and short logs, but the inventory does not audit logging policies. Readers should treat an unfamiliar host as a proxy they are choosing to trust, rather than as an automatic anonymity service.
Tor changes the network path for the three onion services listed as working, but the inventory does not publish uptime histories or security reviews for them. The ten web endpoints are similarly a mix of independently named domains with no common service pledge on the page. The list is useful for discovery and status triage. It cannot certify how an operator stores requests or secures session tokens.
Open code cannot supply upstream permission
The project's AGPL license allows the Nitter source to be studied, copied, and modified under the license terms, which lets a public fork carry the code after the GitHub project was archived. Access to X is a separate technical dependency. The official README identifies the API as unofficial, while the successor's guide relies on cookies from real X accounts. Forking preserves the application code; it does not freeze the service behavior that code calls.
The current count shows recovery along with its limits. The Codeberg list has multiple public entry points after six others disappeared, while eight more services are rate-limited. Availability depends on valid sessions and continued compatibility with endpoints controlled by X. Neither condition is decided by how many copies of the repository exist.
The 345-point Hacker News discussion is evidence that developers still care about a lightweight way to read public X posts. It is not evidence that every listed instance works, that the cease-and-desist demand lacks force, or that the fork will stay maintained. Those questions need separate proof: repeated functional checks, the underlying legal documents, and new engineering commits in the successor repository.
The next test is whether 13 holds
Watch the instance page for movement between working, rate-limited, and taken-down sections, and the fork's commit log for fixes that go beyond renamed links. If the working count remains near 13 after account sessions age and X changes its endpoints, the network will have demonstrated more than a quick relocation. If addresses drift into the rate-limited section, today's recovery will look like a short-lived inventory spike rather than durable service capacity.