Building a Production-Ready IPFS Infrastructure

Building a Production-Ready IPFS Infrastructure

Imagine: you launch an NFT collection of 10,000 tokens. Metadata and images are uploaded to IPFS via a public gateway. A month later, the node where all was pinned goes down—and metadata becomes unavailable. Collectors can't see attributes, marketplaces can't load previews. This cost one project 40% of secondary sales and reputation damage. That situation is a direct consequence of the illusion that IPFS automatically guarantees availability.

We build IPFS infrastructure that actually holds up under load and doesn't lose data. Turnkey: from hardware selection to monitoring setup and backup pinning across multiple services. Below is the real stack we use in production and specific numbers you can achieve.

Why Your Own Node Is Not a Luxury, But a Necessity?

Relying solely on public gateways (ipfs.io, dweb.link) is risky: they can limit RPM, block content by region, or simply go down. Your own node gives full control: limits tailored to your project, stable latency, and custom error handling. In practice, this means response times 3 times lower than through a public gateway and no rate limiting even at 10,000 requests per second.

┌─────────────────────────────────────────────────────┐ │ Your Application │ │ │ │ Upload: File → IPFS Node → CID → Smart Contract │ │ Fetch: CID → IPFS Gateway → File │ └───────────────────┬─────────────────────────────────┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ Your IPFS Pinata / Cloudflare Node Web3.Storage IPFS GW (primary) (redundancy) (public GW) 

What Risks Does Multi-Pinning Solve?

Local pinning is not enough. If your server goes down, no one gets the data. A multi-pinning strategy (your own node + Pinata + Web3.Storage) delivers 99.9% availability. Compare: only your node — 0% on failure, your node + Pinata — 99%, all three — 99.9%. The difference between 99% and 99.9% is about 8 hours of downtime per year vs 43 minutes. For an NFT project with daily trading, that is critical.

Pinning strategy for an NFT project:

• Own node — primary storage, fast access
• Pinata — first backup, reliable paid service
• web3.storage (Filecoin-backed) — second backup, stores data on Filecoin with verifiable deal receipts
• Nft.storage — specialized for NFT, Filecoin + IPFS

How to Set Up Remote Pinning: Step-by-Step Plan

1. Deploy a Kubo node with optimized config (server profile, automatic GC disabled).
2. Register on Pinata, get a JWT token.
3. Set up an upload script that pins on the local node and simultaneously sends a remote pin request via Pinata API.
4. Repeat for Web3.Storage.
5. Write a pinning status checker (queued → pinning → pinned → failed).

import { create } from 'kubo-rpc-client'; import * as fs from 'fs'; const ipfs = create({ url: 'http://localhost:5001' }); async function uploadFile(filePath: string): Promise<string> { const file = fs.readFileSync(filePath); const result = await ipfs.add(file, { pin: true, cidVersion: 1, }); return result.cid.toString(); } async function uploadDirectory(dirPath: string): Promise<string> { const files = []; for (const filename of fs.readdirSync(dirPath)) { files.push({ path: filename, content: fs.readFileSync(`${dirPath}/${filename}`), }); } let rootCid = ''; for await (const file of ipfs.addAll(files, { wrapWithDirectory: true, pin: true, cidVersion: 1, })) { if (file.path === '') { rootCid = file.cid.toString(); } } return rootCid; } 

Comparison of Pinning Approaches

Comparison of IPFS Gateways

GC and Monitoring: How to Not Lose Data

# Manual GC (run on schedule, don't leave on auto) ipfs repo gc # Repository stats ipfs repo stat # List all local pins ipfs pin ls --type=recursive | wc -l # Check if specific CID is locally available ipfs pin ls bafybeig... 2>/dev/null && echo "pinned" || echo "not pinned" 

Monitoring: Prometheus exporter for IPFS (ipfs stats bw, ipfs stats repo) + alert on ipfs swarm peers — if fewer than 10 peers, the node is isolated. Alert if pin count unexpectedly drops (GC removed something important).

When IPFS Is Not Needed

IPFS is overkill for temporary data (user avatars that change), data that requires deletion (GDPR), and frequently updated data. For those, use regular S3 or CDN. IPFS makes sense for: NFT metadata and media (immutability matters), smart contract artifacts (ABI, bytecode), decentralized storage with verifiability.

What Is Included in the Work

We provide not just node configuration—we deliver a ready-to-use infrastructure with documentation and support. The standard package includes:

• Deployment of a Kubo node with optimized config for server profile
• systemd unit setup with auto-restart and log rotation
• Integration with Pinata and Web3.Storage via Remote Pin API (multi-pinning scheme)
• Nginx/Cloudflare gateway with caching and CORS
• Upload and pinning scripts in TypeScript/Node.js (or Python on request)
• Prometheus + Grafana dashboard for key metrics (swarm peers, disk usage, pin count)
• Operational documentation (manual GC, monitoring, recovery)

We assess your project in 2 business days—write to us, and we'll send a technical audit with recommendations. Get a consultation: how to accelerate your IPFS infrastructure and reduce costs by 30% compared to public gateways. Our guarantee: 99.9% data availability when following the multi-pinning scheme.