Resources for developers are becoming less and less available in Russia. What should developers do? Why VPN is not the solution? Analysis #8

In the “Greenhouse Analysis” section, we understand a specific problem, Internet censorship news in real time and tell:

• what's happening;
• how it works;
• how can you fight this

Any thoughts on the topic? Share with us!

Fill out a short form and tell us what you think about the new restrictions and how you can minimize the damage to VPN operators and ordinary users.

Briefly

In Russia, since the beginning of 2026, failures and restrictions have been accumulating that affect the development infrastructure: GitHub, Linux system repositories, separate repositories of the Rust and Debian ecosystem, and now PyPI. Meduza , RBC and Anti-Malware wrote about this.

In May 2026, the OONI project recorded a deterioration in the availability of GitHub from Russia. According to OONI data cited by Vorstka , the share of anomalous measurements of the Web Connectivity test on GitHub on Russian networks increased from approximately the background ≤4% to 10% on May 5, and on May 6–7 reached approximately 16%. This is the aggregated proportion of problematic measurements in the OONI Probe sample, not the proportion of "disconnected" users. Meduza and The Insider also talked about interruptions and complaints, and Skillbox Media wrote about symptoms such as unstable opening of pages, git clone failures and problems with raw files.

Roskomnadzor has officially stated that it does not restrict access to GitHub. The GitHub domain is indeed not blocked entirely, however, as noted by Vorstka and The Moscow Times , the register of prohibited information contains more than 130 individual pages of the service. Moreover, the number of such records in 2026 has increased significantly.

On June 1, 2026, the Durov Code publication reported that for the second day now it has been difficult to get to PyPI, the official repository of Python packages, from Russia. According to the publication, the connection to pypi.org is terminated at the TLS stage, which is reminiscent of the behavior of other resources that were previously blocked or filtered at the network level.

Roskomnadzor responded by saying that it does not restrict access to PyPI. Against this background, the industry is increasingly discussing the transition to mirrors, self-hosted Git platforms and backup dependency delivery channels, because the problem no longer looks like an isolated failure, but as a new norm for developers in Russia.

 Git is a system that helps programmers work with software source code. And PyPI is a directory of ready-made Python packages, that is, libraries and modules that programmers plug into their projects. For ordinary users, this may mean that some services, applications and sites will work worse or be unstable: updates may install with errors, certain programs may not start, and developers and companies will experience delays in releasing fixes, which will affect the cost and availability of programs.

Timeline of restrictions in 2026

The further you go, the more closely the events follow each other - and the more difficult it is to explain them with single “technical work”.

What's happening

The GitHub story didn't come out of nowhere. Back in February 2026, users and developers of Russian Linux distributions complained about the inaccessibility of git.kernel.org and related resources: Meduza , Xakep and Anti-Malware wrote about this. At the same time, problems were reported with the Debian and Rust repositories, as well as projects like Yocto, Zephyr, Buildroot and Artix Linux.

These restrictions do not only affect open source enthusiasts. The outage affected teams that use Linux repositories for enterprise development, building their own distributions, and updating infrastructure. The publications of Meduza , CNews and The Code directly mentioned that the difficulties also affected developers of Russian operating systems: Astra Linux, RED OS and Alt Linux.

In May, problems appeared with GitHub. OONI measurements and numerous user complaints show that access from Russia has become noticeably less stable. The explanations of the regulator and the platform are different: Roskomnadzor claims that it is not blocking anything, GitHub associates the problems with technical work to expand the infrastructure.

By the end of May, the problem became wider, with users reporting problems with DeepSeek and then with PyPI. In both cases, the connectionwas dropped at the TLS stage. This is important because this pattern is often described as a sign of filtering or blocking at the network level.

What OONI data shows

Below is the OONI Explorer graph for the Web Connectivity test for github.com from Russia for the period from April 1 to June 1, 2026. Each column shows measurements per day: green – “good”, yellow – “anomaly” (probable signs of interference), gray – “refusal”, red – “confirmed” (proven blocking with a block page).

Network connection test, github.com (Russia). Source: OONI Explorer , data for April 1 - June 1, 2026.

