Blog
8 min readOctoPeeps team

Storacha is shutting down — your migration playbook

Storacha (formerly web3.storage) sunsets its IPFS gateway May 31, 2026. Step-by-step guide to re-pinning your NFT content elsewhere without breaking smart contracts.

On May 12, 2026, Storacha (formerly web3.storage) announced they're shutting down the public IPFS gateway at w3s.link on May 31, 2026. If your NFT collection's metadata or images live there — millions do — you have about three weeks to re-pin them somewhere else before ipfs:// URIs in your contracts stop resolving for most users.

This is the playbook we used to migrate the OctoPeeps and Octo Kiddos collections (13,000+ NFTs) off Storacha onto our own infrastructure. It applies whether you migrate to Octopin, Pinata, Filecoin Pin, or a self-hosted IPFS node.

First: what actually breaks?

IPFS content is content-addressed. The CID (bafy...) is the hash of the file's bytes — not a pointer to a server. So technically your CIDs never expire. What expires is:

If your contract's tokenURI uses ipfs://<cid>/<file> (native IPFS URI, no gateway in the URL), you don't need to change a single line of on-chain code. As long as the bytes are pinned somewhere on the IPFS network, every marketplace and wallet's gateway pool finds them.

If your contract uses a Storacha gateway URL like https://w3s.link/ipfs/bafy..., you have a bigger problem — that URL is going to 404. You'll need either an immutable proxy on a domain you control, or a contract upgrade.

The five-step migration

Step 1 — Inventory your CIDs

You need a list of every CID currently pinned on Storacha that you care about. Three ways to get it:

For most NFT collections you'll end up with a handful of CIDs (one per metadata folder, one per image folder), not thousands. The folder CIDs cover all the files inside.

Step 2 — Download your content from Storacha

While the gateway is still up, pull every file:

# Single file
curl -L "https://w3s.link/ipfs/<cid>" -o file.bin

# Folder — fetch the entire DAG as a CAR file
curl -L "https://w3s.link/ipfs/<folder-cid>?format=car" -o folder.car

Save the originals to a folder on your laptop. You'll re-upload these to your new pinning provider in the next step. Keep the original filenames if your folder structure matters for path-based access (e.g. /ipfs/<folder>/0.json).

Step 3 — Pick a new pinning provider

Be honest about your priorities. Real options as of May 2026:

For most NFT projects the deciding factor isn't storage — your metadata is ~1 MB and images ~500 MB at the high end. It's bandwidth predictability. A collection that goes viral or gets re-listed on a new marketplace can rack up unexpected gateway traffic. Unlimited-bandwidth providers shield you from that.

Step 4 — Re-upload to verify CIDs match

Upload the files you downloaded in step 2 to your new provider. The critical check: does the new provider produce identical CIDs for identical bytes?

It should. IPFS CIDs are deterministic — the same bytes through the same chunker produce the same hash. Octopin, Pinata, Storacha, and Filecoin Pin all use the default 256 KB fixed-size chunker with raw leaves, which is what produces standard bafy... CIDs.

If you uploaded a folder and the new provider gives you a different root CID than you had on Storacha, something re-chunked your content. Stop and investigate — your contract URIs point at the OLD CID, so a new CID is useless. Re-upload as a CAR file if your provider supports it (preserves the original chunking exactly).

Step 5 — Announce to the public IPFS network

Pinning the bytes is only half the job. Other gateways need to be able to find you. Modern IPFS does this through two channels:

Any reputable pinning provider does both automatically. If you self-host, you need to set up an IPNI publisher (we use js-ipni in our backend; the Go reference is index-provider).

Step 6 — Verify discoverability

Before you trust that the migration is complete, check that the CIDs resolve from at least two public gateways:

Allow 10–30 minutes after re-pinning for new CIDs to propagate through IPNI's ingestion pipeline. If after an hour a CID still isn't resolving on dweb.link, your pinning provider didn't announce successfully.

Common pitfalls


Questions about your specific migration? DM @OctoPeepsNFTs on X or drop into the OctoPeeps Discord.