Skip to content

IPFS Loses Its Core Maintainers. What Happens Next?

Karify98 & Amy 🌸·
Cover Image for IPFS Loses Its Core Maintainers. What Happens Next?

On August 24, Shipyard β€” the engineering team behind much of IPFS's core infrastructure β€” announced it will halt all IPFS work on September 30, 2026, after Protocol Labs declined to renew its funding. IPFS itself isn't going away, but the announcement raises a hard question: how does a decentralized protocol survive when the one team maintaining it walks out the door?

IPFS is a content-addressed storage protocol: a file is found by its own hash, not by whichever server hosts it. Protocol Labs created IPFS, but Shipyard is the team that actually maintained the implementations and public gateway the community uses every day. That entire layer runs on libp2p.

What's happening

Per the official blog post, Shipyard will stop IPFS "engineering, maintenance, and infrastructure operations" on September 30. Specifically:

  • Projects losing dedicated maintainers include Kubo (the Go implementation), Helia (JavaScript), Boxo, Rainbow, IPFS Desktop, IPFS Companion, Service Worker Gateway, IPFS Check, and others.
  • Shipyard's contributions to upstream go-libp2p and js-libp2p will cease.
  • Shipyard will stop operating public infrastructure: ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, the bootstrap nodes, and the Wikipedia-on-IPFS cluster.

The notable part: Protocol Labs β€” which owns the domains and infrastructure β€” will decide what happens to them next. Shipyard was the operator, not the owner. The post also highlights the team's most recent achievement: re-architecting the gateways to handle roughly 3Γ— more traffic while cutting operating and maintenance costs by about 80%.

IPFS isn't dying, but its core maintainers are leaving

On Hacker News, people rushed to correct the headline: this is not "IPFS shutting down." IPFS is an open protocol and the network keeps running. According to some comments, the IPFS Foundation will shift to funding individual maintainers through grants instead of a centralized team.

But that distinction doesn't soften the problem. One maintainer running production asked the right questions, none of which have answers: after September, who triages security reports and ships fixes for Kubo, Boxo, and Helia? Who cuts releases, or should operators freeze current versions and plan around that? Who runs ipfs.io and dweb.link day to day?

A grant to an individual is not the same as a named owner with commit rights and a release process. That's the gap this announcement leaves behind β€” and it's bigger than it looks.

Why a decentralized protocol is still fragile

The paradox is this: IPFS is decentralized at the data layer but centralized at the human layer. When a single team owns most of the main implementations and the public gateways, the bus factor of the whole ecosystem is exactly the size of that team.

This is the old open-source problem: the software is free, but maintainers have to be paid from somewhere. When that somewhere is a single company, the whole ecosystem leans on that company's budget decisions. HN commenters also point out that Cloudflare and Brave previously walked away from IPFS β€” a sign that demand hasn't been enough to fund its infrastructure.

For developers building on IPFS, the consequence is a risk problem: if your app depends on public gateways or a specific implementation, you need a fallback plan before September.

What to Know

  • Don't confuse "Shipyard leaving" with "IPFS dying." The network keeps running and the protocol stays open. But "open" is not the same as "maintained" β€” those are two different things.
  • Audit your dependencies. If you use public gateways like ipfs.io or dweb.link in production, stop treating them as infinite. Self-host a gateway or run your own nodes if they sit on a critical path.
  • Check the bus factor. Ask directly: if the main provider stops tomorrow, who patches the library you depend on? For IPFS, that answer isn't clear yet.
  • Watch the alternatives. The community points to Iroh (iroh.computer), built by former IPFS and Protocol Labs engineers, as a peer-to-peer path with a more sustainable business model. It's not a drop-in replacement yet, but it's worth tracking.

The Shipyard story is a reminder of an uncomfortable truth about open infrastructure: a protocol's decentralization doesn't automatically extend to its operations layer. A network can survive a node leaving, but it wobbles when the single team maintaining its software and gateways walks away. Before September 30, anyone betting on IPFS should answer that question β€” with a concrete plan, not hope.


Content assisted by AI (Amy 🌸). Reviewed by the author.

Related Posts