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:
- The pinning — Storacha agreed to keep your bytes stored and reachable on the IPFS network. After shutdown, no one is obligated to keep them. The bytes get garbage-collected from their nodes. Your CID still exists conceptually, but nobody has the data.
- The gateway — URLs like
https://w3s.link/ipfs/bafy...orhttps://<cid>.ipfs.w3s.link/stop responding. Any marketplace, wallet, or app that hardcoded that hostname breaks.
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:
- From Storacha's dashboard — log in at
console.web3.storage, export your pin list as CSV. Works until the shutdown date. - From your contract's
tokenURI— for each token ID, calltokenURI(id), parse theipfs://<cid>/<path>URI, dedupe by root CID. A 10-line script withviemorethershandles this. - From off-chain records — if you generated metadata locally before uploading, you probably have the CID list in a JSON file. Easiest.
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.carSave 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:
- Octopin — what we built specifically for this scenario. Unlimited bandwidth on every tier, $0 free tier for 1 GB, $5/mo for 25 GB. Google sign-in, drag-and-drop upload. Disclosure: this is our blog. We don't yet have a bulk-import-from-URL tool — you re-upload manually for now.
- Pinata — mainstream choice, 7+ year track record. $20/mo minimum for paid tiers, bandwidth overage at $0.10/GB. Has a bulk pin-by-CID API for programmatic migration.
- Filecoin Pin — Storacha's own successor product. On-chain Filecoin deals for storage proofs. Requires an EVM wallet and FIL for gas. Best fit for Filecoin maximalists who want on-chain durability receipts.
- Self-host on a VPS — what we did originally. Run Kubo or Helia on a Hetzner box, point your domain at it. Maximum control, requires ops skills.
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:
- The Amino DHT (libp2p's distributed hash table) — your pinning node gossips "I have CID X" to peers. Other gateways look up the DHT to find providers.
- IPNI (the InterPlanetary Network Indexer at
cid.contact) — a centralized-but-federated registry that Pinata, web3.storage, Filecoin Pin, and Octopin all publish to. This is the faster, more reliable path for modern clients.
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:
https://dweb.link/ipfs/<cid>— Protocol Labs' public gateway. Consults IPNI.https://cid.contact/cid/<cid>— directly query the indexer to see which providers are listed. You should see your new pinning provider in the response.- A wallet you trust — open the NFT in MetaMask, Phantom, OpenSea testnet. If the image renders, you're good.
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
- Pinning a folder CID isn't the same as pinning every file inside. Most providers handle this correctly, but verify — pin the folder root, then resolve a child file (e.g.
/ipfs/<folder-cid>/0.json) and confirm it returns content. - CIDv0 vs CIDv1. Older Storacha content might be CIDv0 (
Qm...). Modern tools produce CIDv1 (bafy...). The two CID formats refer to the SAME bytes but display differently in URLs. Stick with whatever your contract uses. - Don't change your
baseURIjust because you migrated. If you're usingipfs://URIs (which you should be), nothing on-chain changes. Modifying the contract risks introducing bugs. - Don't delete from Storacha until you've verified the new pin. Until the new provider has announced your CID to IPNI and you've confirmed dweb.link resolves it, keep the Storacha pin as the safety net.
Questions about your specific migration? DM @OctoPeepsNFTs on X or drop into the OctoPeeps Discord.