IPFS Dedicated Gateways Explained

When a file is uploaded to a traditional file storage method, how do you share that file with others? Sometimes it’s through account permissions, where you can add another user account that has permission to view the file, or other times it’s through a public URL link that provides access to the uploaded file.

When a file is uploaded to IPFS, a public, unique identifier called a CID is returned. This CID value is generated using a cryptographic hash that is based on the uploaded file’s content and metadata. For applications that support IPFS natively, only this CID value is needed to access and share the file. But for applications that don’t natively support IPFS yet, how can files be viewed and shared using their CID? That’s where IPFS HTTP Gateways come in.

IPFS HTTP Gateways

To bridge the gap between applications that don’t natively support IPFS and the content stored on the IPFS network, IPFS HTTP gateways can be used. As the same suggests, IPFS HTTP gateways use the HTTP protocol to serve content that’s stored on IPFS. Through gateways, content can be accessed using its CID from any web browser, piece of code, or application.

IPFS HTTP gateways use the following URL format:

At the fundamental level, an IPFS HTTP gateway is an IPFS peer that accepts HTTP requests that are made for IPFS CIDs. When a request for a CID is initiated using an IPFS HTTP gateway, the following steps occur:

1. The IPFS gateway node first checks if the CID has been cached locally before it attempts to retrieve it from the IPFS network. The cache can either be the local HTTP cache or the cache of the IPFS gateway node.
2. If the CID hasn’t been cached, it will need to be retrieved from the IPFS network.
3. The IPFS gateway node asks its direct peers if any of them are hosting the requested CID. If they aren’t, then it will query the DHT to find peer IDs and network addresses of peers that are currently hosting or pinning the requested CID.
4. The IPFS gateway node will connect to one of the peers with the CID, fetch the CID’s content, then relay the response to the client that requested the CID.

There are two types of IPFS gateways: public and private.

Public gateways are used to retrieve any CID stored on IPFS. They aren’t scoped to any specific file or set of files and can be used by anyone in the world to access a CID’s content. Public gateways allow anyone to use HTTP to retrieve CIDs from the IPFS network.

There are two forms of private IPFS gateways: dedicated and self-hosted. Dedicated gateways are an IPFS gateway that’s typically offered by IPFS pinning providers which allow you to access CIDs using your own private dedicated gateway URL. One of the benefits of using a dedicated gateway is that they are not limited to the same rate limits that public gateways are.

Self-hosted gateways refer to an IPFS node that you host yourself that is configured to act as an IPFS gateway. Self-hosted gateways are not limited to rate limits either, but require IPFS to be running and managed by you for functionality.

Many users choose an IPFS pinning service that offers dedicated gateways so they can avoid hosting and maintaining IPFS nodes themselves.

Filebase’s IPFS Dedicated Gateways

Filebase’s IPFS dedicated gateway offering features additional benefits and configuration options when compared to other dedicated gateway solutions. With Filebase, you are able to create your own dedicated gateways that can be configured as public, private, or scoped.

• Public: The gateway can serve any public CID, even ones not pinned by Filebase.
• Private: The gateway can only serve CID's that are pinned by Filebase.
• Scoped: The gateway is tied to a bucket and can only serve content from that specific bucket. Any CIDs for content not stored in the specified bucket will return a 404 Not Found message.

Dedicated gateways of any type are not subjected to rate limits. Additionally, individual CIDs can be set as the ‘root’ CID of a dedicated gateway. That means instead of needing to input the CID in the URL to request the content, if the CID is set as the ‘root’ of the gateway, no CID is needed since the gateway is configured to serve that CID by default.

Each dedicated gateway is assigned a custom URL in the format of:

https://gateway-name.myfilebase.com

Dedicated gateways can be given names that reflect branding, the content that it serves, or any other unique value. Filebase dedicated gateway names are subject to the same naming restrictions as bucket names. All gateway names must be lowercase, between 3-63 characters, and must be unique.

Why You Should Use Dedicated Gateways

Why should you use a dedicated gateway over a public gateway? Dedicated gateways provide benefits like providing a scoped way to serve content stored in a bucket, or serve a single CID at the root of the gateway which allows for the CID to be served using a human-readable URL.

A few use cases for dedicated gateways include:

• Branded IPFS URLs for projects and applications.
• Serving static webpages, such as personal webpages like resumes or portfolios.
• Content restriction, such as only serving content stored in a specific bucket.
• Serving NFT data for marketplaces.
• Serving metadata world data.
• Serving blockchain gaming assets.
• Serving streaming content, like videos or music.

You can learn more about how to use Filebase’s dedicated gateways here.

Ready to get started using IPFS dedicated gateways? You can sign up for a Filebase account here. Please note that IPFS dedicated gateways are a paid feature and will require a paid Filebase IPFS subscription.

If you have any questions, please join our Discord server, or send us an email at hello@filebase.com.