Shipyard to Halt IPFS Operations on Sept. 30 After Protocol Labs Funding Ends

Shipyard, the organization responsible for maintaining core components of the InterPlanetary File System (IPFS), announced it will cease all IPFS-related development, maintenance, and infrastructure operations on September 30. The decision follows the termination of funding from Protocol Labs, the primary sponsor of IPFS development.

Scope of the Shutdown

Shipyard’s portfolio includes critical projects such as Kubo (the original IPFS implementation) and Helia (a modern JavaScript implementation). Without dedicated maintainers, these projects will no longer receive new feature development, bug fixes, or regular releases. Shipyard also plans to shut down public infrastructure it currently operates, including the widely used gateways ipfs.io and dweb.link, as well as IPFS bootstrap nodes that help peers connect to the network.

Protocol Labs, the organization that created IPFS and funded Shipyard’s work, will determine the future operating plans for the affected domains and infrastructure. This transition raises questions about the long-term sustainability of IPFS’s core public services.

Impact on the IPFS Ecosystem

IPFS is a peer-to-peer hypermedia protocol designed to make the web faster, safer, and more open. It is used by numerous Web3 projects, NFT platforms, and decentralized applications to store and retrieve content in a distributed manner. The shutdown of Shipyard’s operations could affect developers and users who rely on the maintained software and public gateways for their daily workflows.

While the IPFS protocol itself remains operational, the loss of dedicated maintainers for Kubo and Helia could slow innovation and introduce security risks if vulnerabilities go unpatched. The closure of public gateways may also reduce accessibility for users who depend on these entry points to interact with IPFS-hosted content.

Community Response and Next Steps

The announcement has sparked discussions within the decentralized storage community about the need for sustainable funding models for open-source infrastructure. Some community members have called for a transition to community-driven governance or the formation of new maintenance groups. However, no concrete plans have been announced yet.

Protocol Labs has not provided a detailed roadmap for the affected projects. The organization may choose to reassign maintenance duties to other teams, or it may allow the community to fork and continue development independently. The lack of clarity adds uncertainty for developers who have built applications on top of these tools.

Why This Matters

This development highlights the fragility of decentralized infrastructure when it depends on a single funding source. For users and developers, it underscores the importance of diversifying support and ensuring continuity plans are in place for critical open-source software. The outcome could influence how other Web3 projects approach funding and maintenance of their core dependencies.

As the September 30 deadline approaches, stakeholders will be watching closely for further announcements from Protocol Labs. In the meantime, users of IPFS are advised to monitor the status of the affected services and plan for potential disruptions.

Conclusion

Shipyard’s withdrawal from IPFS maintenance and infrastructure marks a significant shift for the decentralized storage ecosystem. While the protocol itself remains operational, the loss of dedicated maintainers and public gateways poses practical challenges. The coming weeks will be critical in determining how the community and Protocol Labs respond to ensure the continued health of IPFS.

FAQs

Q1: What is Shipyard and what role did it play in IPFS?
Shipyard was an organization that maintained core IPFS projects, including Kubo and Helia, and operated public infrastructure like ipfs.io and dweb.link. Its work was funded by Protocol Labs.

Q2: What will happen to IPFS after Shipyard ends operations?
IPFS will continue to function as a protocol, but without dedicated maintainers, development and maintenance of Kubo and Helia will cease. Public gateways and bootstrap nodes will be shut down unless Protocol Labs arranges alternative management.

Q3: How can developers and users prepare for the transition?
Developers should monitor official IPFS channels for updates, consider alternative gateways or self-hosted nodes, and be prepared for potential delays in bug fixes or new releases. Community-driven forks may emerge as a stopgap.