Kubo vs Helia vs Elastic-IPFS: Comparing the major IPFS implementations

IPFS is a peer-to-peer, content-addressable, file-sharing protocol that acts as a crucial data layer for those looking to store and retrieve data in a distributed verifiable manner. One of the reasons IPFS has seen such wide adoption is due to many different implementations that exist for working with IPFS.

When looking to develop with IPFS, options can be overwhelming. Which implementation is right for you? Well, it depends! In this guide we’ll compare three major IPFS implementations, against a few key benchmarks.

The three IPFS implementations we’ll be comparing in this guide are:

• Kubo (formerly known as go-ipfs)
• Helia (supercedes js-ipfs)
• Elastic-IPFS

The three benchmark categories we’ll talk through are:

• Ease of working with
• Feature set
• Scalability

‍

Ease Of Working With

Kubo

Kubo requires a bit of command-line experience to get running, and the complexity can depend a bit on the operating system you’re working with (MacOS being the easiest), but once Kubo is installed, running and interacting with your own local IPFS node is easy.

Kubo acts as an all-in-one IPFS “daemon” that once running, lets the user interface through it either through an RPC interface or via an easy-to-use CLI that comes baked into the Kubo implementation.

As you learn more, for those looking to customize things, Kubo also has an extensive configuration file that lets the user fine-tune a Kubo instance to their specific use case.

Another big win for kubo is the mature documentation surrounding it. As Kubo is the oldest IPFS implementation, the documentation is extensive and covers almost any questions that you could have when working with it.

Overall, if you’re looking to get started playing with IPFS as quickly as possible, Kubo is an excellent implementation to do so with.

Helia

Unlike Kubo, which can operate as a standalone process / IPFS process, Helia is intended to be a lightweight, modular component that is built into container NodeJS or Browser applications.

This “container” can range from a single NodeJS file that runs a Helia instance up to a larger application that uses Helia in complex ways.

This is a powerful paradigm for those building in JS ecosystems. The ability to configure and run an IPFS instance within the same process as your main application can reduce complexity and lead to faster development cycles.

As of the time of this guide (insert date here), Helia is still a newer implementation of IPFS, and the documentation is not quite as extensive as implementations like Kubo. For those just getting started this likely won’t present a huge issue, but for those building more complex IPFS applications, you may need to dig into the Helia source code a bit to answer your questions.

Elastic-IPFS

Elastic IPFS’s cloud-native setup means that teams looking to build with it will need comprehensive knowledge of automated code deployment tooling, networking, and cloud-computing services. Specifically, you’ll need to understand the following AWS services:

• DynamoDB
• S3
• Lambda
• Route53
• EKS
• ELB
• VPC
• SQS

On the documentation side, Elastic-IPFS does include some helpful diagrams / ReadMe files that explain things like key concepts and configuration setups, but those planning to work with Elastic-IPFS should plan on reading source code to answer many of their questions.

In short, the barrier to entry is relatively high for Elastic-IPFS.

‍

Feature Sets

Kubo

Kubo’s describes itself as a “generalist” implementation with an extensive API and its feature set reflects that. While many of these features can be built on top of other implementations, Kubo shines by supporting these features “out of the box” as a standalone process without the need for additional coding or applications.

Notable features include:

• Extensive configuration options through the Kubo config that enable things like:
• API restrictions and access controls
• Resource limits/tuning
• Built-in HTTP RPC API for interacting with Kubo and the rest of the IPFS network
• Built-in CLI access to the Kubo API
• Built-in IPFS gateway
• Ability to auto-replicate pins to external pinning services

For a full list of features, check out the official kubo repo!

Helia

Helia’s most powerful feature is the ability to be configured and run as part of a native JS application. This gives it the ability to easily run in-browser which isn’t something other IPFS implementations can currently do without very creative engineering work.

We mentioned earlier that Helia aims to be lightweight and modular. This means that Helia is very intentional about what is included in Helia itself. From a feature set standpoint, this means that Helia itself consists of core packages that outside libraries can interface with for adding features.

If a developer needs additional features, they can choose to bring in interfacing libraries to fit their needs. The Helia team also maintains a set of libraries that provide “common” IPFS functionalities seen in implementations like Kubo.

This approach gives the Helia team the ability to upgrade core components of Helia without worrying about breaking outside libraries as long as those libraries continue to adhere to the Helia implementation specs.

Elastic-IPFS

Elastic-IPFS could be more feature-rich. It does two things, but it does them very well:

• Store IPFS content
• Serve IPFS content

Operators working with Elastic-IPFS may wish to swap out certain components for modified versions or add additional features to the codebase, but the core Elastic-IPFS implementation will likely never support an expansive feature set as its goal, similarly to Helia, is to be lightweight and modular.

