IPFS After Shipyard: Best Distributed Storage Alternatives in 2026

On August 24, 2026, Shipyard — the engineering team Protocol Labs funded to maintain the modern IPFS stack — announced that Protocol Labs will not renew its funding, and Shipyard is winding down all IPFS-related engineering, maintenance, and infrastructure operations. The final day of Shipyard's IPFS work is September 30, 2026. The announcement reached the front page of Hacker News within a day, because the list of affected projects is not peripheral — it is the core of the ecosystem: Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, the Service Worker Gateway, and IPFS Check lose their dedicated maintainers, and public infrastructure including ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, and the IPFS bootstrap nodes changes hands. If your product pins content to IPFS, serves users through a public gateway, or ships an app built on Helia or Kubo, you now have a concrete migration decision to make before the end of September. This guide lays out the realistic options — staying on self-hosted IPFS, moving to Filecoin or Arweave, or going back to boring S3+CDN — with the trade-offs that actually matter. One important calibration up front: IPFS is not shutting down. The implementations are open source, the specifications are public, and Protocol Labs owns the domains and infrastructure Shipyard operated and has published an update on its plans going forward. What ends on September 30 is dedicated, funded maintenance — the people who cut releases, fix bugs, and keep the bootstrap nodes and public gateways healthy.

Quick Verdict

Your situation	Recommended move
You depend on ipfs.io / dweb.link public gateways in production	Migrate to a dedicated gateway or pinning service now; treat public gateways as deprecated for production use
You self-host Kubo/Helia and pin your own content	Stay, but budget for maintenance going community-driven; pin a known-good release and watch the governance transition
You need long-term, verifiable storage with an incentive layer	Filecoin (pair with a pinning service for fast retrieval)
You need permanent, pay-once archival storage	Arweave
You picked IPFS mainly for "cheap static hosting with a hash"	S3 + CDN is the operationally safest answer in 2026

What Exactly Is Changing

Shipyard's announcement is specific about the blast radius:

• No dedicated maintainers for Kubo (the Go IPFS implementation), Helia (the JavaScript implementation), Boxo, Rainbow (the gateway-focused binary), IPFS Desktop, IPFS Companion, and related tooling. Bug fixes, releases, and security response become community responsibilities unless new stewards step in.
• Contributions to go-libp2p and js-libp2p from Shipyard stop, which slows the networking layer underneath IPFS.
• Public infrastructure changes hands: ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, the bootstrap nodes, and community projects like Wikipedia-on-IPFS. Protocol Labs, as the domain and infrastructure owner, decides what happens next.
• Shipyard staff remain available through the end of September 2026 to help with the transition.

The practical takeaway: anything you do not operate yourself — or pay someone to operate — is now a single point of failure with a countdown timer.

Option 1: Stay on IPFS, but Self-Host Seriously

For teams already running their own Kubo nodes, the least disruptive path is to keep going — with eyes open. The code is mature and open source; what changes is the maintenance model. Do this if you stay:

• Run your own gateway and pinning. Pin content on at least two nodes you control, and stop referencing ipfs.io or dweb.link URLs anywhere user-facing.
• Use a pinning service as a second copy. Providers like Pinata and Storacha run dedicated IPFS infrastructure with SLAs, so your content stays retrievable even if your nodes fail.
• Pin a known-good Kubo release and treat upgrades conservatively until the post-Shipyard governance picture is clear.

Cost profile: your own VPS or container budget (a small pinning node runs fine on a $10–40/month VPS) plus pinning-service fees, which are typically usage-based. Risk profile: you now depend on community maintenance for the software itself. For many teams this is acceptable; for teams without an ops person, it is not.

Option 2: Filecoin — Incentivized Storage Built for IPFS Content

Filecoin is the natural first alternative because it was designed as the incentive layer for IPFS: content addressed the same way, but with storage providers economically contracted to keep it. For backup-style and verifiable-storage workloads, it is the most credible "distributed but sustainable" option in 2026. Strengths: cryptographic proofs that your data is stored; a live market of storage providers; directly compatible with IPFS content addressing, so CID-based architectures port over with minimal redesign. Weaknesses: retrieval latency is not CDN-class — plan a caching layer or a pinning service in front for anything user-facing; the tooling has a steeper learning curve than S3; and the ecosystem's operational maturity still trails the big clouds. Best for: teams storing large datasets or archives who care about verifiability and decentralization more than millisecond retrieval.

