What Is Happening?

Since the beginning of 2026, Russia has seen a growing number of outages and restrictions affecting development infrastructure: GitHub, Linux system repositories, selected repositories in the Rust and Debian ecosystems, and now PyPI (the official Python package repository). Meduza, RBC, and Anti-Malware covered this story.

In May 2026, the OONI (Open Observatory of Network Interference) project recorded a deterioration in GitHub accessibility from Russia. According to OONI data cited by Verstka, the share of anomalous Web Connectivity test measurements for GitHub on Russian networks rose from a background level of roughly ≤4% to 10% on May 5, and reached approximately 16% on May 6–7. This figure represents the aggregate share of problematic measurements in the OONI Probe sample — not the share of users who lost access entirely. Meduza and The Insider also reported outages and user complaints, while Skillbox Media described symptoms such as unstable page loading, git clone failures, and problems accessing raw files.

Roskomnadzor (Russia’s federal communications regulator, RKN) officially stated that it has not restricted access to GitHub. The GitHub domain has not been blocked outright. At the same time, Verstka and The Moscow Times noted that more than 130 individual pages of the service were listed in the banned information registry and that this number had grown noticeably in 2026.

On June 1, 2026, Kod Durova reported that PyPI had been experiencing access problems from Russia for two consecutive days. According to the outlet, connections to pypi.org were dropping at the TLS handshake stage. This is a pattern consistent with other resources that had previously been blocked or filtered at the network level.

RKN denied restricting access to PyPI. Meanwhile the industry is discussing a shift toward mirrors, self-hosted Git platforms, and backup dependency delivery channels. The problem no longer looks like a standalone incident but more like a new standard for developers in Russia.

Timeline of restrictions in 2026

Period	What happened
February 2026	git.kernel.org and related Linux resources became inaccessible. Developers working on Astra Linux, RED OS, and Alt Linux were filing complaints. They connected this issue to Telegram throttling.
April 2026	Debian and Rust repositories appeared in reports of affected resources.
May 5-7, 2026	OONI recorded a rise in anomalous GitHub measurements from Russia: from ≤4% to 10% (May 5) and ~16% (May 6-7). RKN denied any blocking.
May 2026	State Duma deputy Anton Gorelkin (known for his internet censorship initiatives) suggested Russian developers move their projects from GitHub to alternative platforms.
Late May 2026	Reports emerged of DeepSeek connectivity issues exhibiting the same TLS-level failure pattern.
June 1, 2026	Kod Durova reported two days of disrupted access to PyPI, with connections dropping at the TLS stage.

The GitHub situation did not emerge out of nowhere. As early as in February 2026, users and developers of Russian Linux distributions were reporting that git.kernel.org and related resources had become inaccessible (publications by Meduza, Xakep, and Anti-Malware). At the same time, Debian and Rust repositories, as well as some other projects such as Yocto, Zephyr, Buildroot, and Artix Linux faced troubles.

These restrictions hit not only open-source enthusiasts. Teams using Linux repositories for corporate development, building custom distributions, and maintaining infrastructure were affected. Meduza, CNews, and The Code explicitly noted that developers working on Russian operating systems — Astra Linux, RED OS, and Alt Linux — were among those impacted.

In May 2026 GitHub problems emerged. OONI measurements and a wave of user complaints showed that access from Russia had become noticeably less stable. The regulator and the platform offered different explanations. RKN said it was not blocking anything, while GitHub attributed the issues to infrastructure expansion work.

By late May, the problem had spread. Users reported connectivity issues with DeepSeek, and then with PyPI. In both cases, the connection was dropping at the TLS stage. This matters because that specific pattern is commonly described as a sign of network-level filtering or blocking.

OONI Data Analysis

The chart below comes from OONI Explorer’s Web Connectivity test for github.com in Russia (April 1 – June 1, 2026). Each bar represents one day of measurements: green means “OK,” yellow means “anomaly” (likely signs of interference), gray means “failure,” and red means “confirmed” (a proven block with a block page returned).

