Changes to ipfs.io and dweb.link gateways

Public Network
1

We are making changes to how the sponsored ipfs.io and dweb.link gateways work. Rather than acting as central servers that fetch content on your behalf, they’ll hand the browser a service worker that makes direct peer-to-peer connection to fetch the content and verify it locally.

The phased rollout of the service worker gateway redirect began in May and now handles 100% of browser traffic.

IPFS gateways were always meant to be a stepping stone while we built toward native IPFS support in browsers. Over time, hardcoded gateway URLs spread across the web and traffic re-centralized around a small number of public gateways. These changes bring the network closer to the direct peer-to-peer connections, and allow us to invest our time and resources into shared foundations and lightweight on-ramps instead of subsidizing centralized bandwidth.

Here’s what to expect:

  • Browser users get direct browser connections, seamlessly. Users who navigate to ipfs.io and dweb.link will now be redirected to the service worker gateway at inbrowser.link, which will hand your browser a service worker that makes direct peer-to-peer connection to fetch the content and verify it locally. This maintains the same user experience and ease of development while enabling local verification, offline access, and better security.
  • Apps & Hotlinks → @helia/verified-fetch. Apps that previously hotlinked images, JSON, metadata, or scripts through the public gateways should move to @helia/verified-fetch or the Drop-In Service Worker (opens new window). For those looking for more verification and resiliency, Helia’s Verified Fetch (opens new window)offers trustless content retrieval and automatic fallback to multiple providers.
  • Backend Services → Self-Hosted Gateways. For backend and automated clients, we recommend running dedicated IPFS nodes or gateways using tools like Rainbow, Someguy, or Kubo (if you also need to publish). These services shouldn’t rely on the public-good gateway at all. We’ve created a guide to help you transition painlessly (opens new window).
  • Rate limiting has begun on ipfs.io and dweb.link for hotlinked and backend traffic, and will be increasing. Limited responses will point at the migration paths above to help route users to the appropriate channel.

Questions about these changes, or need help migrating? Drop a reply here.

2

A question for the teams this hits hardest: backends and apps that fetch JSON or images through these gateways (NFT metadata, indexers, link previews). We self-host, so I ask for them, not for us.

A backend fetch or an img tag cannot run a service worker, so inbrowser.link does not help them. And it cannot read advice inside an error response.

So, in plain numbers:

  • What are the rate limits now, and what will they become?
  • What HTTP status and headers will a limited response use, so people can alert on it?
  • Is there a date when these hostnames stop serving this traffic at all?

The guide says run your own gateway, and that is good advice. But without numbers and dates, nobody can size the migration window. Thank you.

4

radio silence gg :grimacing:

my chain CID crawler is getting errors on links like https://gatewaychanges.ipfs.io/#/ipfs/bafkreie7q3iidccmpvszul7kudcvvuavuo7u6gzlbobczuk5nqk3b4akba

https://gatewaychanges.ipfs.io says:

Starting September 1st the gateway steps aside a little each hour, currently about 10 minutes each hour, and these pauses keep growing until it retires for good on September 21 (UTC).