Stay connected with KayaToday, follow us on Instagram and Facebook for the latest news and reviews delivered straight to you.
Decentralised storage has long been one of the more credible use cases in the broader Web3 narrative, and the InterPlanetary File System sits near the centre of that argument. So when the organisation responsible for maintaining IPFS’s most widely used tools announces it is shutting down, it is worth understanding exactly what is being lost and what, if anything, remains.
Shipyard, the engineering collective that has served as the primary maintainer of IPFS infrastructure since its founding in 2024, confirmed in a Monday blog post that it will cease operations on September 30 after Protocol Labs declined to renew its funding. The wind-down affects a significant slice of the IPFS ecosystem, including core implementations such as Kubo and Helia, tooling projects Boxo and Rainbow, and user-facing products IPFS Desktop and IPFS Companion.
What Shipyard Actually Did, and Why Its Exit Creates a Real Gap
To understand the stakes, it helps to know what Shipyard was. Protocol Labs, the research and development organisation that originally created both IPFS and the Filecoin blockchain, spun out a group of its longtime IPFS engineers into an independent collective in 2024. That collective, Shipyard, took on the unglamorous but essential work of keeping IPFS implementations maintained, patched, and running at scale.
The projects now left without dedicated maintainers are not peripheral experiments. Kubo is the most widely deployed IPFS node implementation. IPFS Desktop and IPFS Companion are the primary tools through which everyday users and developers interact with the network. Shipyard also operated public infrastructure that much of the ecosystem quietly depends on, including the gateways ipfs.io and dweb.link, the delegated routing service at delegated-ipfs.dev, and the IPFS bootstrap nodes that help new nodes find and connect to the network.
Shipyard has clarified that it will cease operating all of that public infrastructure at the end of September. Protocol Labs owns the underlying domains and server infrastructure and will decide what happens to them next, but no timeline or commitment has been announced.
Protocol Labs Frames This as a Strategic Shift, Not an Abandonment
Protocol Labs engineering and research lead Molly Mackinlay addressed the situation in an online forum discussion, describing the transition as a move toward what she called “lighter-weight stewardship.” Under this model, the IPFS Foundation would distribute grants to individual maintainers rather than funding a centralised engineering team. Mackinlay added that development on decentralised public infrastructure would continue.
The framing is optimistic, and it is not entirely without precedent. Many open-source protocols do operate through distributed volunteer and grant-funded maintainership. But the gap between that model and what Shipyard provided is significant. Shipyard offered coordinated, professional engineering across multiple interdependent projects simultaneously. Replacing that with a looser network of individual grant recipients introduces real questions about coordination, accountability, and response times when something breaks.
It is also worth noting the timing. IPFS is not a struggling niche project. It underpins NFT metadata storage across major platforms, powers parts of the Filecoin ecosystem, and is used by developers building decentralised applications across the industry. Withdrawing structured funding from its core maintenance team at this stage of Web3 development sends an ambiguous signal about Protocol Labs’ priorities.
Why This Matters Beyond One Organisation’s Budget Decision
The Shipyard situation illustrates a structural tension that runs through much of the decentralised web. The ideological promise of these protocols is that no single entity controls them, which means they should be resilient to any one organisation stepping back. In practice, the most widely used implementations of open protocols tend to concentrate around whoever is willing to fund full-time engineers, and when that funding disappears, the gap is rarely filled quickly or cleanly.
For developers and projects in Malaysia, Singapore, and across Southeast Asia that have built on IPFS-dependent infrastructure, the immediate practical concern is continuity. Applications relying on the ipfs.io or dweb.link gateways will need to evaluate alternatives or run their own infrastructure before September 30. The bootstrap node situation is similarly worth monitoring, since those nodes are how new IPFS nodes discover the network.
The longer-term question is whether the IPFS Foundation’s grant model can attract and retain the calibre of engineering talent that Shipyard concentrated. Open-source grant programmes have a mixed track record on that front, particularly for maintenance work that is critical but rarely exciting enough to attract competitive bids.
IPFS as a protocol is not going away. The specification is open, the network is distributed, and other organisations can and likely will step in to maintain some of what Shipyard built. But the loss of a dedicated, coordinated engineering team removes a layer of professional stewardship that the ecosystem will feel, and the transition period between now and whenever replacement maintainers are established represents genuine operational risk for anyone who has built on the assumption that IPFS’s core tooling would remain reliably supported.
Read More: Ethereum’s Next Big Upgrade Is Still a 66-Way Decision, and Privacy Is at the Centre of It
