Why we had to stop using Cloudflare’s IPFS Gateway
We had decided to service certain static assets for MiningClub.app using IPFS and Cloudflare’s IPFS Gateway.
The solution was rather genius. IPFS Gateway allowed us to deploy our assets to IPFS and have them visible on the website. We used a popular pinning service and then set the DNS ipfs.miningclub.app to point the newly deployed IPFS CID.
It took a few minutes for Cloudflare to discover the newly deployed content, but this was expected. This was how IPFS works.
The problems started happening when content wasn’t regularly requested. It seems like Cloudflare’s IPFS Gateway will cache content, but it won’t hold that cache forever. When this happens, your assets will fail with an http status of 429.
This resulted in our web app displaying a bunch of content that wouldn’t load.
Many errors in the console show an http status of 429, which is usually reserved for “too many requests” yet this would only happen on first load. Wait 5 minutes and refresh and all the errors go away.
We expected Cloudflare’s IPFS Gateway setup with DNS to replace our static asset folder (like S3 or Cloudflare’s R2). Since the IPFS CID was set in the DNS we incorrectly assumed Cloudflare would cache these files and keep them available.
This wasn’t the case and because of this, we have chosen to stop using Cloudflare’s IPFS Gateway service for something more traditional and reliable.
We also could have served the files through our pinning service’s HTTP Gateway, but we’re on the free plan and there are cheaper places to serve static assets than the first paid tier.
Web3 is amazing and full of limitless potential, but it’s just not ready to serve static assets to a Web2 world today.
Cheers 🍻
