IPFS Bootstrap Nodes and How a New Node Finds Its Peers

IPFS bootstrap nodes are well-known peers that a new IPFS node dials first, so it can learn about other peers and join the Amino DHT. Shipyard's IPFS work, including these nodes, ended on September 30, 2026, yet the four main bootstrap hosts still answered our test on October 28.

TL;DR:

• A bootstrap node only introduces your node to other peers, and your content lives on whichever peers provide it
• Kubo dials its bootstrap list whenever it has fewer than 4 open connections, checks every 30 seconds, and saves up to 20 connected peers each hour as backups
• The default list is the placeholder auto, which Kubo resolves from a manifest at conf.ipfs-mainnet.org
• On October 28, 2026, the four bootstrap.libp2p.io DNS records pointed to hosts under bootstrap.ipni.io, and all four hosts answered a libp2p multistream request from us
• You change the list with ipfs bootstrap add and rm, and you should only add peers you trust

What are IPFS bootstrap nodes?

The IPFS docs define the bootstrap list as "a list of peers with which the IPFS daemon learns about other peers on the network." Think of it like the first page of numbers in a new phone: you call one, get introduced to friends, and soon you no longer need that page.

In a 2022 forum thread, an IPFS developer said bootstrap peers get no special trust beyond being in the default list, and that any publicly reachable DHT server could fill the role. The default ones are run by a known team so random people don't get flooded with traffic.

A bootstrap node also doesn't hold your files, because it is only the entry ramp onto the network. Our guide to types of IPFS nodes explains how it differs from relay and delegated routing nodes. Once your node knows enough peers, lookups go through the DHT and Bitswap like any other request.

How does a new IPFS node find its first peers?

Kubo's bootstrap loop comes from the boxo library, and its defaults fit in a few lines. If your node has fewer than 4 open connections, it dials peers from the bootstrap list, gives each attempt 10 seconds, and repeats the check every 30 seconds.

Those first connections only open the door, and the DHT then runs its own bootstrap, issuing random queries that discover more peers and fill the routing table. From there, your node can find providers for a CID without ever touching a bootstrap peer again.

As a safety net, Kubo saves up to 20 of the peers it is connected to every hour as temporary bootstrap peers. After a restart, it dials those backups only after the configured list, and only if it still has too few connections.

Two other paths need no bootstrap list at all: mDNS finds nodes on your local network, and Peering.Peers keeps connections to peers you name. The addresses themselves are libp2p multiaddrs that can travel over TCP or QUIC.

The default list after Shipyard's exit

On August 24, 2026, Shipyard wrote that it would stop operating "the IPFS bootstrap nodes" along with ipfs.io, dweb.link and delegated-ipfs.dev. Its final day of IPFS work was September 30, 2026, and Protocol Labs would decide what happened next. Our post on the new stewards of the ipfs.io gateway covers the wider handover.

The IPFS blog answered on October 14, saying the project will keep operating "the bootstrappers that help new nodes find their first peers." It also named the IPNI and Compass team as an infrastructure provider for "resilient bootstrapping."

You can check the result yourself, because the default names are published in DNS, and we ran these lookups on October 28, 2026:

$ dig +short TXT _dnsaddr.bootstrap.libp2p.io
"dnsaddr=/dnsaddr/ny5.bootstrap.libp2p.io/p2p/QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa"
"dnsaddr=/dnsaddr/sg1.bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt"
"dnsaddr=/dnsaddr/am6.bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
"dnsaddr=/dnsaddr/sv15.bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN"

$ dig +short TXT _dnsaddr.am6.bootstrap.libp2p.io
"dnsaddr=/dns4/lith-1.bootstrap.ipni.io/tcp/4443/wss/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
"dnsaddr=/dns4/lith-1.bootstrap.ipni.io/udp/4001/quic-v1/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"
"dnsaddr=/dns4/lith-1.bootstrap.ipni.io/tcp/4001/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb"

All four names keep the peer IDs listed in the IPFS docs and now resolve to hosts under bootstrap.ipni.io. We then opened a TCP connection to each host and sent the libp2p multistream header, and all four sent it back, as did the long-standing address 104.131.131.82.

The one gap was the js-libp2p node at va1.bootstrap.libp2p.io, which timed out from our machine in repeated tries on TCP 4001 and HTTPS 443. That is a single vantage point, so it doesn't prove an outage. The AutoConf manifest still lists all seven addresses, and its file was last modified on September 3, 2026.

