In May, we wrote about upcoming changes to the ipfs.io gateway and how they would impact users of the ipfs ecosystem. 

To summarize, the ipfs.io gateway is switching towards a service worker model, which means that those retrieving content via the ipfs.io gateway will essentially run a local node in their browser to fetch content from IPFS instead of relying on a free service to fetch content for them. As a side effect, the ipfs.io gateway will no longer work outside of browsers, preventing applications and code deployments from using it to retrieve content.

Last week, the transition timeline was confirmed, with September 21st, 2026 being the last day programmatic traffic will be accepted. In addition, starting September 1st, the gateway will reject programmatic traffic at an increasing rate each hour until the September 21st cutoff date is reached.

What does this mean for applications relying on ipfs.io?

If you have a business or product relying on ipfs.io in any capacity, you've likely already started seeing broken responses and outages for your application. 

So how can you fix this? To start, you're going to need an alternative IPFS gateway to serve your content. There are two main routes you can take for this: 

Self hosting

For those with DevOps resources, and a desire for full control, self hosting is an option that some teams take. Using open-source tools like Kubo or Rainbow, you can run your own dedicated gateway infrastructure for retrieving content. 

Some important things to consider when running your own IPFS gateways are:

• Scale (how you handle traffic spikes / uptime)
• Peering agreements (staying connected to major IPFS peers for reliable retrieval)
• Content moderation (preventing illegal content from being served through your domain)
• Abuse protections (making sure only intended users are using your gateway)

Using a Managed Service such as Pinata

For teams wanting a fully featured drop-in replacement, IPFS services like Pinata offer managed dedicated gateways as a service. These gateways are enterprise scale, and come with critical enhancements out of the box such as:

• Global auto-scaling infrastructure
• A built in Content Delivery Network
• Analytics systems for gateway activity
• Image resizing capabilities
• Gateway access controls
• Built in abuse / content moderation

Because Pinata handles all of this for you, your team can focus on the things that truly matter instead of dealing with the complexities of IPFS content retrieval.

Once you have a running gateway, all you need to do is replace "ipfs.io" in your application with your new dedicated gateway domain and things will automatically start working again with full backward compatibility.

If you want to make sure that your new gateway works with all places you ingest content with IPFS, such as alternative gateways or on-chain coded IPFS content identifiers (CIDS), our SDK comes with a built in helper function that easily handles this for you.

Long term sustainability

The ipfs.io gateway served a very useful purpose for much of the IPFS ecosystem by making IPFS easily accessible for those joining the ecosystem. As IPFS has matured, unfortunately many projects came to rely on it as a free content delivery network, which came with enormous costs for its maintainers. Now it's time for IPFS to take its next step and move content retrieval into a much more distributed model of gateway ownership. Doing so will ensure IPFS continues to thrive for years to come instead of relying on unsustainable subsidies.

Need additional help?

Pinata's team has been around for 8+ years, solving some of the hardest problems in IPFS and decentralized storage. If you need any help with your migration, reach out to us at [email protected] and we'd love to help.