ipfs.io Gateway Not Working? What Changed and Who Runs It

The ipfs.io gateway stopped fetching content for scripts, servers and hotlinked files on purpose, so you can't fix it on your side. Those requests now get HTTP 429, and browser visits go to inbrowser.link. On October 14, 2026, the IPFS Project named who keeps its shared services running.

TL;DR:

• A plain curl request to ipfs.io returned HTTP 429 with a 15-minute Retry-After on October 19, 2026
• Browser visits redirect to inbrowser.link, which fetches and verifies content inside your own browser
• The new stewards are the IPNI and Compass team (inbrowser.link, delegated routing, bootstrapping), ProbeLab (measurement) and Skapa (the BadBits denylist)
• Your CIDs keep working: change the gateway hostname, and make sure someone still provides the content
• On AIOZ Pin, the public gateway is for testing, and premium gateways have no predefined rate limit

Why is the ipfs.io gateway not working anymore?

The IPFS Project changed what the gateway is for, and the change is finished for non-browser traffic. In August 2026 it said ipfs.io and dweb.link would stop "acting as central servers that fetch content on your behalf" and send browsers to a client-side gateway instead. The October 14 post adds that "100% of in-browser gateway traffic is now served by direct peer-to-peer retrieval".

Everything else was throttled in steps until it stopped. The page those requests now point to, gatewaychanges.ipfs.io, says the pauses started on September 1 and grew each hour until the gateway "retires for good on September 21 (UTC)". You can see the result with one request, which we ran from a server with plain curl at 08:53 UTC on October 19, 2026 (headers trimmed):

$ curl -s -D - https://ipfs.io/ipfs/bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy
HTTP/2 429
content-type: text/plain; charset=utf-8
retry-after: 900
server: cloudflare

This IPFS gateway is switching to a service worker gateway only. See https://gatewaychanges.ipfs.io#/ipfs/bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy for more information.

The dweb.link hostname returned the same 429 and message. A 900-second Retry-After looks like an ordinary rate limit, but waiting won't help you, because the body says the gateway now serves browsers only. Our browser-style request hit a Cloudflare challenge page, so we couldn't follow the browser redirect from a script.

How the rollout went, per the primary sources:

• May 11, 2026: Shipyard began a phased redirect of browser visits to inbrowser.link
• August 24: Shipyard said Protocol Labs would not renew its funding and its IPFS work would end on September 30
• August 25: the IPFS blog said rate limiting "has begun" for hotlinked and backend traffic
• September 1 to 21: the gateway paused for longer each hour, then retired for non-browser requests
• October 14: the IPFS blog named the new stewards

Who runs the public IPFS services now?

When Shipyard wound down, it said it would stop operating ipfs.io, dweb.link, delegated-ipfs.dev and the IPFS bootstrap nodes, and that Protocol Labs would decide their future. The October 14 announcement thanks Shipyard and names three groups as ongoing stewards:

• IPNI and Compass team (Alex Firmani, Bart Święcki, Takwa Gnenna and others): an infrastructure provider for inbrowser.link, delegated routing at delegated-ipfs.dev, and resilient bootstrapping
• ProbeLab (Yiannis Psaras, Dennis Trautwein and team): crawlers and long-running measurements of the DHT, Bitswap, IPNI and gateways, the research behind Optimistic Provide, and live dashboards at probelab.io/ipfs
• Skapa, a longtime infrastructure steward: BadBits, the shared list of known malicious or abusive content that operators use to handle takedowns

The post describes routing as moving toward "a more federated model, where multiple independent operators could each run services". It doesn't name a day-to-day operator for the ipfs.io and dweb.link hostnames, and it makes no uptime promise. The IPFS docs still call every public utility "best-effort" and "not intended to be part of your critical path".

The code behind inbrowser.link has shipped two releases since Shipyard's last day, v3.5.0 on October 6 and v3.5.1 on October 15. Delegated routing still answers too, and our request to delegated-ipfs.dev on October 19 returned HTTP 200 with a list of providers.

What to change, by how you use the gateway

If you open IPFS links in a browser, nothing breaks: you land on inbrowser.link, which loads the content and checks it against the CID locally. If you publish links, the IPFS docs suggest pointing them at inbrowser.link directly so your readers skip the extra redirect. Our guide to how the IPFS service worker gateway works covers each step, from the installer page to the check against the CID.