Key observations. Almost all days in April and most days in May are green meaning that under normal conditions, GitHub was largely accessible from Russia. The sharp exception is May 5–7, when the share of yellow (“anomaly”) segments rises noticeably. On May 5, anomalous measurements climbed to roughly 15 out of ~159 for the day (about 10%); on May 6, they peaked at around 24 out of ~148 (roughly 16%). After May 7, the spike subsides, though scattered yellow segments continue to appear in the following days.

What the chart does not show. There are no red segments at all. This is the key detail: OONI never recorded an automatically confirmed block — that is, a block page being returned. The data points to anomalies — possible but unproven interference. This aligns with the cautious language used in media reporting and with RKN’s denials.

Interpreting the results. The total number of measurements per day varies roughly 50 to 250. What matters is not the absolute height of the yellow bar but its share of all measurements for that day across Russian networks. OONI highlights that a rising anomaly rate indicates probable (but not guaranteed) blocking: false positives are possible.

The signal becomes stronger when errors follow the same pattern (for example, a connection reset immediately after the TLS handshake) and persist over time within a single autonomous system (ASN). The total number of measurements appears to decline gradually over the period. This could reflect a natural drop in the number of probes being run. On the other hand, it could reflect the operation of “whitelists” that prevent OONI Probe reports from being submitted at all.

Running your own measurements. The chart is interactive and updated in real time. You can open the current version with pre-filled parameters — including a breakdown by operator (ASN) — via a direct link to OONI Explorer (github.com, Russia, Web Connectivity). The country-level summary page with aggregate charts is at OONI Explorer: Internet Censorship in Russia.

You can also contribute measurements yourself. The easiest way is to install the OONI Probe app (Android or iOS) and run tests regularly from the device and network you normally use. OONI asks users to be aware of the risks and to avoid testing sensitive sites without understanding the potential consequences. Reading their security section before you start is recommended.

Possible causes of disruption

That remains unclear. No single publicly confirmed cause explains all the outages at once. But the cases already documented by Netopia and Anti-Malware suggest several working hypotheses.

Hypothesis 1. Collateral damage from blocks and slowdowns targeting other services

In February 2026, several outlets (Meduza, Xakep, and The Code) linked the inaccessibility of Linux resources to new RKN filtering algorithms deployed as part of its campaign against Telegram. When filtering is based on IP addresses, CDN subnets, TLS parameters, or other indirect signals, neutral developer services can end up caught in the crossfire.

Hypothesis 2. A growing volume of page-level blocks within large platforms

The GitHub domain as a whole is not in the banned sites registry, but individual URLs and pages are being blocked, and the number of such entries is rising. Verstka and The Moscow Times have drawn attention to this pattern. So, a service is technically “not banned,” yet its accessibility for users in Russia quietly continues to degrade.

Hypothesis 3. The inherent fragility of modern development workflows to any transport- or application-layer disruption

GitHub, PyPI, Docker Hub, system Git repositories, CI/CD pipelines, and package managers are not independent tools. They form a single supply chain for code and dependencies, as SecurityLab and Netopia have noted. Even if the main website loads, there can be a problem at the level of git clone, release file downloads, container image pulls, or Python packages. This could make the entire workflow unstable.

Stakeholder positions

The regulator’s position has not changed. RKN states that it is not restricting access to GitHub or PyPI. Formally, this allows the authorities to frame outages as external or technical problems rather than blocks.

Some industry and media explanations point to network-level collateral damage. Kod Durova  suggested that GitHub and PyPI may have been caught in the crossfire of blocks targeting CDN subnets such as Fastly. Pypi.org resolved to Fastly, and many Fastly IPs were reportedly blocked at the time. This is not any final proof, but the theory fits well with established cases in which infrastructure-based restrictions have taken down multiple seemingly unrelated services at once.

