IPFS Home Lab: Public Node and DHT Review

This document summarizes the IPFS Home Lab presentation session, focusing on a comparison of IPFS node operation architectures, DHT mechanics, bandwidth cost control strategies, and a practical hybrid deployment proposal.

Comparison of IPFS Architecture Types

1. Public Home Node

This is the optimal configuration for environments with a static public IP and unmetered bandwidth. Using a business-grade router (e.g., Fortinet) makes port forwarding straightforward, and the IPFS node can be operated as a full DHT server, eliminating the need for external pinning services such as Pinata. Advantages include low cost, data sovereignty, and freedom from external dependencies. Drawbacks include the need to directly manage port forwarding and IP exposure, and the risk of becoming unreachable when the ISP's DHCP lease changes if Dynamic DNS is not configured.

2. Old Client Mode (Node Behind NAT)

This is the default configuration that operates within a NAT environment without router setup, and is Kubo's default option. Setup is simple and there is no IP exposure, but a critical drawback exists. An old client is not a DHT server, and therefore cannot directly reprovide its own content to the DHT. While initial propagation is possible via bootstrap nodes, after several weeks to a month the DHT records expire, causing content to disappear from the network — a silent failure. A real-world experience was shared in which this issue forced a migration to Pinata, and a subsequent attempt to migrate to Fly.io incurred bandwidth costs of $18 per day.

3. VPS Hybrid Deployment

This is the currently recommended architecture, in which a VPS node operates as the DHT server while the home node holds the actual data. The VPS, with its high availability and reachability, handles DHT propagation, while the home node maintains persistent peering with the VPS to continuously advertise content CIDs. This resolves the IP-change problem on the home network and reduces costs compared to Pinata or a full VPS node. However, comprehensive testing has not yet been completed.

Key Discussion on DHT and Bandwidth

The DHT (Distributed Hash Table) propagates content location information across peers, similar to BitTorrent. Because IPFS uses a gossip protocol, bandwidth consumption is high, and the inbound/outbound traffic ratio on a home network can appear abnormal — leading some ISPs to block the connection. Korea's KT installing spyware on BitTorrent users was cited as an example of ISP-level risk.

Regarding peer count limits, the highWater / lowWater options in the IPFS configuration can cap the number of connected peers. More peers result in faster DHT propagation and better content reachability, while fewer peers slow gossip propagation and make CID discovery more difficult. It was emphasized that failing to control peer count on cloud platforms such as AWS can cause costs to spike sharply.

For provider strategies, two options were introduced: the roots strategy, which advertises only root CIDs, and the pinned+MFS strategy, which advertises all CIDs of pinned files. The pinned+MFS strategy is recommended when minimum bandwidth is the priority; the roots strategy does not advertise child CIDs, which increases the number of peer hops required during download.

Docker Containerization and Resource Control

It was noted that the IPFS community does not actively share methods for limiting node performance — analyzed as stemming from an unspoken norm similar to BitTorrent culture's "leech taboo." As a practical alternative, resource limiting via Docker and Docker Compose was proposed. Memory and CPU caps can be set through Docker Compose, but bandwidth limits cannot be imposed via Docker Compose alone. Disabling private services was also recommended in order to reduce relay traffic.

The session's final proposal is to implement all the architectural decisions and configurations discussed as a single Dockerfile and Docker Compose file, with the goal of providing a verified image that anyone can deploy with ease.

Many-to-Many Peering and Community Operation Models

A 1:N structure — one VPS DHT server connected to multiple home nodes behind NAT — is feasible, and an N:N structure with multiple DHT servers and multiple home nodes is also supported. This is analogous to BitTorrent's tracker–seeder structure. An ideal use case proposed was operating a closed community DHT server by sharing authentication credentials only within a specific group. For the deployment guide, it was suggested to cover only the home node configuration, with the VPS DHT server address specified via environment variable.

Conclusion and Next Steps

The discussion converged on the VPS hybrid architecture as the most suitable configuration for long-term operation. The main follow-up tasks are as follows:

Compose a Docker image that minimizes resource usage on the home node, enabling lightweight operation on a Raspberry Pi or Fly.io

Reduce bandwidth costs by applying highWater/lowWater peer-count limits and the pinned+MFS provider strategy

Write a deployment guide that includes persistent peering configuration between the VPS DHT server and the home node

Conduct an actual DHT server–home node connection experiment at the Shikoku workshop to gather research data, and consider publishing the results