Building a Multi-Region IPFS Cluster: How to Deploy 3 Distributed VPS Nodes for Permanent Data Redundancy

Introduction: The Imperative for Decentralized Data Resilience

In the digital economy, data availability is synonymous with business continuity. Traditional centralized cloud storage providers offer high uptime, yet they remain vulnerable to localized infrastructure outages, regional networking failures, and shifting compliance landscapes. For enterprises seeking absolute data permanence, the InterPlanetary File System (IPFS) presents a paradigm shift.

However, running a standalone IPFS node introduces a critical risk: if that specific node goes offline, your content may become inaccessible to the network. To guarantee that files are retained permanently and reliably, businesses must deploy an IPFS Cluster. By structuring this cluster across three Virtual Private Servers (VPS) situated in distinct geographic regions, you create a self-healing, highly redundant storage network. This architectural blueprint details the exact methodology for engineering a multi-region IPFS Cluster designed for maximum data longevity.

Understanding the Architecture: IPFS vs. IPFS Cluster

Before initiating deployment, it is vital to distinguish between the base IPFS protocol and the IPFS Cluster management layer:

IPFS (Kubo): Responsible for the actual storage, content-addressing (using CIDs), and bitswap data transfer between peers.
IPFS Cluster: A separate orchestration tool that runs alongside each IPFS daemon. It coordinates which nodes allocate, pin, and replicate specific CIDs, ensuring automated data distribution across the entire collective.

By leveraging three VPS instances in separate global regions (e.g., North America, Europe, and Asia-Pacific), the cluster achieves data survival even if two complete data centers experience a catastrophic blackout simultaneously. This structure relies on a consensus mechanism—typically Raft or CRDT—to synchronize pinning states seamlessly across all participating nodes.

Prerequisites and Infrastructure Provisioning

To follow this guide successfully, you must provision three Linux-based VPS instances. For production workloads, the following baseline specifications are highly recommended for each node:

Recommended Per-Node Specs: Ubuntu 22.04 LTS or 24.04 LTS, 2 vCPUs, 4GB RAM, and dedicated SSD storage scaled to your anticipated data footprint.

Ensure that each VPS is located in a completely different geographical zone. For example:

Node 1 (Leader/Bootstrap): Frankfurt, Germany (EU)
Node 2 (Follower): Singapore (APAC)
Node 3 (Follower): New York, USA (NA)

Additionally, you must configure your cloud firewalls to allow communication across critical ports. Open Port 4001 (TCP/UDP) for IPFS Swarm traffic, Port 9094 (TCP) for HTTP REST API cluster interaction, and Port 9096 (TCP/UDP) for internal cluster communication.

Step 1: Installing IPFS and IPFS Cluster Daemons

Execute these installation commands on all three VPS instances. We will utilize the official pre-built binaries provided by Protocol Labs.

First, download and install the core IPFS daemon (Kubo):

wget [https://dist.ipfs.tech/kubo/v0.31.0/kubo_v0.31.0_linux-amd64.tar.gz](https://dist.ipfs.tech/kubo/v0.31.0/kubo_v0.31.0_linux-amd64.tar.gz)
tar -xvzf kubo_v0.31.0_linux-amd64.tar.gz
cd kubo
sudo ./install.sh
ipfs init --profile server

Using the --profile server flag is highly critical; it optimizes the configuration by preventing IPFS from generating excessive local network discovery traffic, which can lead to your VPS being flagged or throttled by cloud hosting providers.

Next, install the IPFS Cluster service and client tools on all nodes:

wget [https://dist.ipfs.tech/ipfs-cluster-service/v1.1.0/ipfs-cluster-service_v1.1.0_linux-amd64.tar.gz](https://dist.ipfs.tech/ipfs-cluster-service/v1.1.0/ipfs-cluster-service_v1.1.0_linux-amd64.tar.gz)
tar -xvzf ipfs-cluster-service_v1.1.0_linux-amd64.tar.gz
cd ipfs-cluster-service
sudo cp ipfs-cluster-service /usr/local/bin/

wget [https://dist.ipfs.tech/ipfs-cluster-ctl/v1.1.0/ipfs-cluster-ctl_v1.1.0_linux-amd64.tar.gz](https://dist.ipfs.tech/ipfs-cluster-ctl/v1.1.0/ipfs-cluster-ctl_v1.1.0_linux-amd64.tar.gz)
tar -xvzf ipfs-cluster-ctl_v1.1.0_linux-amd64.tar.gz
cd ipfs-cluster-ctl
sudo cp ipfs-cluster-ctl /usr/local/bin/

Step 2: Configuring the Cluster Secret and Initializing Node 1

Security within a private or semi-private cluster relies on a shared 32-byte cryptographic key called the Cluster Secret. Unauthorized nodes without this secret cannot join or see your data pinsets.

On Node 1 (Frankfurt) only, generate the secret key:

export CLUSTER_SECRET=$(od -vN 32 -An -tx1 /dev/urandom | tr -d ' 
')
echo "Your Cluster Secret is: $CLUSTER_SECRET"

Crucial Note: Copy this generated string carefully. You must export this exact environment variable onto Node 2 and Node 3 before initializing them.

With the secret exported on Node 1, initialize the cluster configuration utilizing the CRDT consensus model, which is superior for multi-region setups due to its dynamic membership properties:

ipfs-cluster-service init --consensus crdt

Start the IPFS daemon and the IPFS Cluster service on Node 1 to capture its unique Multiaddress identification string:

ipfs daemon &
ipfs-cluster-service daemon &

Run ipfs-cluster-ctl id to extract your cluster multiaddress, which will look similar to: /ip4/YOUR_NODE_1_IP/tcp/9096/p2p/Qm...

Step 3: Joining Node 2 and Node 3 to the Cluster

Move to Node 2 (Singapore) and Node 3 (New York). First, initialize the local IPFS configurations if you have not done so. Then, export the cluster secret generated from Node 1:

export CLUSTER_SECRET="PASTE_YOUR_NODE_1_SECRET_HERE"
ipfs-cluster-service init --consensus crdt

To bind these nodes to your primary bootstrap node, initiate the daemon using the --bootstrap flag followed by Node 1's full multiaddress:

ipfs daemon &
ipfs-cluster-service daemon --bootstrap /ip4/NODE_1_IP/tcp/9096/p2p/CLUSTER_PEER_ID &

Once both secondary nodes complete their initial connection, verify the structural integrity of your decentralized network from any node by executing:

ipfs-cluster-ctl peers ls

The system should output three distinct peers, listing their geographic IP addresses, versions, and proof of operational health status.

Step 4: Automating Failover and Permanent Storage Policies

To ensure files remain permanent, modify the cluster's replication factors within the configuration file located at ~/.ipfs-cluster/service.json. Look for the allocation parameters and set:

replication_factor_min: 2 (Ensures data must exist on at least two servers to be considered successful)
replication_factor_max: 3 (Instructs the cluster to mirror every single piece of content to all three VPS regions)

By enforcing a maximum replication factor equal to your total node count, you configure a complete mirroring strategy. If Node 1 experiences an unexpected system crash, Node 2 and Node 3 will continue serving the assets globally without a single millisecond of data unavailability.

Conclusion: Production Recommendations

Deploying a three-node, multi-region IPFS Cluster provides robust security against geographical hardware failures. To elevate this setup to enterprise-grade production quality, consider implementing systemd service files to automatically restart the IPFS daemons upon unexpected server reboots. Furthermore, incorporating reverse proxies with SSL termination (such as Nginx) in front of the IPFS Gateway allows you to securely expose data to standard web consumers while maintaining absolute cryptographic integrity across the decentralized backbone.