The most prominent political statement came from Anton Gorelkin, First Deputy Chairman of the State Duma Committee on Information policy, information technologies, and communications. Mr Gorelkin is known for his censorship initiatives. He called on Russian developers to move their projects from GitHub to alternative platforms, including Russian ones, and warned that the service could become entirely inaccessible. At the same time, as Skillbox Media noted, he went out of his way to say that he did not consider GitHub a “harmful platform” and acknowledged its value to the IT industry.

The professional community’s response has been more pragmatic. Experts recommended not waiting for official acknowledgment of a block, but instead building resilience proactively: mirroring repositories, deploying self-hosted GitLab or Forgejo (a GitHub/GitLab alternative), maintaining local package caches, and eliminating single external points of access to source code. These recommendations appear in Netopia’s coverage and in Kaspersky Daily’s write-up on lessons from the Docker Hub situation.

Impact on the developer ecosystem

For modern development, GitHub and PyPI are not simply “websites.” GitHub is the world’s largest collaborative development platform. PyPI is the basic package delivery infrastructure for Python, which underpins analytics, DevOps, backend development, cybersecurity, and automation. Even partial access degradation quickly becomes a business issue and a problem for education, NGOs, and independent technical teams.

Smaller teams are especially vulnerable. A large company may be able to maintain its own infrastructure, but small studios, independent developers, and civil society organizations typically have no such backup. They are the first to face missed releases, inability to update dependencies, and additional costs for workarounds.

For the open-source ecosystem, the problem is even broader. Restriction of access to global repositories weakens Russian developers’ participation in international projects, makes publishing code harder, and reduces the compatibility of local development with global practices. In the long run, cutting Russian developers off from international resources will inevitably degrade the industry as a whole.

International context

Russia is not the first country where access to global development infrastructure has become a pressure point or fallen under sanctions and regulatory restrictions. A few comparable cases help reveal a pattern rather than a single incident.

• Sanctions-driven geo-restrictions from the platforms themselves. In 2024, Docker Hub temporarily blocked access from Russian IPs, and GitHub had previously restricted individual accounts subject to sanctions. In these cases, the restriction originates from the foreign service, not the local regulator.
• Full country-level blocks. In Iran, access to GitHub, GitLab, and many package registries has been complicated for years by a combination of external sanctions and domestic filtering. Developers rely heavily on mirrors and proxies.
• The Great Firewall. In China, unstable access to GitHub and slow package registries have long made local mirrors — corporate and university npm/PyPI mirrors, for example — a standard part of engineering practice.

What is the common lesson across these cases? If access to global development infrastructure becomes unpredictable, the survivor is not one who circumvents the latest block faster but one who has built multiple independent sources for code, packages, and images in advance. That is exactly the direction the Russian industry is now moving in.

Affected services

Below is a quick map of services that have already experienced similar problems.

Service	Type of problem	What is known
GitHub	Unstable access, partial page-level blocks	In May 2026, OONI recorded a rise in anomalous connections; RKN denied blocking.
PyPI	Access problems, TLS connection drops	Problems reported by Kod Durova (June 1, 2026); RKN denied blocking.
git.kernel.org	Inaccessible for Russian users	Problems recorded in February 2026 amid network restrictions (Meduza, Xakep, Anti-Malware).
Debian	Repository blocked or inaccessible	RBC and Anti-Malware cited Debian as one of the affected cases.
Rust repository	Blocked or inaccessible	Mentioned as an example of false positives and restrictions (RBC, Anti-Malware).
Yocto / Zephyr / Buildroot / Artix	Partial inaccessibility	It appeared in reports of February network outages (Habr, Xakep).
Docker Hub	Geo-IP restriction by the service itself	Access from Russia was blocked by the platform in 2024 under sanctions; the restriction was later lifted (masterhost, Habr, CNews). The source was the platform, not RKN.

It is not about a single domain or a single incident. The causes vary, and it is important not to conflate them. Some restrictions originate from Russian regulatory mechanisms (TSPU filtering, Russia’s “technical means to counter threats,” a deep-packet inspection infrastructure operated by ISPs under RKN’s direction — and registry entries). Other restrictions come from foreign platforms complying with sanctions requirements (geo-IP restrictions). The symptoms may look similar to the end user, but these issues should be addressed differently.

