Foreign Git Platforms Are a Risk for Russian Companies. Here’s Why

When discussing foreign Git platforms such as GitHub, GitLab, or Bitbucket, debates usually focus on features, pricing, and usability. For a Russian company, however, a different question comes first: what happens if access is simply revoked? Or if critical vulnerabilities can no longer be patched? This is not a hypothetical concern. It has already happened, and more than once.

In this article, we will examine two common deployment models for foreign Git platforms – cloud and self-hosted – along with the risks associated with each. We will also take a candid look at the counterarguments because they are real, and ignoring them would be a mistake.

Two Threat Models

Before diving into specifics, it helps to establish the framework. Risks associated with foreign Git platforms fall into two fundamentally different categories depending on how the platform is used:

• Cloud (SaaS): “They can cut off our access.” Your code physically resides with the vendor, and the vendor decides whether you can reach it.

• Self-hosted: “They can prevent us from maintaining and improving it.” Your code resides on your infrastructure, but you remain dependent on the vendor for updates, security patches, and support. If the platform is proprietary, you may not even be able to inspect what is happening under the hood.

These two threat models require different mitigation strategies. That is precisely why domestic or open source solutions with ownership of the code base are so attractive: they address both vectors simultaneously. But first, let us look at each scenario in detail.

Scenario 1: Cloud – When You Do Not Control the Switch

Sanctions Risk Is Not a Hypothesis

The strongest argument here is also the most practical: this has already happened. GitHub belongs to Microsoft and operates under U.S. jurisdiction, meaning it must comply with OFAC requirements and export-control regulations such as EAR and ITAR.

As early as 2019, GitHub began restricting accounts belonging to developers in sanctioned regions, including Crimea, Iran, Syria, Cuba, and North Korea. Affected users lost access to private repositories, Marketplace services, and paid organizations. One revealing detail: VPNs did not help because repositories themselves were restricted, and users could not download or export them before the lockout. The platform analyzed IP addresses and payment histories, and even a simple trip to a sanctioned region could trigger restrictions.

In April 2022, the restrictions expanded further. GitHub froze accounts linked to sanctioned Russian organizations, including profiles associated with Sber and Alfa-Bank, as well as several individual developers who received notices suggesting that their accounts might be connected to sanctioned regions.

The conclusion is straightforward: blocking criteria are determined by the vendor under pressure from its regulator, and those criteria can change or expand at any time. Today restrictions may target specific organizations. Tomorrow the definition may become broader. You have no control over that process.

The Data Physically Resides Abroad

Even if access is never restricted, compliance concerns remain. Code and related data stored on GitHub.com or GitLab.com reside on foreign servers. For many Russian companies, that creates a direct regulatory conflict.

• Federal Law No. 152-FZ requires personal data belonging to Russian citizens to be localized within Russia. Such information can easily find its way into repositories through configuration files, test dumps, logs, or comments.

• Requirements become even stricter for state-owned enterprises, critical information infrastructure operators, and organizations handling classified information, in some cases extending to outright prohibitions on foreign software and overseas hosting.

For the enterprise sector, this is not an abstract concern. It affects audits, compliance reviews, and potential penalties.

Hidden Dependence on External Infrastructure

Even when GitHub itself is functioning normally, organizations remain dependent on a web of supporting external services: authentication providers, CDNs distributing static assets and artifacts, package registries such as npm and PyPI, container registries, Actions runners, and dependency mirrors.

Any link in that chain can fail independently of the core platform due to sanctions, regional restrictions, or unrelated outages. Suddenly Git repositories remain accessible, yet builds and deployments stop working. This is a classic supply-chain problem. You depend not on one service but on many, and you control none of them.

Scenario 2: Self-Hosted – The Code Is Yours, Control Is Not

At first glance, installing GitLab or another platform on your own infrastructure appears to solve the problem. The code lives on your servers, and nobody can lock it remotely. That is partially true. However, a different class of risks emerges, particularly problematic for enterprise environments.

Support and Ownership of the Code Base

For large companies, vendor support is not a bonus. It is part of the SLA. When a production environment serving 5,000 developers breaks, organizations need a vendor capable of responding.

A foreign vendor can terminate support for Russian customers at any moment due to sanctions or corporate policy. At that point, ownership of the code base becomes critical. A domestic developer that controls its own source code can continue supporting and evolving the product independently. That is what import independence means in practice: not “we deployed open source and hope for the best,” but “there is an organization responsible for the product and capable of controlling its future.”

Security Patches May Simply Stop Arriving

This is, in my view, the most underestimated risk associated with self-hosted foreign software. Imagine the platform continues running on your infrastructure, but the vendor stops delivering updates to your region by cutting access to update repositories, licensing servers, or patch-distribution channels. You become frozen on the current version.

Then a new CVE appears – perhaps a critical remote code execution vulnerability affecting your platform version – and there is no fix available to you. Suddenly you are operating with a publicly known vulnerability at the very heart of your development infrastructure. For a system storing all of your source code, that is close to a worst-case scenario.

Licensing Risks

Licensing introduces another layer of exposure. Enterprise editions of foreign platforms typically rely on subscription models, creating several points of failure. Licenses may not be renewed, may be revoked, or may simply become impossible to pay for due to payment-system restrictions affecting Russia. An expired license can reduce functionality or disable premium capabilities on which critical workflows already depend.

A Conflict of Jurisdictions

Underlying all these risks is a fundamental reality: vendors must comply with the laws of their home countries.Those laws may directly conflict with your interests or with Russian regulations. When the demands of a foreign regulator clash with the interests of a Russian customer, the vendor will choose the regulator. Otherwise, the vendor itself risks legal consequences. In that equation, the customer becomes the variable that gets sacrificed.

