Types of IPFS Nodes: The Different Roles, Explained

Ask "what types of IPFS nodes are there" expecting an answer like a blockchain's full-node-vs-light-client split, and the real answer looks different: IPFS's own documentation frames node types around specific, opt-in jobs a node can take on for the network, not a weight class every node fits into. This article covers those actual roles, plus the more everyday question of how much of the stack you personally have to run to use IPFS at all.

TL;DR:

• IPFS's documentation defines node roles by function, not by weight class: relay nodes, bootstrap nodes, and delegated routing nodes each do a specific job for the network
• A relay node implements Circuit Relay v2, acting as a go-between so peers that can't connect directly (behind restrictive NATs) can still reach each other
• A bootstrap node helps other IPFS instances find peers on the DHT in the first place, an entry point into the network rather than a destination
• A delegated routing node offloads routing lookups to a plain HTTP API, which is how browsers and other constrained environments participate without running a full DHT client
• Separately, and more practically for most users: you can run a full Kubo daemon, a browser-based Helia light client, or rely entirely on a gateway with no node at all, three genuinely different levels of participation

Not a Weight Class, a Set of Jobs

Some networks split nodes cleanly into "full" and "light" based on how much state they store. IPFS's documentation doesn't frame node types that way. Instead, it describes distinct functional roles a node can opt into, on top of whatever base participation level it's already running at. A single node can take on more than one of these roles simultaneously, or none of them, participating in basic content exchange without ever acting as a relay, bootstrap point, or routing server for anyone else.

Relay Nodes: The Go-Between for Unreachable Peers

Not every peer can connect to every other peer directly, restrictive NATs and firewalls get in the way constantly. A relay node implements the Circuit Relay v2 protocol, functioning, in the documentation's own words, "as a kind of VPN in an attempt to reach the unreachable node." Two peers that can't establish a direct connection can still communicate by routing through a relay node that both of them can reach, at the cost of that extra hop. This is the same NAT-traversal machinery covered in more depth in this series' libp2p article, relay is one of several techniques (alongside AutoNAT and DCUtR hole-punching) libp2p uses to keep peers reachable despite an internet that doesn't make direct connections easy.

Bootstrap Nodes: The Network's Entry Points

A bootstrap node exists to help other IPFS instances "find peers on the DHT" when they first join the network. It's part of the Amino DHT and serves as a known, stable connection point a fresh node can reach out to before it's discovered any peers of its own. Bootstrap nodes aren't where content ultimately gets found or retrieved, they're the entry ramp onto the network, the first hop that gets a new node connected to enough peers to start doing real DHT lookups on its own.

Delegated Routing Nodes: Offloading the DHT Entirely

A delegated routing node offloads routing work to a Delegated Routing V1 HTTP API instead of running DHT lookups itself. This is particularly useful "in browsers and other constrained environments" that can't reasonably act as full DHT participants, maintaining the connections and routing tables a real DHT lookup needs is genuine ongoing work, unsuited to a browser tab's lifecycle. This series has a dedicated article on exactly how this works, the V1 API's endpoints, the someguy reference server, and the separate Network Indexer backend, since it's substantial enough to deserve its own full treatment rather than a summary here.

The More Practical Question: How Much of the Stack Do You Run?

Separate from those three official roles, there's a more everyday spectrum worth naming clearly, since it's what most people actually mean when they ask "what kind of IPFS node should I run":

• A full Kubo daemon. Runs the complete IPFS stack yourself: DHT participation, Bitswap, its own storage. Real control, real operational responsibility.
• A browser-based Helia light client. Participates in IPFS from inside a web page, relying on delegated routing rather than a full DHT implementation, exactly the constrained-environment case delegated routing nodes exist for.
• No node at all, gateway-only. Retrieving content through a gateway's plain HTTP response, with zero IPFS-specific software running client-side.

These three aren't officially named "node types" in IPFS's own documentation, but they're the practical decision most people are actually making, and they connect directly to the official roles above: a Helia client in a browser is a textbook case of relying on a delegated routing node, precisely because running its own bootstrap or relay logic isn't realistic in that environment.

Where AIOZ Pin Sits on This Spectrum

AIOZ Pin's own infrastructure runs full nodes, participating fully in DHT, Bitswap, and content routing on behalf of everything pinned through it. A developer integrating AIOZ Pin's SDK or API, though, doesn't need to run any node at all, requests go through AIOZ Pin's gateway, which already holds the content directly. That's the gateway-only end of the spectrum by design: all of the node-level complexity above is AIOZ Pin's problem to run, not the integrating application's.

Frequently Asked Questions

What are the official types of IPFS nodes? IPFS's documentation defines node roles by function: relay nodes (Circuit Relay v2, connecting otherwise-unreachable peers), bootstrap nodes (DHT entry points for new peers), and delegated routing nodes (offloading routing lookups to an HTTP API).

Is there a "full node vs. light client" split in IPFS like some blockchains have? Not officially in IPFS's own documentation. In practice, though, running a full Kubo daemon, a browser-based Helia client, or relying entirely on a gateway represent three genuinely different levels of participation.

What does a relay node actually do? It acts as a go-between for peers that can't connect to each other directly, typically because of restrictive NATs, functioning similarly to a VPN to make an otherwise-unreachable peer reachable.

Why would a browser use delegated routing instead of running its own DHT node? Maintaining DHT connections and routing tables is real, ongoing work unsuited to a browser tab's lifecycle. Delegated routing gets the same answers over a simple HTTP API instead.

Do I need to run an IPFS node to use AIOZ Pin? No. AIOZ Pin's infrastructure runs full nodes on your behalf. Integrating through its SDK, API, or gateway requires no node-level software on your side at all.

Related Reading

• libp2p: The Networking Layer Underneath IPFS - the NAT-traversal mechanics (relay, AutoNAT, DCUtR) behind relay nodes specifically
• Delegated Routing: How Light Clients Skip Running a DHT - the full mechanics of delegated routing nodes, only summarized here
• Helia: IPFS's Modern JavaScript Implementation - the browser-side client that relies on delegated routing in practice
• How IPFS Finds and Retrieves Files: DHT and Bitswap - what bootstrap nodes are actually helping a new peer get access to

References

• IPFS Docs: Nodes