· via Hacker News – Front Page (native)
Protocol Labs ends Shipyard funding; core IPFS maintenance stops September 30, 2026
Shipyard, the team behind Kubo, Helia and much of IPFS's public infrastructure, says Protocol Labs will not renew its funding and its IPFS work ends September 30, 2026.

Shipyard is winding down its IPFS operations
Shipyard, the engineering company that has carried much of the day-to-day work on IPFS, is shutting down its IPFS efforts. In an announcement on its blog, which also surfaced on the front page of Hacker News, the company says Protocol Labs has informed it that its funding will not be renewed. Shipyard's final day of IPFS-related engineering, maintenance and infrastructure work will be September 30, 2026.
Shipyard describes the outcome as disappointing while expressing gratitude for what it says was more than two years of support from Protocol Labs. The same post also refers to three years of shaping the modern IPFS ecosystem, a slightly longer horizon than the funding period it cites. No statement from Protocol Labs accompanies the announcement, so the reasoning behind the decision remains unknown.
Projects left without dedicated maintainers
According to Shipyard, a long list of software will no longer have anyone formally responsible for new features, bug fixes, releases or long-term stewardship. The named projects are Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, the Service Worker Gateway and IPFS Check, along with others. Kubo is the reference Go implementation of an IPFS node, Helia is the JavaScript implementation, and Boxo is the shared Go library stack underneath them.
Shipyard's upstream contributions to go-libp2p and js-libp2p, the networking layer IPFS builds on, will also cease. Its work on IPFS specifications, standards and broader ecosystem coordination comes to an end as well.
Public infrastructure in question
Shipyard will additionally stop operating the public infrastructure it currently manages. That includes the ipfs.io and dweb.link gateways, check.ipfs.network, delegated-ipfs.dev, the bootstrap nodes that help new peers join the network, and collaborative cluster infrastructure such as the Wikipedia-on-IPFS archive.
There is an important nuance here: Protocol Labs owns the associated domains and infrastructure and will determine their future, according to the post. These services are therefore not automatically going dark on September 30, but no successor operator has been named, and anyone depending on them is now waiting on a decision from Protocol Labs.
The roadmap that will not ship
Shipyard had planned a next phase for IPFS that it now says it will not get to deliver. The abandoned work includes far simpler HTTP-native implementations, a hardier and more cost-effective approach to content routing, support for large native SHA-256 objects, and the ability to host and retrieve content pseudonymously over Tor onion services.
What Shipyard delivered
The post points to several accomplishments from its tenure. Inbrowser.link lets browsers fetch sites and downloads whose contents can be cryptographically verified. A re-architecture of gateway infrastructure roughly tripled the traffic it could handle while cutting operating and maintenance costs by about 80 percent. Shipyard also advanced HTTP-native deployment approaches that it says are considerably cheaper to run than traditional libp2p-based hosting.
The handover window
Shipyard says it will remain reachable through the end of September to answer questions, provide context and ease the transition for anyone who maintains software, operates infrastructure or otherwise depends on its work. The company is also inviting community input on what it hopes IPFS might eventually achieve.
Why it matters
IPFS is presented as decentralized infrastructure, but this announcement shows how concentrated its actual upkeep had become. One funded contractor was responsible for the reference node implementation, the JavaScript stack, the shared libraries, significant libp2p contributions, the specifications work, and the public gateways through which most people reach IPFS content. With that funding withdrawn, every one of those threads is now open-ended unless new maintainers or another sponsor step forward.
Open-source code does not vanish when maintainers leave, but it does stop moving: unreleased fixes, unanswered issues and stale dependencies are how widely used projects effectively deprecate themselves. The September 30 cutoff leaves just over a month for handover conversations, a tight window for software of this scale.
The other open question is infrastructure. Public gateways like ipfs.io and dweb.link, plus the bootstrap nodes, are how most casual users actually experience IPFS. The announcement leaves their future entirely to Protocol Labs without saying what, if anything, the company plans to keep running. Until that is clarified, the practical risk is that the network's most visible entry points become unreliable even if the protocol itself lives on.
- #ipfs
- #p2p
- #open-source
- #decentralized-web
- #protocol-labs