What can be seen on the graph

Almost all days in April and most of May are almost completely green: in normal mode, access to GitHub from Russia mostly works. A sharp exception is May 5–7 : it is on these days that the proportion of yellow segments (“anomaly”) increases noticeably. On May 5, anomalous measurements rise to about 15 out of ~159 per day (about 10%), and on May 6 they reach a peak of about 24 out of ~148 (about 16%). After May 7, the surge subsides, although isolated yellow segments also occur on subsequent days.

What's not on the chart

There are no red segments (“confirmed”) on all days. This is a key detail: OONI never recorded an automatically confirmed block - that is, a block page. The data speaks precisely of anomalies - probable but unproven interference, which is consistent with the cautious language of the media and with the denial of blocking by Roskomnadzor.

How to read a chart

The total number of measurements per day varies (from approximately 50 to 250), so it is not the absolute height of the yellow column that is indicative, but its share of all measurements of the day at the level of Russian networks. OONI itself emphasizes: an increase in the proportion of anomalies indicates a probable, but not guaranteed blocking - false positives are possible.

The signal is amplified when errors are of the same type (for example, a break at the TLS handshake stage) and are stable over time within one autonomous system (ASN). You can note that the number of measurements is gradually decreasing; this may indicate either a normal situation (reducing the number of checks) or the operation of “white lists”, in which sending OONI reports is impossible.

How to reproduce this test yourself

The graph is interactive and updated, so the current version and breakdown by operator (ASN) can be opened via a direct link with the parameters already entered: OONI Explorer - GitHub, RU, Web Connectivity . General page for the country with summary graphs - OONI Explorer: Internet Censorship in Russia .

You can take part in testing yourself. The easiest way is to install the OONI Probe application ( Android , iOS ) and regularly run tests from the device and network where you usually access the Internet. OONI asks that you consider the risks and not test sensitive sites without understanding the consequences. It's best to read their security section before testing.

How crashes happen

Not clear. There is no public evidence yet of a single reason that would explain all the failures at once. But from the already known cases described by Netopia and Anti-Malware , several working hypotheses emerge.

Hypothesis 1. Side effects of blocking and slowdowns targeting other services

In February 2026, a number of media outlets associated the unavailability of Linux resources with new Roskomnadzor algorithms used in the fight against Telegram. Meduza , Xakep and The Code wrote about this. If filtering is based on IP addresses, CDN subnets, TLS parameters, or other indirect characteristics, even completely neutral services for developers may come under attack.

Hypothesis 2. Increase in the number of targeted blocking of pages and resources within large platforms

The entire GitHub domain is not included in the registry of banned sites, but individual URLs and pages are blocked, and the number of such entries increases. “Vorstka” and The Moscow Times drew attention to this. This creates a situation in which the service seems to be “not prohibited,” but its availability for users in Russia is still gradually deteriorating.

Hypotzea 3. Technical vulnerability of modern development to any failures at the transport and application level

GitHub, PyPI, Docker Hub, system Git repositories, CI/CD pipelines and package managers are not independent tools, but a single supply chain of code and dependencies. SecurityLab and Netopia wrote about this. Even if the main site opens, a failure at the level of git clone, downloading release files, container images or Python packages already makes the workflow unstable.

Who says what

The regulator’s position remains the same: Roskomnadzor states that it does not restrict access to GitHub via PyPI . Formally, this allows the authorities to talk not about blocking, but about external or technical problems.

Some industry and media explanations point to network spillovers. The Durov Code publication assessed that GitHub and PyPI could be hit on a tangent due to blocking of CDN subnets like Fastly: pypi.org resolves to Fastly, and many Fastly ranges were blocked at that time. This is not conclusive proof, but the version fits well with known stories when infrastructure restrictions affected several seemingly unrelated services at once.

The most notable political statement came from the first deputy chairman of the State Duma Committee on Information Policy, Information Technologies and Communications, Anton Gorelkin, known for his censorship initiatives. He called on Russian developers to transfer projects from GitHub to alternative sites, including Russian ones, and warned that the service may become completely unavailable. At the same time, the deputy separately emphasized that he does not consider GitHub a “sabotage platform” and recognizes its value for the IT industry, as noted by Skillbox Media .