This, combined with the cloud-native setup of Elastic-IPFS, means that operators can update and modify portions of their IPFS setup without downtime as elastic-IPFS is just a combination of serverless components working together to act as a giant IPFS provider. This is an advantage over implementations like Kubo which require reboots/downtime to receive updates.

Other benefits to working with a cloud-native implementation of IPFS such as Elastic-IPFS is that operators can leverage additional cloud tooling on top of it for things like:

• Enhanced logging/observability
• Networking protections
• Data backup/deletion protection

‍

Scalability

Kubo

The scalability of a singular Kubo node depends on 3 main things:

• The physical hardware Kubo is running on (GB of memory/number of CPU cores)
• The network connection of the machine running Kubo
• The amount of content being worked with

While Kubo does provide an extensive list of settings that can help operators tune Kubo to their needs, ultimately a singular Kubo daemon can only scale so much before running into issues.

As such, Kubo is a great fit for many desktop-based applications (such as IPFS-Desktop), or projects serving smaller data sets, but can struggle as a standalone option when encountering large amounts of scale, especially when dealing with larger data sets that may need to periodically delete data.

For operations needing more scale, Kubo is often scaled by running multiple Kubo nodes in parallel through orchestration setups built on top of technologies such as Kubernetes. For those looking for a pre-built option, IPFS-Cluster is a pinset orchestration system that is designed to work specifically with Kubo nodes.

Helia

A notable area where Helia outshines other IPFS implementations right now is its implementation of a Reference Counting file system which offers considerable performance benefits vs Kubo when adding and removing content from IPFS. This gives Helia an edge when working with larger amounts of data.

However, Helia is similar to Kubo as the scalability of Helia also relies on:

• The physical hardware Helia is running on (GB of memory/number of CPU cores)
• The network connection of the machine running Helia

As such, many of the examples for Helia are focused on its usage in smaller-medium scale applications such as desktop or browser-based IPFS applications. There are a few examples of Helia being run in a server-type environment, but similarly to a user’s machine, these server environments also rely on the scalability constraints listed above.

Similarly to Kubo, Helia can be scaled by running multiple instances in parallel through orchestration technologies like Kubernetes. Unfortunately at the time of this writing, IPFS-Cluster is not yet compatible with Helia, so any parallel Helia orchestration would have to be custom-built.

Elastic-IPFS

Elastic-IPFS was purpose-built for a data-center scale.

Where other IPFS implementations can run into bottlenecks like hardware constraints, Elastic-IPFS takes a different approach by completely removing hardware limitations from the equation. It uses a modular, cloud-native design that breaks the core pieces of an IPFS implementation into serverless subsystems that each scale independently of each other.

In other words, Elastic-IPFS leverages battle-hardened cloud-based building blocks to provide an IPFS node that is fast, stable, and “auto scales” itself in a nearly infinite way.

Elastic-IPFS requires sizable engineering investment to properly run and maintain, but for projects needing massive scale, you certainly get that with Elastic.

‍

Honorable Mentions

Iroh

Iroh self describes itself as an “IPFS System”, in that it uses content identifiers (CIDs), but it is not an IPFS implementation. Iroh is a content-addressible protocol but diverges in a few critical areas which can be seen in their comparison table. Importantly, it should be noted that Iroh is not compatible with the “public” IPFS network that the IPFS implementations above operate on.

Similar to how new blockchains are inspired by learnings of pre-existing blockchains, Iroh is attempting to address a lot of the key learnings that the IPFS community has made over the years. However, to do this, the team made an intentional decision to sacrifice compatibility with the current public IPFS network.

These sacrifices have allowed Iroh to work efficiently in areas that traditional IPFS implementations are too resource-intensive to run in (such as mobile or IOT devices). In other words, Iroh can scale from mobile to data center and maintain performance the entire way.

If you’re building a project that needs content addressability but doesn’t require interoperability with the main public IPFS network, Iroh is a promising option to look into.

Nabu

Nabu is a Java-based implementation built by the team at Peergos. It’s a minimal IPFS implementation built for storing and transferring content over libp2p (the communication protocol of IPFS).

While Nabu is a minimal implementation, it makes some key additions to its IPFS implementation surrounding data privacy. Specifically, Nabu adds an authenticated bitswap layer which allows Nabu nodes to exchange data in an authenticated, privacy-preserving manner. It offers this while also maintaining interoperability with the public IPFS network (the data privacy functionality is completely optional).

Nabu also has some big wins on the performance front as well. In particular, when retrieving data. When benchmarked on a 2MB 6-layer data set consisting of 6000 blocks, Nabu was able to retrieve the dataset in 5 seconds compared to 120 seconds for Kubo.

A few items that developers should be aware of when working Nabu include:

