Operational Deep-Dive: 3-Node IPFS Cluster in Romania
This page is for operators who have outgrown a single-node Kubo pinning service and need real redundancy without changing jurisdiction. An IPFS Cluster across three Romania VPS nodes gives Raft consensus on the pin set, parallel Bitswap serving from multiple endpoints, and the operational flexibility to do rolling upgrades without dropping availability. This is a deep-dive, not an overview - we assume you already understand the single-node pinning workload from the main Romania pinning page.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Cluster Topology
Three Romania VPS V tier nodes, each running Kubo with badger v4 plus ipfs-cluster-service. Raft consensus across the three. Cluster secret shared via secure channel out of band. Pin replication factor: rmin=2, rmax=3. New pins propagate via Raft to all three; serving is round-robin from your client-facing nginx.
Choose the three nodes from the same Romania region but on different physical hosts. Anubiz Host VPS placement gives you that without exposure to specific datacenter details. The three-node minimum is required for Raft quorum tolerance of one node failure.
Secret Management
The cluster secret is the cluster's identity. Anyone with the secret can join, sync the pin set, and disrupt the cluster. Treat it as a credential of the same class as a root SSH key. Store in a secret manager (Vault, sops with age, bitwarden); never commit to git.
Rotation is operationally heavy - you stop services, change the secret in all node configs, restart in a controlled order. Plan to rotate annually or after any suspected compromise.
Pinning Operations
Pin via the cluster API: ipfs-cluster-ctl pin add CID --rmin 2 --rmax 3. Status: ipfs-cluster-ctl status CID. Removal: pin rm. The cluster propagates to all three nodes; serving comes from whichever node a Bitswap request reaches first.
For a paid pinning SaaS, integrate the cluster API into your billing layer. Customer creates pin, your service authenticates the request, calls cluster API with rmin/rmax based on customer tier, returns the CID metadata.
Failure Modes and Recovery
Single node failure: cluster continues with two-node quorum. Replace the failed node, configure it, rejoin via cluster bootstrap. Pin set replicates automatically.
Two node failure (loss of quorum): cluster goes read-only. Recover by manually promoting a surviving node to bootstrap, then re-add nodes. Document this in your runbook.
Total cluster loss: rebuild from your pin list export. Always export the pin list nightly to a separate location.
Internal Links
Related Services
Why Anubiz Host
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.