The reaction from the professional community is more pragmatic. Experts recommend not waiting for official recognition of the blocking, but building fault tolerance in advance: mirroring repositories, deploying self-hosted GitLab or Forgejo (an alternative to GitHub/GitLab), maintaining local package caches, and not keeping the only access point to source code outside the country. Such recommendations are found, in particular, in Netopia and in the Kaspersky Daily article about conclusions from the Docker Hub story.

Why is this important

For modern development, GitHub and PyPI are not just “sites.” GitHub remains the largest collaborative development platform, and PyPI remains the core package delivery infrastructure for Python, which is used in analytics, DevOps, backend development, cybersecurity, and automation. Therefore, even partial degradation of access quickly becomes a problem for business, education, NGOs and independent technical teams.

Small teams are especially vulnerable. A large company can still maintain its own solutions, but small studios, independent developers or public organizations often do not have such a backup infrastructure. As a result, they are the first to experience broken releases, inability to update dependencies, and additional costs for workarounds.

For the open source ecosystem, the problem is even broader. Restricting access to global repositories weakens the participation of Russian developers in international projects, complicates the publication of code and reduces the compatibility of local development with global practices. Ultimately, the separation of Russian developers from international resources will lead to inevitable degradation of the industry.

International context

Russia is not the first time that access to global development infrastructure has become a pressure point or has come under sanctions and regulatory restrictions. Several comparable stories help to see a pattern in what is happening, and not a one-time accident.

• Sanctional geo-restrictions on the part of the platforms themselves. In 2024, Docker Hub temporarily blocked access from Russian IPs, and GitHub previously restricted individual accounts under sanctions. Here the source of restriction is the foreign service, and not the local regulator.
• Complete lockdowns at the country level. In Iran, access to GitHub, GitLab and many package registries has been complicated for years by a combination of external sanctions and internal filtering. Developers rely heavily on mirrors and proxies.
• "The Great Firewall" In China, unstable access to GitHub and slow batch registries have long turned local mirrors (for example, corporate and university npm/PyPI-mirror) into a standard of engineering hygiene.

The general conclusion from these cases: where access to the global dev infrastructure becomes unpredictable, the one who survives is not the one who quickly “bypasses” the next block, but the one who has built several independent sources of code, packages and images in advance. It is precisely this logic that the Russian industry is moving towards.

Which services are already affected?

Below is a short map of services that have already encountered similar problems.

This is no longer about one domain or one incident. The causes of the problems are different, and it is important not to mix them up: some of the restrictions come from Russian regulatory mechanisms (filtering at TSPU, registry entries), and some come from the foreign platforms themselves that comply with sanctions requirements (geo-IP restrictions). A user's symptoms may look similar, but they may respond differently.

How the industry is reacting

Reservation

The industry's main reaction is reservations. Developers and companies are moving critical projects to self-hosted solutions, setting up Git repository mirrors and caching proxies for packages so as not to depend on one external access point. This strategy is described by Netopia and Kaspersky Daily .

Alternative platforms

The second response is to diversify platforms. Along with GitHub, GitLab CE, Gitea, Forgejo are considered, and in the Russian circuit, GitVerse, GitFlic, RTK-Phoenix and other local alternatives are more often discussed. However, even their supporters admit that GitHub does not yet have a full-fledged replacement.

To make it easier for you to compare options, below is a table of the main platforms with parameters that are important specifically for small teams and non-profit organizations.

Resilience Architecture

The third reaction is a transition from “bypassing locks after the fact” to a resilience architecture. It's no longer just about VPNs or proxies, but about building processes in which code, dependencies and containers are available from multiple independent sources. For many teams, this means additional costs and increased complexity in DevOps processes, but the alternative is to work in constant disaster mode.

What developers can do

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