Industry response

Redundancy. The primary response is redundancy. Developers and companies are moving critical projects to self-hosted solutions, setting up Git repository mirrors, and deploying caching proxies for packages. They are trying to eliminate dependence on a single external access point. Netopia and Kaspersky Daily both describe this strategy.

Alternative Platforms. The second response is platform diversification. GitLab CE, Gitea, and Forgejo are being considered as alternatives to GitHub. Domestically people talk much about the Russian-hosted alternatives — GitVerse, GitFlic, and RTK-Fenix. Even their advocates, however, acknowledge that no existing platform is a full replacement for GitHub.

Here is a table of the main platforms, with parameters particularly relevant to small teams and NGOs.

Platform	Hosting	Open Source	CI/CD	Notes for Distributed Teams
GitHub	Cloud (outside Russia)	No (SaaS)	GitHub Actions	Maximum integration and network effects, but a single external point of failure — the key risk.
GitLab CE	Self-hosted	Yes	Built-in	Full self-hosted setup; repository mirroring between servers is available on paid tiers.
Forgejo	Self-hosted	Yes	Forgejo Actions	Lightweight and actively developed; works well for small teams on a private VPS.
Gitea	Self-hosted / cloud	Yes	Gitea Actions	Minimal server requirements; straightforward backup.
GitVerse / GitFlic / RTK-Fenix	Russia	Partial / No	Yes	Local jurisdiction: a plus for accessibility within Russia, but a minus for projects with international contributors or sensitive data.

Resilience architecture. The third response is a shift from “circumvent censorship as it appears” to a deliberate resilience architecture. This goes beyond VPNs and proxies. The goal is to build workflows in which code, dependencies, and containers are available from multiple independent sources. Many teams will face additional costs and greater DevOps complexity but the alternative is to experience incidents one by one.

Recommendations for developers

There is no single universal solution, but the basic set of measures is clear already.

• Netopia and migration-focused industry publications recommend to mirror critical Git repositories and stop keeping the only working copy of your code on GitHub.
• Deploy a self-hosted Git platform for internal projects and backup access — GitLab CE, Forgejo, or Gitea are solid options.
• Set up a local cache or private dependency mirror for Python, Node.js, and container images if your project relies on external registries. The Docker Hub experience underlines how important this is.
• Separate your public-facing layer from critical infrastructure: open mirrors can stay on GitHub, while production builds and deployments should live in your own environment.
• Document access incidents and identify exactly where the connection breaks (DNS, TCP, TLS, or HTTP). This would help distinguish a platform-side sanctions restriction from network-level filtering inside Russia.

Mini-guide: where exactly is the connection failing?

Before changing your infrastructure, it makes sense to understand at which layer the failure occurs. Here is a basic diagnostic sequence (substitute the relevant host for github.com):

1) DNS — does the hostname resolve?

nslookup github.com   # or: dig github.com

2) TCP — does port 443 open?

curl -v --connect-timeout 10 https://github.com

3) TLS — where does the handshake break, and does a server response arrive? (requires openssl)

openssl s_client -connect github.com:443 -servername github.com

4) Route — where are packets being dropped?

traceroute github.com   # on Windows: tracert; mtr github.com is more informative

How to read the results:

• If the hostname does not resolve, or resolves to a suspicious IP — this looks like DNS-level interference.
• If the TCP connection establishes but openssl s_client drops immediately after the Client Hello (RST / “connection reset”), specifically when the real SNI is sent — this is a classic sign of DPI-based filtering by hostname.
• If the server returns no certificate when connecting from a Russian IP but works fine from a different IP — this looks more like a geo-restriction on the platform’s side.

You are welcome to send us the output of these commands for analysis.

