IPFS Is Rate-Limiting Public Gateways: What Changes for You

If a project relying on IPFS's free public gateways has noticed things getting slower or less reliable lately, that's not an outage. Per IPFS's own blog, it's a deliberate, announced shift: the ecosystem is moving away from subsidizing free public gateway bandwidth indefinitely, and rate limiting on those gateways "has begun and will increase." This article covers exactly what's changing, why, and what to actually do about it.

TL;DR:

• IPFS's public gateways handle roughly 250 million requests per day, and per IPFS's own blog, continuing to subsidize that bandwidth indefinitely is no longer considered necessary or sustainable
• Rate limiting on public gateways has already started and is set to increase, this is a deliberate policy shift, not a temporary technical problem
• The recommended path depends on what you're building: browser users get automatically redirected to service-worker-based gateways, apps should adopt trustless, client-side retrieval, and backend services are told to migrate to self-hosted infrastructure
• The ecosystem has matured enough to support this: more than a dozen active IPFS implementations now exist, and a service-worker gateway approach first built in late 2024 now performs on par with traditional gateways
• For any project that can't self-host, a dedicated commercial gateway is the direct, drop-in answer to exactly the gap this creates, no self-hosted infrastructure to maintain

Why This Is Happening

Public IPFS gateways aren't a paid product, they're subsidized infrastructure the ecosystem has funded to make IPFS content accessible to anyone with a browser, no node required. IPFS's own blog frames the shift plainly: the ecosystem has grown enough, more than a dozen active implementations, browser-based nodes, service worker gateways, that indefinitely subsidizing free bandwidth at 250 million requests a day is no longer the highest-leverage use of resources. The stated philosophy is direct: "the scarce thing now is interoperability, not code", meaning funding should go toward specifications and conformance testing, not toward bandwidth subsidies that were only ever meant to bootstrap the ecosystem, not run it forever.

What's Actually Changing

Rate limiting on the shared public gateways has already begun, and per the announcement, it's set to increase further. This isn't a bug to wait out. Anything currently depending on unlimited, free access to a public gateway, a marketplace resolving NFT metadata on every page view, a dApp loading user assets, a documentation site, should expect that access to keep getting more constrained, not less, going forward.

The Three Recommended Paths

IPFS's own migration guidance splits by what you're actually building:

• Browser-based use. Traffic gets automatically redirected to service-worker-based gateways (via inbrowser.link), a lighter-weight approach that, per the announcement, now performs on par with traditional gateways after being built out since late 2024.
• Application-level retrieval. Apps are pointed toward @helia/verified-fetch, a trustless, client-side retrieval library, so content gets verified and fetched without depending on a shared gateway's continued availability.
• Backend services. The clearest guidance: migrate to self-hosted infrastructure, specifically named options include Rainbow and Kubo, running your own gateway rather than depending on a shared public one.

Where a Commercial Gateway Fits That Guidance

That third path, self-hosting, is the right answer for a team with the operational capacity to run and maintain gateway infrastructure. It's a real cost for a team that doesn't: running Kubo or Rainbow reliably at production scale is genuine ongoing infrastructure work, monitoring, scaling, security patching, not a one-time setup. A dedicated commercial gateway, like AIOZ Pin's premium gateway, covers the same underlying need, a private, non-rate-limited access point, without requiring a team to run that infrastructure itself. It's not one of IPFS's own three named paths, but it solves the exact problem the shift away from free public gateways creates, for anyone who'd rather not take on self-hosted infrastructure as a new operational responsibility.

What to Actually Do About This

• Audit current gateway dependency. Anything pointing at a shared public gateway URL in production is exposed to this change directly.
• Match the fix to the use case. A browser-only integration may need nothing more than the automatic redirect already in place. A backend service resolving content server-side needs a real decision: self-host, or move to a dedicated gateway.
• Don't wait for a visible failure. Rate limiting increasing gradually means degraded performance shows up as intermittent slowness before it shows up as an outright block, worth checking dependency now rather than after users start noticing.

Frequently Asked Questions

Why are IPFS public gateways being rate-limited? Per IPFS's own blog, the ecosystem has matured enough (more than a dozen implementations, viable client-side alternatives) that indefinitely subsidizing free public gateway bandwidth at roughly 250 million requests a day is no longer considered the best use of resources.

Is this a temporary problem or a permanent policy? A deliberate, announced policy shift. Rate limiting has already begun and is stated to increase further, not something expected to reverse.

What should a browser-based app do about this? Very little immediately, traffic gets automatically redirected to service-worker-based gateways, which now perform on par with traditional ones.

What should a backend service do about this? IPFS's own guidance is to migrate to self-hosted infrastructure like Rainbow or Kubo, or use a dedicated commercial gateway if running that infrastructure yourself isn't practical.

Does AIOZ Pin's gateway get affected by this public-gateway rate limiting? No. AIOZ Pin's premium gateway is a separate, dedicated access point already built specifically to not be subject to shared public-gateway rate limits, this change is exactly the gap that kind of gateway exists to cover.

Related Reading

• Explore How IPFS Gateway Works Across Decentralized Networks - the full gateway mechanics this policy shift applies to
• AIOZ Pin Dedicated Gateways: Simple, High-Performance IPFS Access - the specific product answer to the backend-services guidance above
• Helia: IPFS's Modern JavaScript Implementation - the project behind @helia/verified-fetch, one of the three recommended migration paths
• What Actually Determines IPFS Retrieval Speed - how gateway choice affects real-world retrieval performance
• How to Host a Static Website on IPFS (and Why Pin It) - a concrete use case directly exposed to public-gateway dependency
• AIOZ Pin Rate Limits: API, Public, and Premium Gateways - the published AIOZ Pin limits for its API, public gateway, and premium gateways
• IPFS Gateway Not Working? Diagnose It in This Order - what to check, in order, when a public gateway request fails

References

• IPFS Blog: IPFS Is Moving Beyond the Sponsored Gateways