We have some difficult news to share with the IPFS and wider peer-to-peer community.
Protocol Labs has informed us that it will not be renewing Shipyard’s funding. While we’re grateful for the support and trust they have placed in us over the past two-plus years, we’re naturally disappointed by this outcome. As a direct result, Shipyard will be winding down its IPFS-related engineering, maintenance, and infrastructure operations. Our final day of our IPFS related work will be September 30, 2026.
Over the past three years, it has been our privilege to help shape the modern IPFS ecosystem and empower users with more resilient, self-sovereign technology. You can read more about the impactful work that we shipped in a follow-up post we’ll be sharing in the coming days, but some highlights include:
- Delivering verifiable websites and downloads directly in the browser through inbrowser.link.
- Re-architecting IPFS gateway infrastructure to handle approximately 3× more traffic while reducing operating and maintenance costs by around 80%.
- Advancing HTTP-native approaches to IPFS that dramatically simplify deployment, development, and operating costs compared with traditional libp2p-based hosting.
- Maintaining and improving many of the core implementations, libraries, and public infrastructure relied upon by the IPFS ecosystem every day.
We were excited about delivering the next chapter for IPFS: dramatically simpler HTTP-native implementations, resilient and sustainable content routing, support for large native SHA-256 objects, pseudonymous hosting and retrieval through Tor and onion services, and many other ideas we believed would make IPFS significantly easier to adopt. Unfortunately, we won’t have the opportunity to see those efforts through ourselves.
The practical implications extend well beyond Shipyard. Among other things:
- Projects maintained by Shipyard will no longer have dedicated maintainers responsible for new features, bug fixes, releases, or long-term stewardship. These include: Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check, and others.
- Contributions from Shipyard to upstream projects such as go-libp2p and js-libp2p will cease.
- Our work on IPFS specifications, standards, and broader ecosystem coordination will come to an end.
- Shipyard will cease operating the public infrastructure it currently manages, including ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, the IPFS bootstrap nodes, collaborative cluster infrastructure such as Wikipedia-on-IPFS, and related services. Protocol Labs, as the owner of the associated domains and infrastructure, will determine their future.
Our goal over the coming weeks is to leave the IPFS ecosystem in the best possible position for whatever comes next.
We’ll remain available through the end of September to help with that transition. If you maintain software, operate infrastructure, or rely on any of the work Shipyard has been responsible for, please don’t hesitate to reach out. We’ll do everything we reasonably can to answer questions, provide context, and help make the transition as smooth as possible.
If you have a favourite memory of working with Shipyard, or an idea you always hoped IPFS would eventually achieve, we’d love to hear it. Google Form
Finally, we want to say thank you.
To everyone who contributed code, reviewed pull requests, filed issues, tested experimental features, ran infrastructure, participated in standards discussions, or simply believed in the idea that content should be addressed by what it is rather than where it lives: thank you.
It’s been an honour to build alongside this community. While this chapter of IPFS at Shipyard is coming to a close, we remain proud of what we’ve accomplished together, and we hope the work we’ve done helps provide a strong foundation for whatever comes next.