Ten named IPFS projects will lose their dedicated maintainers after September 30, and the same cutoff applies to public services that many developers treat as permanent parts of the network. That concrete deadline drove a 346-point, 162-comment Hacker News discussion in the current MrKeyoor brief. Shipyard says Protocol Labs declined to renew its funding, so the engineering collective will stop its IPFS maintenance and infrastructure work.
The affected software includes Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway and IPFS Check. Shipyard also named the ipfs.io and dweb.link gateways, delegated-ipfs.dev, bootstrap nodes and collaborative clusters among the infrastructure it will stop operating. Protocol Labs owns the associated domains and infrastructure and will decide what happens to them, according to the announcement. No successor or operating timetable is identified there.
This is a maintainer and operations crisis rather than a protocol shutdown. The repositories remain open, existing nodes can keep running, and content addresses do not expire on September 30. Yet code availability answers only the simplest part of the problem. Projects that depend on IPFS need to know who can review a security report, merge a compatibility fix, issue a release and keep routing or gateway endpoints online. Shipyard's post says those projects will have no dedicated team for those jobs after its wind-down.
The dependency chain is wider than the project list
Kubo is the all-purpose Go implementation that packages an IPFS node, command-line interface, HTTP gateway and RPC API. Its repository, which currently identifies Shipyard as the maintainer, has about 17,100 stars and 3,200 forks. It is also dual-licensed under Apache 2.0 and MIT, so the source remains available for another group to maintain or fork. The open question is whether anyone will take responsibility for releases and security work with enough continuity to serve production users. Kubo's own repository does not yet name a replacement team.
Boxo makes the handoff more complicated. It collects Go components for content routing, Bitswap data transfer, gateways, IPNS and other IPFS functions. The Boxo repository says it powers Kubo and lists Lotus, Rainbow, Someguy, IPFS Check and IPFS Desktop among its dependants. A fix in Boxo can therefore feed several products, while a stalled release can hold them back together. Shipyard's weekly issue and pull-request triage was part of the machinery behind that shared code.
Helia occupies the JavaScript and browser side. It is a modular TypeScript implementation whose packages can use peer-to-peer retrieval, HTTP gateways or both. Helia's documentation describes separate modules for UnixFS, IPNS, JSON, CAR files and verified fetching. Shipyard's departure reaches beyond a single daemon: browser libraries, desktop tools, gateway code and the specifications that let independent implementations communicate all lose the same dedicated engineering group.
The announcement also says Shipyard will stop contributing to go-libp2p and js-libp2p, and will end its work on IPFS specifications, standards and ecosystem coordination. Those upstream projects are not described as shutting down. The change removes one recurring contributor from the networking layer beneath the named IPFS tools, which makes the eventual scope dependent on who picks up individual responsibilities.
Public gateways reveal the operational dependence
IPFS is built around content addressed by cryptographic identifiers, but much everyday use still arrives through ordinary HTTPS endpoints. In a 2025 gateway traffic analysis, Shipyard said ipfs.io and dweb.link were handling 614 million requests and 45 TB of data for 10 million users per day. Its three-day sample attributed 67.4% of requests to automated clients and backend services, 23.1% to hot-links or app embeds, and 9.4% to direct browser visits.
Those figures expose a practical contradiction. A distributed protocol acquired centralized entry points because an HTTP URL is easier to place in an app than a local node. The public gateways lowered that barrier, then became infrastructure that applications could call like a free CDN. Shipyard's gateway analysis had already said this load created cost, trust and scaling problems, and its analysis urged backend operators to run their own gateway instead of relying on the shared domains.
Migration had begun before the funding decision. In May, Shipyard started redirecting direct browser visits from ipfs.io and dweb.link to inbrowser.link, where a service worker retrieves and verifies content inside the browser. The team also warned API clients and sites that hot-link media to move toward self-hosted or verified options as rate limits increased during 2026. Shipyard now lists the Service Worker Gateway and inbrowser.link infrastructure inside the work it will stop maintaining or operating.
For developers, the immediate task is dependency discovery. The IPFS migration guide specifically tells teams to search source, configuration and stored data for legacy gateway domains. Deployment manifests belong in the same audit because an endpoint can sit outside the application repository:
rg -n 'ipfs\.io|dweb\.link|delegated-ipfs\.dev|check\.ipfs\.network' .
The IPFS self-hosting guide makes the split explicit. Browser applications can use @helia/verified-fetch with an ipfs:// address, allowing the client to check returned bytes against the CID. A backend that only retrieves content can run Rainbow locally. A service that publishes and pins content needs Kubo or another node that can announce it. That guide now carries extra weight, even though several tools it recommends appear on Shipyard's affected list.
Self-hosting also transfers work to the application operator. The same guide warns that a public gateway is an open service and needs rate limits, a denylist and abuse controls. It recommends separate treatment for the Kubo RPC API rather than exposing it as a public gateway. Replacing ipfs.io with a private hostname may remove one external dependency, but it also creates an on-call service with storage, network and security costs.
A CID proves which bytes a client asked for; it does not guarantee that a reachable peer still has them. The self-hosting guide says a Kubo node hosts added content only while the daemon runs and the data remains pinned. It recommends a pinning service or IPFS Cluster when one node is insufficient. Teams auditing their gateway dependency therefore need to trace two paths: how clients retrieve and verify a CID, and which operators keep that CID available. A gateway replacement fixes neither path by itself.
There is also a difference between a response that is content-addressed and one the client actually verifies. The same guide reserves public gateway domains for raw blocks or CAR streams that a client can check against the requested CID. Browser code can use @helia/verified-fetch to perform that check before deserializing the result. A migration that swaps hostnames while continuing to trust ordinary HTTP responses preserves the old gateway trust model under a new domain.
The independence plan retained one large dependency
Shipyard was formed in 2024 when IPFS and libp2p developers moved into an independent engineering collective. The launch post argued that core development tied to one company and one funding source could be disrupted by a strategy change. It named Protocol Labs as the anchor financial partner for 2024 and 2025, while seeking another $3 million through community support, grants and commercial work. That account of the funding plan makes this week's decision easier to understand: organizational independence did not produce a sufficiently independent maintenance budget.
Open-source licenses make succession legally possible. They do not appoint maintainers, transfer domain access or create an incident-response rota. Shipyard has offered to answer questions and help with the handoff until September 30, but its announcement leaves the funding amount, decision process and possible successor arrangements unstated. It also promises a later post about the work completed during the past three years.
The next useful signal will be the project-by-project handoff missing from the current announcement. Watch for named maintainers and security contacts for Kubo, Helia and Boxo; release authority across the GitHub organizations; and an operator plan for the gateways, routing endpoint and bootstrap nodes. If those assignments are still unclear as September 30 approaches, developers using the public endpoints will have a date for the end of Shipyard's work but no dependable description of the service that follows it.