• Mirror critical Git repositories and do not keep a single copy of production code on GitHub, as Netopia and industry publications on migration recommend.
• Deploy a self-hosted Git platform for internal projects and backup access - for example GitLab CE , Forgejo or Gitea .
• Raise a local cache or private dependency mirror for Python, Node.js and container images if the project depends on external registries. The importance of this approach is also indicated by experience with Docker Hub .
• Separate the public loop and critical infrastructure: open mirrors can remain on GitHub, while the working build and deployment can live in their own loop.
• Document access incidents and check where exactly the connection is broken - on DNS, TCP, TLS or HTTP, because this helps to distinguish platform sanctions restrictions from network filtering within Russia.

Mini-instructions: where exactly the connection breaks

Before changing your infrastructure, it's helpful to understand at what level the failure occurs. Basic sequence (substitute the desired host for github.com):

1) DNS - whether the name is resolved:

 nslookup github.com # or: dig github.com

2) TCP - is port 443 opened:

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

3) TLS - at what stage the handshake is broken and whether the server response is received (openssl must be installed):

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

4) Route - where packets are lost :

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

How to read the result:

• If the name does not resolve or resolves to a suspicious IP, this looks like DNS interference.
• If a TCP connection is established, but openssl s_client is terminated immediately after Client Hello (RST / “connection reset”), and precisely when transmitting real SNI, this is a classic sign of DPI filtering by host name.
• If the server does not issue a certificate from a Russian IP at all, but works with a change in IP, this is more like a geo-restriction on the part of the platform.

You can send us the results of running commands for analysis.

Important: the commands above are diagnostic and safe. They do not “bypass” restrictions, but only show where the connection is broken so that you can choose the right strategy. The saved curl -v logs may contain certificate headers and details - do not publish them in their entirety.

Mini-tutorial: mirrors and dependency caches

The idea is simple: put a local cache or mirror between your pip/git/docker and the external registry, which continues to work even when the external resource is unavailable. Let's briefly describe a few proven solutions, just to set the direction:

All of the tools listed are official or widely used in the industry. The specific configuration should be selected according to the size of the team: a caching proxy is enough for two or three people; for an organization with CI/CD, a full-fledged mirror and image registry makes sense.

What does this mean for NGOs and civil IT projects?

For non-profit, human rights and media projects, the situation is more acute than for business: the budget is limited, and the dependence on digital infrastructure is no less. Losing access to repositories, packages and images may not mean inconvenience, but the risk of stopping services and internal tools. Some practical tips:

• Don't tie a single access point to one jurisdiction. Keep a working copy of the code in at least two independent places, preferably in different countries, so that blocking or sanctions on one side does not stop work.
• Separate the public and sensitive circuit. Open materials and mirrors can live on public platforms, and internal tools, data and assembly can live in a closed self-hosted circuit with a limited range of access.
• Consider the different legal status of participants. If the team has people inside and outside Russia with different risks, access should be built according to the principle of the minimum necessary: ​​not everyone should have full access to the entire infrastructure, and it is better to duplicate critical actions between several trusted people.
• Describe the emergency scenario in advance. A simple document “what we do if access to GitHub/PyPI is lost tomorrow”: where are the backup mirrors, who updates them, how to switch CI. It's cheaper than dealing with it at the time of the accident.
• Build sustainability into your grant budget. A small VPS for a mirror and cache is inexpensive, but it is often what they save on - until the first serious failure.

Why VPN is not a solution, but a temporary bridge

VPNs and proxies seem like the obvious answer, but they're not a good fit as the basis of your workflow, and here's why.

• Instability and unpredictability. Bypass channels themselves become subject to restrictions; what worked yesterday may not work today, and the assembly breaks at the most inopportune moment.
• Poor compatibility with automation. CI/CD runners, package managers and container builds are usually not designed to work over an unstable VPN: timeouts, partial downloads and broken caches lead to subtle errors.
• Legal and organizational risks. For an organization, tying critical processes to bypass tools is a separate risk.

VPN is still justified:

• as a temporary bridge to pull together dependencies one-time and immediately put them in a local mirror;
• for manual operation of a person with an interface (not for automation);
• as a spare channel while setting up a normal fault-tolerant architecture.

That is, a VPN helps you gain time, but does not replace other solutions.

What to do for those who don't write code