Option 3: Arweave — Pay Once, Store Permanently

Arweave takes a different bet: a one-time, upfront payment intended to fund storage effectively in perpetuity, with content replicated across its network. It has become the default home for permanent web archiving, NFT metadata, and documents that must not disappear. Strengths: the permanence model is simple to reason about — pay once, no recurring bills, no pinning daemon to babysit; strong adoption for archival use cases; gateways and tooling are mature. Weaknesses: "permanent" means permanent — there is no delete, which is a liability for user-generated content or anything under privacy-regulation takedown obligations; upfront cost per GB is higher than a month of S3, though it amortizes; throughput and latency are archive-grade, not app-grade. Best for: immutable archives, published reports, provenance records — content you want to outlive your company.

Option 4: S3 + CDN — The Boring, Correct Default

Here is the uncomfortable question every team using IPFS should answer this month: were you using content addressing because you needed it, or because it was interesting? If the honest answer is that you needed cheap static asset delivery with cache-busting hashes, then Amazon S3 (or Cloudflare R2, Backblaze B2, or any object store) behind a CDN does that job with two orders of magnitude less operational risk. Strengths: SLAs, mature tooling, predictable costs, every hire knows it. Content-defined chunking and hash-addressed releases are achievable on top (many build pipelines already emit hashed filenames). Weaknesses: centralized — no peer-to-peer resilience story, and you are renting from a landlord; egress fees on AWS specifically can sting at scale (R2 and B2 mitigate this). Best for: the majority of teams that adopted IPFS for static hosting or asset distribution rather than for decentralization as a requirement.

A Sensible Migration Sequence

If you are affected, do not wait for the September 30 deadline to start. A pragmatic order: 1. Audit your exposure. Grep your codebase and configs for ipfs.io, dweb.link, and any hard-coded bootstrap addresses. List what you pin and where the only copies live.
2. Secure your content. Re-pin everything you care about to infrastructure you control or pay for (own nodes plus a pinning service), independent of any public gateway.
3. Decide your target using the verdict table above. If in doubt between Filecoin and S3, prototype the retrieval path — that is where the difference bites.
4. Ship the migration before late September, while Shipyard staff are still available to answer transition questions.

What to Watch Next

Two open questions decide the long-term shape of the ecosystem. First, whether Protocol Labs' follow-up plan keeps the public gateways and bootstrap nodes running, and under what operating model. Second, whether new maintainers — foundations, companies, or community collectives — adopt Kubo and Helia. The code is good enough to survive; the question is who funds its upkeep. Until that is answered, treat self-operated or paid infrastructure as the only dependable tier.

FAQ

Is IPFS dead?

No. The protocol specifications and all major implementations are open source, and Protocol Labs — which owns the ipfs.io infrastructure — has stated its plans for continuing the project. What ended is Shipyard's funded maintenance of the core implementations and public services. Expect a slower release cadence and a community-driven governance transition, not a shutdown.

Do I have to migrate off IPFS?

Not necessarily. If you self-host your nodes and pin your own content, staying is viable — but you should remove any dependency on public gateways and treat future software updates as community-maintained. If you rely on ipfs.io or dweb.link in production, you do need to move that traffic.

Filecoin vs Arweave: how do I choose?

Filecoin fits verifiable, large-scale storage where you want an open market of providers and IPFS-compatible content addressing. Arweave fits permanent archival where you want to pay once and never think about renewal. Many teams use Filecoin (or plain S3) for hot data and Arweave for the cold, must-not-disappear layer.

What happens to my existing CIDs and links?

Content identifiers are just hashes — they remain valid forever. What can break is retrieval: if the only copy of your content lived on a public gateway's cache or on infrastructure that goes away, the CID resolves to nothing. Secure your own copies first, then update links to gateways you control or pay for. --- This guide is based on the official Shipyard announcement of August 24, 2026, and public project documentation as of August 2026. Storage pricing and provider terms change frequently — verify current terms before committing to a migration.