• To maintain Nabu’s minimal profile, it deliberately does not have a built-in “file system” layer, meaning you’ll need to develop your own code for breaking down files into blocks before storing them with Nabu. While this provides more flexibility than a built-in file system, it is a bit different than systems like Kubo and Helia which come with unix-fs support already provided.
• At the time of this writing, Nabu lacks native support for Websocket and Webtransport layers. For many IPFS applications, this likely won’t pose a problem, but for those needing interoperability with in-browser IPFS nodes, this is a limitation to be aware of.

In summary, Nabu is a great choice for developers looking to build with IPFS in the JVM ecosystem, or those looking to build privacy-centric IPFS applications.

Pinning services

IPFS pinning services, such as Pinata, are platforms that essentially act as “IPFS as a service”.  They offer a way to offload the “hard” parts of IPFS and allow developers to focus on the things that matter most to their application. The features provided by pinning services can vary, but at a minimum, a pinning service should store content for the customer and make that content available on the general IPFS network.

Some pinning services offer additional functionality such as Dedicated IPFS Gateways, which allow for serving and retrieving of content on the IPFS network via an HTTP interface. This allows developers to serve / retrieve content in web-based applications or via API calls.

A topic that often comes up surrounding pinning services is decentralization. We talk about this a bit in our blog post here, but the short and sweet is that while pinning services themselves are centralized entities, IPFS is purpose-built so that multiple “centralized” providers can all work together to serve content in a decentralized way.

This means that projects can host themselves, host with a pinning service, or even better host in multiple places at once. The more places you store your content, the more decentralized/resilient it is. Many of our customers self-host, pin with Pinata, and host with other pinning services for a powerful blend of decentralization and speed.

Speaking of speed, those who add their content to pinning services receive the benefit of speed of access for those retrieving their content. This benefit exists at the peer-to-peer layer and the gateway layer. This is because pinning services, such as Pinata, have spent years building powerful infrastructure to make sure content hosted with them is quickly discoverable and retrievable throughout the IPFS network.

‍

Recommendations

So which IPFS is right for you? While the answer depends on your use case, here are a few use cases and recommendations.

Desktop Applications

For desktop applications, for example IPFS-Desktop, both Kubo and Helia are great candidates to work with. Having the ability to access the user’s local file system and add it straight to IPFS is something that both Kubo and Helia can do, which lets developers seamlessly add files to an IPFS node without needing to code this themselves.

In addition, for desktop applications, there’s usually one user per device at a time. This means the amount of content and resource requirements will likely be relatively small scale so leveraging the user’s local hardware (CPU and RAM) should work in most cases.

Of the two, Kubo is the most “feature-packed” version of IPFS for desktop applications to build on and can handle more “out of the box”, while Helia works well for people developing NodeJS-based apps such as those utilizing the electron framework.

For those looking for a way to sync users’ content to an IPFS pinning service for added speed/redundancy, Kubo and Helia both support remote pinning to services, such as Pinata, that support the IPFS pinning services spec. This allows content to stay available on the IPFS network even if the device running the local IPFS desktop application goes offline.

Websites and Browser Applications

For those building in browser-based environments, Helia is the clear winner here.

Instead of needing an external instance of IPFS that your application connects to, Helia’s native JS implementation allows developers to make IPFS a part of their application instead of something that exists outside of it.

Similarily to desktop applications, with browser applications, there’s usually one user per device, so leveraging the user’s local hardware should work fine here.

Similarly to desktop apps, IPFS pinning services also pair well with browser-based applications that need content to persist on the IPFS network past the users’ browser session.

Serverside Applications (small to medium scale)

For applications running applications server-side at a small (a few GBs) to medium (a few TBs) scale, Kubo is a relatively approachable option. It’s been around for quite a while and has a healthy amount of documentation and configurability to aid developers in their work.

As applications scale, multiple Kubo nodes can be run in parallel using orchestration software to get the application to more of a medium scale. Interfacing with kubo nodes can be done directly via its RPC API or through language-specific clients such as the js-kubo-rpc-client.

As with user-local applications, pinning services can be considered for additional IPFS retrieval speed/redundancy.

Cloud Applications (large scale)

For applications working at a large production scale, Elastic-IPFS should strongly be considered. It stores and serves IPFS content using a cloud-native IPFS setup that scales up and down as much as applications need.

The downside to Elastic-IPFS is that it requires a significant engineering investment to set up and properly maintain. For projects not working at a large scale, other implementations like Helia and Kubo should be considered.

‍

Conclusion

Developers looking to build with IPFS have a lot of options. Each option has tradeoffs and which one to use depends on project needs and constraints. Which implementation you decide on will depend on your individual use case, and the role IPFS plays in your specific project.

In nearly all cases, IPFS pinning services, like Pinata, provide a powerful option for those who need a solution that can scale with them at every stage of their application.

Building something interesting with IPFS and need advice? Reach out to us at [email protected]. We’d love to hear about it.

‍