Glonce

Shipyard winds down its IPFS work as Protocol Labs ends funding

infrastructureThe Glonce editorsHacker News🔥69Glonce rating69Impact50Novelty35Relevance65Surprise65Players55Credibility85
Shipyard winds down its IPFS work as Protocol Labs ends funding

Shipyard, the organization responsible for IPFS-related engineering, maintenance and infrastructure operations, says Protocol Labs has told it that it will not renew Shipyard's funding. As a direct result, Shipyard is winding down its IPFS work, with its final day on the project set for September 30, 2026. Protocol Labs has backed Shipyard for a bit over two years; in the same post, Shipyard says it has spent three years helping shape the modern IPFS ecosystem. No reason is given for Protocol Labs' decision, and no dollar figure is attached to the funding that is ending.

Shipyard frames its work as building 'more resilient, self-sovereign technology' for IPFS, a protocol built on the idea that content should be addressed by what it is rather than where it is hosted. Among the things it says it shipped: inbrowser.link, which delivers verifiable websites and downloads directly in the browser; a re-architecture of IPFS gateway infrastructure that Shipyard says lets it handle about 3 times more traffic than before while cutting operating and maintenance costs by around 80 percent; HTTP-native approaches to IPFS meant to simplify deployment and reduce operating costs compared with traditional libp2p-based hosting; and ongoing maintenance of the core implementations, libraries and public infrastructure the IPFS ecosystem relies on daily. Shipyard says it will not get to finish other work it had planned, including simpler HTTP-native implementations, more resilient and sustainable content routing, support for large native SHA-256 objects, and pseudonymous hosting and retrieval through Tor and onion services.

Shipyard spells out what its exit means in practice. Projects it maintains, including Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check and others, will no longer have a dedicated maintainer handling new features, bug fixes, releases or long-term stewardship. Shipyard's contributions to upstream projects such as go-libp2p and js-libp2p will stop, and its work on IPFS specifications, standards and broader ecosystem coordination will come to an end. Shipyard will also stop operating public infrastructure it currently runs, including the ipfs.io and dweb.link gateways, check.ipfs.network, delegated-ipfs.dev, the IPFS bootstrap nodes, collaborative cluster infrastructure such as Wikipedia-on-IPFS, and related services. Protocol Labs owns the domains and infrastructure involved and will decide what happens to them next.

Shipyard says it will stay available through the end of September 2026 to help any maintainer or infrastructure operator who depends on its work make the transition, and that its goal for the coming weeks is to leave the IPFS ecosystem in the best possible position it can. No successor maintainer or organization is named for any of the affected software projects, and no date is given for when the public infrastructure Shipyard is stepping away from will actually stop working, only that Protocol Labs will decide its future.

Key facts

  • Protocol Labs, which has backed Shipyard for a bit over two years, told the organization it will not renew that funding, so Shipyard is winding down its IPFS-related engineering, maintenance and infrastructure operations.
  • Shipyard's final day of IPFS-related work is September 30, 2026, though it says it will stay available through the end of that month to help with the transition.
  • Projects Shipyard maintains, including Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check and others, will lose their dedicated maintainer, and Shipyard's contributions to upstream projects such as go-libp2p and js-libp2p will stop.
  • Shipyard will stop operating public infrastructure including the ipfs.io and dweb.link gateways, check.ipfs.network, delegated-ipfs.dev, the IPFS bootstrap nodes and the Wikipedia-on-IPFS cluster; Protocol Labs, which owns the domains and infrastructure, will decide their future.
  • Shipyard says a re-architecture of its IPFS gateway infrastructure let it handle about 3 times more traffic while cutting operating and maintenance costs by around 80 percent.

Why it matters

Shipyard describes its mission as helping build 'more resilient, self-sovereign technology' for IPFS, a protocol built on the idea that content should be addressed by what it is rather than where it is hosted. It has served as IPFS's de facto engineering team, running public gateways and bootstrap nodes, maintaining core client libraries, and doing much of the standards and coordination work behind the protocol. Losing that funding removes dedicated maintenance from infrastructure that, by Shipyard's own account, other maintainers, infrastructure operators and projects depend on, and Shipyard says the practical implications extend well beyond the organization itself.

Who it affects

Anyone who maintains software or operates infrastructure built on Shipyard-maintained projects, including Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway and IPFS Check, loses that dedicated support. So do users of the public gateways and bootstrap nodes Shipyard runs, such as ipfs.io, dweb.link, check.ipfs.network and delegated-ipfs.dev, and collaborative infrastructure like the Wikipedia-on-IPFS cluster. Upstream libp2p projects that received Shipyard's contributions, go-libp2p and js-libp2p among them, are affected too. Protocol Labs, as owner of the domains and infrastructure, inherits the decision of what becomes of them.

How to use it

There is no product or price here, only a deadline. Shipyard says anyone who maintains software, operates infrastructure, or relies on work it has been responsible for should reach out before its IPFS-related work ends on September 30, 2026. It says it will answer questions, provide context and help make the transition as smooth as it reasonably can through the end of that month.

How solid is it

The account comes entirely from Shipyard's own blog post, written in the organization's collective voice with no individual spokesperson named. The traffic and cost figures it cites, about 3 times more traffic handled and around 80 percent lower operating and maintenance costs from its gateway re-architecture, are Shipyard's own self-reported numbers, not independently audited.

Risks and caveats

No successor maintainer or organization is named for any of the affected software projects, so it is unclear whether volunteers, Protocol Labs or another party will pick them up. No date is given for when the public infrastructure Shipyard is stepping away from, including ipfs.io and the IPFS bootstrap nodes, will actually stop working, only that Shipyard will cease operating it and Protocol Labs will decide what happens next. Anyone depending on IPFS gateways, bootstrap nodes or the software Shipyard lists should plan for reduced support or an eventual gap in maintenance.

“We have some difficult news to share with the IPFS and wider peer-to-peer community.”

— Shipyard, in its announcement