What happens if the bootstrap nodes go offline?

A fresh node with no reachable bootstrap peers starts with an empty routing table. In that same 2022 thread, the developer put it plainly: you then "cannot request / serve any content via internet." The reply noted it had already happened once, because of configuration issues in the infrastructure.

A node that has run before is in better shape, because it can dial the backup peers it saved. AutoConf also falls back to a hardcoded copy of the mainnet list when it can't fetch the manifest and has no cached copy. The weak spot is a brand new install, or a list with a single entry. The IPFS docs warn that a node with one bootstrap peer loses the Amino DHT on restart if that peer goes offline.

The docs also call these nodes public utilities offered "on a best-effort basis," and add that they are "not intended to be part of your critical path." So if your service depends on a node joining the network quickly, you can list a few peers you run yourself next to auto.

Changing the bootstrap list in Kubo

The commands below come from the IPFS docs page "Modify the bootstrap list," and we did not run them because this machine has no IPFS binary.

ipfs bootstrap list                  # prints: auto
ipfs bootstrap list --expand-auto    # shows the resolved addresses
ipfs bootstrap rm --all              # empty the list
ipfs bootstrap add /ip4/25.196.147.100/tcp/4001/p2p/QmaMqSwWShsPg2RbredZtoneFjXhim7AQkqbLxib45Lx4S
ipfs bootstrap add --default         # put the auto placeholder back

With auto in place, removing a single peer returns an error, so you replace auto first or clear the list. An empty list turns off all bootstrap dialing, including the saved backups. Kubo's help text calls these your "trusted peers," and the docs warn that a malicious bootstrap peer could introduce you only to other malicious peers.

The most common reason to change the list is a private IPFS network, where the public bootstrap peers can't connect at all. Light clients that skip the DHT entirely use delegated routing instead.

How AIOZ Pin handles it

With AIOZ Pin, you don't run the node, so you never manage a bootstrap list. The FAQ says the service "eliminates the need for you to manage and monitor your own IPFS nodes." Your app talks HTTPS to api.aiozpin.network, and we look after the nodes behind it.

The docs also say that pinned content "becomes available on the public IPFS network," so anyone running a node can fetch it once that node has bootstrapped. When your own node already holds a CID, you can pin it by CID without uploading it again, using this request from the docs (not run here):

curl --location --request POST 'https://api.aiozpin.network/api/pinning/pinByHash' \
--header 'pinning_api_key: KEY' \
--header 'pinning_secret_key: SECRET' \
--header 'Content-Type: application/json' \
--data-raw '{
    "hash_to_pin": "Qmc1135ziMvmFG534i75E8HpJoLqzLzgKBxfjBV9cBsMAs",
    "metadata": { "name": "name-ipfs-hash" }
}'

The AIOZ Pin docs don't describe how our own nodes bootstrap or which peers they use.

Next step: read the AIOZ Pin pinning API docs.

Frequently Asked Questions

What is an IPFS bootstrap node?
It is a well-known peer that a new IPFS node dials first to learn about other peers and join the Amino DHT.

Do bootstrap nodes store my files?
No. They only introduce your node to other peers, and your content is fetched from whichever peers provide it.

Who runs the IPFS bootstrap nodes after Shipyard?
The IPFS blog post of October 14, 2026 says the project keeps operating them, with the IPNI and Compass team providing resilient bootstrapping.

Can I run my own bootstrap node?
Yes. Any publicly reachable node running a DHT server can act as one, and you add its multiaddr with ipfs bootstrap add. Our guide to multiaddrs and peer IDs explains how to read the /p2p/ part that names which peer must answer.

Does Helia use the same bootstrap list?
Helia takes its bootstrap peers from the libp2p peerDiscovery option, according to the IPFS docs on node types.

Related Reading

• Types of IPFS Nodes: the three node roles
• IPFS Private Network: bootstrap peers for a private swarm
• How IPFS Finds and Retrieves Files: what happens after bootstrap
• Helia: IPFS in JavaScript

References

• IPFS Docs: Modify the bootstrap peers list
• IPFS Docs: Public IPFS Utilities
• IPFS Docs: Nodes
• Kubo config docs: Bootstrap and AutoConf
• boxo: bootstrap/bootstrap.go
• Shipyard: The end of IPFS at Shipyard
• IPFS Blog: New Stewards for Public IPFS Network Services
• IPFS Forums: What if IPFS's public DHT bootstrap shutdown?
• AIOZ Pin Docs: Pinning API