And Now for the Counterarguments

Foreign platforms have significant strengths.

GitHub and GitLab have been developed for years by large engineering teams. They are mature products with deep functionality: advanced CI/CD, AI assistants, code scanning, refined code-review workflows, and thousands of integrations available out of the box. Domestic platforms are catching up rapidly, but in some areas the feature gap remains real. That remains a genuine downside of migration.

There is another argument that often goes unspoken in discussions about risk, and it has nothing to do with features or pricing. GitHub is not merely a repository-hosting platform. It is where the global technology community lives. Millions of open source projects, architectural discussions in issues, pull requests from engineers at leading companies, vulnerability discussions around CVEs – these are not platform features. They are a living ecosystem where developers grow professionally. Teams working exclusively inside isolated internal environments inevitably begin to lag behind, not because of tools but because of mindset. New patterns, approaches, and libraries that become global standards arrive late or not at all. This is not paranoia in reverse. It is simply how professional development works.

Complete isolation from foreign platforms solves the access problem but creates another one: an engineering vacuum. The mature approach is not full withdrawal but separation. Critical development environments containing source code and CI/CD pipelines belong on an independent domestic platform. Personal participation in the global community can continue wherever that community exists.

These arguments are real and should not be hidden. But on closer inspection, most of them revolve around convenience, pricing, and features. In other words, operational efficiency.

The arguments for independence address something different: sanctions, jurisdiction, patch availability, and control over the switch itself. These are existential risks rather than usability concerns. That is the key asymmetry. Convenience can be compensated for through investment, time, and engineering effort. Loss of access to source code during a critical moment cannot.

The decision therefore is not about what is universally better or worse. It is about which risk you cannot afford to accept. A small startup running a public project may reasonably favor GitHub because speed, community, and free features matter more while sanctions-related risks remain theoretical. For a government entity, critical infrastructure operator, or large enterprise managing sensitive code, the calculation looks entirely different. The cost of the risk dwarfs any savings gained from convenience.

Another common argument is: “We will use self-hosted open source tools such as GitLab CE, Gitea, or Forgejo. They are free, their code is open, and that gives us independence.” It is a strong argument, but not an absolute one. First, open source projects can change licenses or place functionality behind commercial editions. GitLab, for example, reserves a substantial portion of its capabilities for proprietary Enterprise editions and its SaaS offering, and that boundary changes at the vendor’s discretion. Second, downloading and installing software is not the same as having support. When a production system fails, responsibility for the incident falls on you. Open code eliminates auditing concerns and reduces update-blocking risks, but it does not answer the question of who will maintain and develop the platform over time.

Where GitFlic Fits In

If everything discussed above can be reduced to a single criterion, it is this: the platform should be owned by an organization operating within your jurisdiction and capable of supporting and developing it independently. That brings us to GitFlic, which addresses both threat models simultaneously for an interesting reason.

GitFlic is not a fork of GitLab, Gitea, or any other platform. It is an independent platform written from scratch in Java. At first glance, that sounds like a technical detail. In discussions about independence, however, it is crucial. A fork inherits not only code but also the fate of its upstream project: architectural decisions, licensing policies, and strategic direction. When an upstream project moves functionality into proprietary editions or changes its licensing model – as GitLab has done in the past – the fork becomes reactive, either following those decisions or diverging at significant cost.

A platform built from scratch avoids that dependency. Its developers control the entire code base and determine its future themselves.

The choice of Java rather than Ruby on Rails, the foundation of both GitHub and GitLab, is also more than a cosmetic decision. It reflects a focus on stability and performance under the heavy workloads typical of enterprise environments.

Regulatory requirements are also addressed. GitFlic is included in Russia’s domestic software registry, developed without foreign participation, and forms part of the Astra Group ecosystem. It is available both as a cloud service and as a self-hosted deployment on customer infrastructure. In other words, it covers both scenarios discussed in this article: organizations seeking SaaS without the risk of external lockouts and organizations requiring complete on-premises control backed by a vendor that owns the code.

Functionally, it goes beyond basic Git hosting. The platform includes CI/CD, role-based access control, package and artifact registries – effectively a domestic alternative to Nexus or Artifactory – as well as security tools. This matters when discussing maturity because migration from a foreign platform should not require sacrificing essential functionality.

I am not claiming that GitFlic replicates every GitLab feature one-for-one. A realistic assessment recognizes that foreign giants remain stronger in certain specialized areas. Yet by the primary criterion explored in this article – who controls the switch and who owns the code – GitFlic provides a compelling answer.

The Bottom Line

For a Russian company, choosing a foreign Git platform is not really about whether it works today. Most likely, it does. The real question is that at any moment, decisions about your access, patches, and functionality are being made outside your organization and outside your jurisdiction.

The two threat models discussed here – “access can be cut off” in the cloud and “maintenance can be blocked” in self-hosted deployments – can both be addressed through a platform whose code base is owned by an organization operating within your jurisdiction and capable of supporting and developing it independently. This is not about choosing domestic technology for its own sake. It is about keeping control of the switch.

That trade-off used to be real. Independence often came at the expense of convenience and functionality. Today, that is increasingly a false dichotomy. Mature local platforms can handle core development workflows without forcing organizations to choose between team productivity and control over their own code.

If that is the case, choosing independence stops being a sacrifice and starts looking like common sense.

Eduard Tikhomirov,

Chief Technology Officer, GitFlic