Important: the commands above are diagnostic and safe. They do not circumvent any restrictions — they simply show where the connection breaks, so you can choose the right response. curl -v logs may contain headers and certificate details; do not publish them in full.

Mini-guide: mirrors and dependency caches

The idea is straightforward: place a local cache or mirror between your pip / git / docker client and the external registry. That cache continues to serve requests even when the external resource is unavailable. Here is a brief overview of proven solutions, meant to point you in the right direction.

• Python (PyPI). For team-level caching, use devpi or the lighter proxpi; for a full mirror, use bandersnatch. A comprehensive overview of all approaches is in the official PyPA guide, “Package index mirrors and caches.”
• Git. Keep your repository in multiple locations by adding an extra push URL, so that a single git push sends code to both GitHub and a backup platform. See the git remote documentation for the syntax.
• Containers (Docker Hub, etc.). Run a registry as a pull-through cache — see the “registry as a pull-through cache” recipe in the Distribution documentation. For a universal solution that manages private package repositories across multiple ecosystems at once (RPM, Debian, Python, containers), Pulp is worth considering.

All of the tools listed above are official and/or widely used across the industry. The right configuration depends on team size: a caching proxy is enough for two or three people; an organization running CI/CD will want a full mirror and a container image registry.

Implications for NGOs and civic tech projects

For non-profit, human rights, and media projects, the situation is more acute than for commercial businesses. Budgets are limited, but dependence on digital infrastructure is just as high. Losing access to repositories, packages, and images may not be a mere inconvenience. It can mean a real risk of services and internal tools going dark. Some practical recommendations:

• Do not tie your single point of access to one jurisdiction. Keep a working copy of your code in at least two independent locations, ideally in different countries, so that a block or sanctions on one side do not stop your work.
• Separate your public-facing layer from sensitive infrastructure. Open materials and mirrors can live on public platforms; internal tools, data, and build pipelines should live in a closed self-hosted environment with restricted access.
• Account for the different legal situations of your team members. If your team includes people both inside and outside Russia who face different levels of risk, set up access rules on a need-to-know basis. Not everyone should have full access to all infrastructure, and critical operations should be covered by more than one trusted person.
• Prepare your emergency plan. A simple document answering “what do we do if GitHub or PyPI goes down tomorrow?” should list backup mirrors, who is responsible for updates, and how to switch CI. This is far cheaper to prepare in advance than to make plans during an actual outage.
• Build resilience into grant budgets. A small VPS for a mirror and cache is not expensive, but it is precisely the thing that tends to get cut — until the first serious incident.

VPNs as a bridge

VPNs and proxies seem like an obvious answer, but they make a poor foundation for a production workflow. Here is why.

• Instability and unpredictability. Circumvention channels themselves become targets for restriction. What worked yesterday may not work today, and your process can crash at the worst possible moment.
• Poor compatibility with automation. CI/CD runners, package managers, and container builds are generally not designed to operate through an unreliable VPN. Timeouts, partial downloads, and corrupted caches produce hard-to-debug errors.
• Legal and organizational risk. For an organization, tying critical processes to circumvention tools introduces a separate layer of risk.

When VPNs are still justified:

• As a temporary bridge to pull down dependencies once and immediately place them in a local mirror.
• For a developer doing manual work through a UI — not for automation.
• As a backup channel while you set up a properly resilient architecture.

In other words, a VPN can buy you time. It does not replace the other solutions.

Strategic Perspective

Judging by the dynamics of 2026, the problem does not look temporary. First, Linux repositories were affected. Then GitHub. Then PyPI. That progression alone is enough to talk about a systemic deterioration in the accessibility of foreign development infrastructure in Russia (the reporting from Meduza, Anti-Malware, and Kod Durova make the same conclusion).

Even if some of these incidents turn out to be collateral damage from network filtering rather than direct blocks, the result for users is the same: development tools become less predictable and less reliable. The industry will therefore continue moving toward mirrors, self-hosted solutions, and ecosystem fragmentation — not because it is more convenient, but because there is no other way to build stable workflows anymore.