It would seem that what non-programmers have to do with it. But our work often depends on software that pulls packages from PyPI or images from Docker Hub under the hood, even if the employees themselves don’t think about it. A few simple steps (choose the ones that apply to you):

• Ask your developers if the project has backup mirrors and what will happen to the site or tool if access to external resources is lost tomorrow.
• Save working versions. If you use a ready-made tool, keep an offline copy of the installer or image that definitely works - you can update later, but it’s difficult to restore “from scratch” during blocking.
• Don't reinstall "just in case". During failures, reinstalling software that pulls components from an inaccessible registry may leave you without a working tool at all.
• Build sustainability into your planning. It is useful to know in advance which services are critical and to have a backup option in case of unavailability. Well, make backup copies, of course.

What's next

Judging by the dynamics of 2026, the problem does not look temporary. Сначала под удар попали Linux-репозитории, затем GitHub, затем PyPI, и уже этого достаточно, чтобы говорить о системном ухудшении доступности зарубежной инфраструктуры разработки в России. Это подтверждают публикации Meduza , Anti-Malware и «Кода Дурова» .

Даже если часть этих инцидентов объясняется не прямой блокировкой, а побочными эффектами сетевой фильтрации, для пользователя результат один и тот же: инструменты разработки становятся менее предсказуемыми и менее надёжными. А значит, отрасль будет и дальше двигаться к зеркалам, self-hosted-решениям и фрагментации экосистемы — не потому, что так удобнее, а потому, что иначе уже нельзя строить устойчивые процессы.

Sources

GitHub

• «В России начали ограничивать доступ к GitHub». «Вёрстка»
• «В России начали ограничивать доступ к GitHub». The Insider
• «GitHub стал плохо открываться в России. Роскомнадзор утверждает, что не блокирует его». Meduza
• «Блокировка GitHub в России: что известно». Skillbox Media
• «GitHub не ограничивается, заявили в Роскомнадзоре». «Ведомости»
• «Роскомнадзор заявил, что не блокирует GitHub». «Газета.Ru»
• «В России начали блокировать одну из крупнейших платформ для программистов». The Moscow Times
• «Горелкин призвал российских разработчиков переносить проекты из GitHub». «Ведомости»
• «Депутат Горелкин призвал разработчиков переходить на российские Git-платформы». Anti-Malware
• «Ухудшение доступности зарубежных сервисов и риски для разработки». SecurityLab
• «Доступность GitHub в России: что делать командам и как готовить запасной репозиторий». Netopia

PyPI и DeepSeek

• «Сайт китайского ИИ-сервиса перестал открываться без использования VPN». «Код Дурова»
• «В России зафиксированы проблемы с доступом к PyPI». «Код Дурова»
• «Роскомнадзор не ограничивал доступ к Python». «Осторожно, новости»
• «Роскомнадзор: доступ к Python Package Index не ограничивается». Хабр

Linux-репозитории и более ранние ограничения

• «Разработчики российских ОС не могут получить обновления с серверов Linux — всё из-за Роскомнадзора». Meduza
• «Россияне внезапно остались без обновлений Linux и Windows. Зацепило даже отечественные Astra Linux, «Альт» и «Ред ОС»». CNews
• «Хотели замедлить Telegram, а уронили Linux: как «чёрные ящики» РКН мешают работать айтишникам». Xakep
• «Блокировка обновлений Linux и Windows в России». The Code
• «Сводка о недоступности репозиториев Debian и Rust для российских пользователей». Anti-Malware
• «Российские разработчики столкнулись с ограничениями доступа к репозиториям». RBC

Docker Hub

• «Docker Hub стал недоступен для пользователей из России». masterhost
• «Уроки истории с Docker Hub: как снизить зависимость от внешних реестров». Kaspersky Daily

Данные мониторинга

• «OONI Explorer: Internet Censorship in Russia». OONI
• «OONI Explorer — Web Connectivity, github.com, Россия (апрель–июнь 2026)». OONI

The material is being updated!

Кстати, рассылку сложнее заблокировать. Так что каждую неделю мы рассказываем о самом важном в области технологий и безопасности: как уберечь свои данные, финансы и себя в условиях блокировок, шатдаунов и финансовых ограничений. Subscribe!