Two signals arrived in close succession: Mitchell Hashimoto — creator of Terraform and Ghostty, 18-year GitHub loyalist — announced he is migrating his project off the platform after documenting near-daily outages. Then GitHub disclosed a security breach affecting approximately 3,800 internal repositories. Together they raise a question most development teams have not seriously asked: what is our actual exposure if this infrastructure fails or is compromised?
Two things happened in close proximity that individually might be dismissed and together are harder to ignore. Mitchell Hashimoto — co-founder of HashiCorp, creator of Terraform and Vagrant, and one of the most respected figures in developer tooling — announced that Ghostty, his terminal emulator project, is leaving GitHub. He had been a daily GitHub user for 18 years. His reason was not philosophical. He had been keeping a journal of outages and their operational impact, and described the disruptions as happening "almost every day." His specific complaint was not with Git itself but with the infrastructure GitHub has built around it: issues, pull requests, and Actions.
Around the same time, GitHub confirmed a security breach. Attackers compromised approximately 3,800 internal GitHub repositories after an employee installed a malicious Visual Studio Code extension. The cybercrime group TeamPCP obtained valid access tokens and exfiltrated internal source code, then advertised the data on dark-web forums for $50,000. GitHub rotated credentials and isolated the compromised machine. The company reported no confirmed impact on customer repositories or enterprise environments. The broader campaign involved malicious open-source packages — including a compromised PyPI package — designed to steal SSH keys, cloud credentials, and vault secrets from developer workstations.
Neither event alone demands a response. Together, they raise a question worth asking carefully: for teams whose development workflow depends on GitHub's ancillary services, what is the actual business exposure if that infrastructure degrades or is compromised?
What Hashimoto's decision signals
The significance of his departure is not that one developer moved a project. It is the profile of the developer and the specificity of the complaint. Hashimoto described his attachment to GitHub as "irrationally personal" — the kind of loyalty that does not break easily. He kept a journal. He tracked operational impact. His conclusion, after eighteen years, was that the disruptions to PR review and CI/CD had become frequent enough to impair actual work.
His framing is important: the problem is not Git. Git is distributed, portable, and reliable. The problem is the layer GitHub has built on top — the issues system, the pull request workflow, the Actions CI/CD runner, the notification infrastructure. These are proprietary services that have no direct equivalent when you leave the platform. Teams that use GitHub deeply are not just hosting their code there; they are running significant parts of their development operations on GitHub's proprietary infrastructure.
That infrastructure dependency is the real risk exposure. Outages that knock out GitHub Actions stop CI/CD pipelines. Outages to the pull request system stop code review. For small teams with no redundancy, a multi-hour disruption is not an inconvenience — it is a work stoppage.
The security incident and the supply chain pattern behind it
The breach itself targeted GitHub's internal repositories, not customer code. The attack vector — a malicious VS Code extension installed by an employee — is part of a documented and growing class of supply chain attacks that target developer toolchains specifically. The developer workstation is now a primary target because it holds access tokens, cloud credentials, SSH keys, and source code in a single location that is typically less hardened than production infrastructure.
The TeamPCP campaign that hit GitHub ran the same playbook against open-source package ecosystems simultaneously. A compromised PyPI package — the Python package index that millions of projects depend on — was used to steal SSH keys and cloud credentials from developer machines. This is the "poisoned package" attack pattern: rather than attacking production systems directly, attackers inject malicious payloads into trusted, widely-used libraries so that downstream developers automatically download and execute tainted code during routine installs and updates. In the npm ecosystem, which underpins most JavaScript and Node.js development, attackers have phished maintainer accounts and compromised CI/CD pipelines to release poisoned versions of popular libraries — packages that run install scripts automatically when a developer runs a standard dependency update. WordPress plugin distribution follows the same pattern at a different layer: a popular plugin with a vulnerability or a compromised maintainer account becomes a delivery mechanism for backdoors across thousands of downstream sites.
GitHub's public position — that no customer data was confirmed affected — is accurate as far as it goes. Internal repositories can contain service architecture, security configurations, and tooling that reveals structural information about how customer systems are organized. The more important takeaway for development teams is not the specific incident but the attack surface it illustrates: IDE extensions, package dependencies, and CI/CD tooling are active attack vectors. Every team that installs VS Code extensions without vetting them, pulls npm packages without auditing, or runs third-party GitHub Actions without reviewing their source code is exposed to the same class of attack regardless of which platform they use.
The infrastructure beneath GitHub
Not all of what gets reported as a "GitHub outage" originates inside GitHub. GitHub depends on Cloudflare for its CDN layer and DDoS protection, which means Cloudflare's own reliability directly affects GitHub's uptime. Cloudflare has had a documented series of significant outages since 2019: BGP routing failures that took down GitHub, Amazon, and Google simultaneously; a code release error that invalidated service tokens for 121 minutes; a DNSSEC signature expiration that caused DNS resolution failures across a large portion of internet traffic; and a November 2025 incident caused by a ClickHouse database permissions bug that affected roughly one in five web pages globally for approximately six hours, taking down platforms including Zoom, Spotify, Coinbase, and ChatGPT.
This matters for how to interpret Hashimoto's complaints. Some portion of the near-daily disruptions he documented are likely cascade failures originating in Cloudflare or other upstream providers, not failures that GitHub's engineering team could have prevented. That does not reduce the impact on development work — a multi-hour CI/CD outage costs the same whether the root cause is GitHub's code or their CDN provider's configuration error. But it does change the analysis for anyone evaluating alternatives. GitLab, Bitbucket, and Codeberg also sit on CDN and DNS infrastructure with their own failure modes. Moving platforms addresses some reliability risk and changes none of the upstream infrastructure risk.
The practical conclusion from the Cloudflare data is that any platform relying on a centralized CDN layer is subject to cascading outages from that layer. Teams that need high availability for their development workflows — especially CI/CD pipelines that block deployments — should build for the assumption of periodic platform unavailability, not for the assumption of platform reliability. That means local runners, fallback pipelines, or build processes that can operate partially without external services.
The alternatives, compared
GitHub is not the only option for hosted code collaboration, and the alternatives have matured significantly. The comparison worth making is not which platform has the most features but which one matches a given team's actual dependencies and risk tolerance.
GitLab is the most complete alternative for teams that use GitHub deeply. It offers hosted and self-hosted options, a full CI/CD system, issue tracking, merge request workflows, and container registry — the full stack that GitHub provides, under one roof. GitLab's self-hosted option gives teams complete control over their infrastructure, which eliminates platform-level reliability and breach risk at the cost of operational overhead. The hosted version (GitLab.com) is broadly comparable to GitHub in reliability posture, without being significantly better or worse. Migration from GitHub is well-documented; the tooling exists.
Bitbucket, owned by Atlassian, is the natural fit for teams already running Jira, Confluence, or other Atlassian products. The integration between Bitbucket Pipelines and Jira is tighter than what GitHub offers natively. For teams not in the Atlassian ecosystem, Bitbucket offers less differentiation. Its free tier supports small teams; the CI/CD system (Pipelines) is capable but less extensible than GitHub Actions or GitLab CI.
Forgejo and Gitea are lightweight, open-source Git hosting platforms designed for self-hosting. Forgejo is a community fork of Gitea with no corporate backing, making it a fully independent option. Codeberg is a non-profit instance of Forgejo hosted in Europe, free to use, with GDPR-compliant data handling. For teams with a principle around open infrastructure or data sovereignty, Codeberg is a credible option. For teams without the operational capacity to run their own server, Forgejo and Gitea require more setup than most small businesses will want to maintain.
Azure DevOps and AWS CodeCommit offer code hosting within their respective cloud ecosystems. For teams already running significant infrastructure on Azure or AWS, these provide tight integration with build pipelines, identity management, and deployment tooling. Neither has the open-source community or third-party integration ecosystem that GitHub or GitLab has built.
What this means in practice for most teams
The short answer for most small development teams is: do not migrate reactively. GitHub's customer-facing repositories have not been compromised in the incidents described, and the platform remains the largest code collaboration ecosystem in the world, with the integrations, documentation, and community that entails. Migrating under pressure, without a clear operational reason, typically creates more risk than it removes.
The more useful response is to audit the actual dependency. Teams that use GitHub primarily as a Git remote — storing code, running occasional Actions jobs — have low lock-in and low migration cost. Teams that have built their development workflow heavily on GitHub Issues, Projects, Actions, Packages, and Dependabot are more exposed to platform risk and have a longer migration path if they ever need one. Understanding which situation you are in is the first step.
For new projects and teams that have not yet committed deeply to any platform, the current environment makes it worth evaluating GitLab alongside GitHub from the start. The feature gap has narrowed significantly, and starting with more portable infrastructure habits — keeping CI/CD configuration in code, using standard issue formats, avoiding deep GitHub-specific API integrations — costs little and preserves options.
The operating implication
Developer infrastructure carries vendor risk the same way CRM, payment processing, and email do. Most small businesses think carefully about what happens if their payment processor goes down or their email provider has an outage. Fewer think as carefully about what happens if their code hosting platform has a multi-hour disruption during a deployment window, or if the CI/CD system that runs their automated tests is unavailable when a critical fix needs to ship.
Hashimoto's departure is not a call to action for most teams. It is a signal from a credible observer that the reliability assumptions baked into a default platform choice deserve periodic review. The security breach is a reminder that developer workstations, IDE extensions, and package dependencies are now active attack surfaces — a fact that applies regardless of which platform a team uses to host their code. The combination is a prompt to ask the question, not necessarily to change the answer.