If your app hotlinks images, JSON or metadata, the IPFS blog points you to @helia/verified-fetch, part of Helia, or to the Drop-In Service Worker. The verified-fetch library checks every block against the CID, much like a trustless gateway. By default it still calls delegated-ipfs.dev and trustless-gateway.link, and the docs say production setups should point both at their own servers.

If your backend or scripts fetch by CID, these are the requests that now get the 429. The IPFS docs suggest Rainbow if you only retrieve, Kubo if you also publish, and Someguy as your own routing endpoint. The other route is a paid gateway from a pinning provider, and the IPFS blog names Pinata, Filebase and Lighthouse as examples.

NFT projects should check their token URIs as well: an ipfs:// URI lets each marketplace pick its own gateway, while a hardcoded https://ipfs.io/ipfs/ URI gets the 429 whenever a server fetches it. See the NFT metadata problem for the storage side.

Does your content disappear when the gateway stops serving it?

No. The gatewaychanges page says the content "is still available via the IPFS public network" for any node to fetch and verify, "as long as someone is still providing it". If nobody provides it, no gateway can fetch it, and a gateway cache was never meant to keep your file online.

If your files only lived on a service that shut down, or on your laptop, a new gateway will time out too. Pinning keeps a provider online, and if the content already has a CID you can pin it by CID without uploading it again.

How AIOZ Pin handles it

AIOZ Pin runs its own gateways, so the IPFS Project's change doesn't alter our limits, and the docs list two kinds:

• Public gateway at https://public.aiozpin.network/ipfs/{cid}: no account needed, "primarily intended for testing purposes or scenarios with very low retrieval volumes", with 15 requests per minute per CID across all IPs and 200 per minute per IP
• Premium gateways: "unrestricted rate limits" on 200+ edge-caching locations; free-plan users get a limited premium gateway that serves single files like images, video and audio, but not HTML or scripts; if your balance runs out, the premium gateway turns off and pinned files stay reachable through the public gateway

A move off ipfs.io takes three steps: pin the CIDs your app depends on, find your gateway host, then swap the hostname. Here are those calls as the AIOZ Pin docs show them (not run for this article):

// Pin a CID that already lives on IPFS
POST https://api.aiozpin.network/api/pinning/pinByHash
headers: pinning_api_key, pinning_secret_key
body: { "hash_to_pin": "{cid}" }

// List your gateways (returns name, host, type, bandwidth)
GET https://api.aiozpin.network/api/gateways/

// Swap the hostname, keep the CID
https://ipfs.io/ipfs/{cid}                      before
https://public.aiozpin.network/ipfs/{cid}       testing, low volume
https://{gateway}.aiozpin.network/ipfs/{cid}    your premium gateway

The docs don't yet say whether AIOZ Pin's gateways fetch CIDs that are pinned only elsewhere, so pin what you serve. The free vs paid premium gateway guide and the AIOZ Pin rate limits guide have the details.

Next step: set up your gateway with the AIOZ Pin premium gateways docs.

Frequently Asked Questions

Is the ipfs.io gateway shutting down?
For browsers it still works by redirecting visits to inbrowser.link, but for scripts, servers and hotlinks it already stopped and returns HTTP 429.

What is inbrowser.link?
It is the IPFS Service Worker Gateway, which runs in your browser, downloads blocks from peers and verifies them against the CID before showing the content.

Who are the new stewards of the public IPFS services?
Per the IPFS blog of October 14, 2026, they are the IPNI and Compass team, ProbeLab and Skapa.

Will waiting fix a 429 from ipfs.io?
No, because the gateway no longer serves non-browser requests even though the Retry-After header says 900 seconds.

Do I need new CIDs after switching gateways?
No, a CID is derived from the content itself, so it stays the same on every gateway and only the hostname in front of it changes.

Related Reading

• IPFS Is Rate-Limiting Public Gateways: the August policy change
• IPFS Gateway Not Working? Diagnose It in This Order: checks for any gateway
• Delegated Routing: finding providers without a DHT
• IPFS Dedicated Gateway Free vs Paid Plans on AIOZ Pin: what each plan serves

References

• IPFS Blog: New Stewards for Public IPFS Network Services
• IPFS Blog: IPFS is moving beyond the sponsored gateways
• Shipyard: The end of IPFS at Shipyard
• Shipyard: IPFS Public Gateways are Redirecting to inbrowser.link
• IPFS: Switch to fetching IPFS content directly
• IPFS Docs: Replace public gateways with self-hosted IPFS
• IPFS Docs: Public IPFS Utilities
• GitHub: service-worker-gateway releases
• AIOZ Pin Docs: Limit