Deploying an IPFS Node: Installation, Configuration, and Operation
Imagine: you launch an NFT collection, metadata stored on a public gateway. Suddenly the gateway goes down — your collection goes 'blind'. Or you build a decentralized application that must operate without a single point of failure. In both cases, your own IPFS node is the only reliable solution. Our experience includes 30+ projects — from NFT marketplaces to decentralized storage. Below is a detailed guide to installing and configuring a production-ready node, covering common pitfalls.
When a Public Gateway Falls Short
IPFS (InterPlanetary File System) is a content-addressed decentralized file system. Addressing by content hash (CID) means that a file with the same content always has the same CID, regardless of who and where stores it. This is key for Web3: NFT metadata addressed by CID cannot be silently swapped — changing the content changes the CID.
Public gateways (ipfs.io, Cloudflare) are convenient for testing, but in production they disappoint: request limits, slow loading, risk of unavailability. A personal node guarantees data availability (pinning) and speed, and for large traffic volumes (over 1 TB/month) it is cheaper than Pinata or NFT.Storage — savings can reach 40% (approximately $150/month for typical usage). Additionally, gateway response time peaks 2–3x during high load, which is critical for user experience.
| Criterion | Public Gateway | Own Node |
|---|---|---|
| Availability | Depends on operator | Under your control |
| Speed | Limited by quotas | Maximum |
| Pinning | Session-only | Permanent |
| Confidentiality | Gateway sees CIDs | Full isolation |
| Cost at >1TB/month | High (public limits) | Low (only hardware) |
Installing and Configuring Kubo
Kubo is the reference implementation of IPFS in Go. We use the latest stable version:
wget https://dist.ipfs.tech/kubo/v0.28.0/kubo_v0.28.0_linux-amd64.tar.gz tar -xvzf kubo_v0.28.0_linux-amd64.tar.gz cd kubo && sudo bash install.sh ipfs init --profile server ipfs daemon & --profile server is important for cloud deployment: without it, the node wastes resources on mDNS discovery, useless in a datacenter. The server profile also disables local HTTP endpoints for LAN discovery.
Production Configuration of an IPFS Node
Production configuration requires strict resource limits. Without them, the node can consume all memory and disk. Set the following limits:
Expand configuration commands
ipfs config Datastore.StorageMax "100GB" ipfs config --json Swarm.ConnMgr.LowWater 200 ipfs config --json Swarm.ConnMgr.HighWater 400 ipfs config --json Swarm.ConnMgr.GracePeriod '"1m"' ipfs config --json Swarm.Transports.Network.Relay false ipfs config --json Gateway.NoFetch true ipfs config --json Gateway.HTTPHeaders.Access-Control-Allow-Origin '["*"]' Gateway.NoFetch true — the node will not download CIDs not stored locally. Without this setting, the node becomes a public gateway and can accumulate others' data, overflowing storage. The StorageMax limit protects the disk from overflow: when reaching 95% of the limit, IPFS starts aggressively unpinning blocks. We recommend leaving at least 20% free space for service data and temporary files.
For a high number of peers (>1000), increase Swarm.ConnMgr.LowWater to 500 and HighWater to 1000. To improve gateway response time, enable caching: ipfs config --json Gateway.Cache.CacheSize 1000000 — cache for 1 million blocks. With 500 peers, RAM usage is about 512 MB; consider this when choosing a server.
Systemd Service
For automatic start and restart, use systemd:
[Unit] Description=IPFS Daemon After=network.target [Service] Type=notify User=ipfs Environment=IPFS_PATH=/data/ipfs ExecStart=/usr/local/bin/ipfs daemon --migrate=true Restart=on-failure RestartSec=10s LimitNOFILE=65536 [Install] WantedBy=multi-user.target After creating the file, run sudo systemctl enable ipfs && sudo systemctl start ipfs.
Pinning: Guaranteeing Availability
Adding a file to IPFS without pinning — it will be removed at the next garbage collection. Pinning fixes the CID locally. For programmatic pinning via API, use ipfs-http-client:
import { create } from "ipfs-http-client"; const client = create({ url: "http://localhost:5001/api/v0" }); async function uploadAndPin(content: Buffer, filename: string): Promise<string> { const result = await client.add( { path: filename, content }, { pin: true, wrapWithDirectory: true } ); return result.cid.toString(); } To check pinning status, use ipfs pin ls --type recursive and ipfs repo stat.
How to Configure nginx Reverse Proxy for the Gateway?
The API (port 5001) should not be exposed externally — only the gateway (port 8080). nginx configuration with caching and SSL:
server { listen 443 ssl; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_cache_valid 200 1d; proxy_cache_bypass $http_cache_control; proxy_read_timeout 300s; proxy_buffering off; } } Caching for 1 day is safe because CIDs are immutable identifiers. If a file updates, the CID changes and the old cache automatically expires. This setup delivers 99.9% uptime and response times under 100ms.
Monitoring Node Health
Regularly check storage size (ipfs repo stat), peer count (ipfs swarm peers | wc -l), and bandwidth (ipfs stats bw). For automation, use Prometheus with ipfs-prometheus-exporter. Set alerts: storage >90% of limit, peer count <5 (network isolation), bandwidth >80% of server capacity.
| Metric | Command/Tool | Alert Threshold |
|---|---|---|
| Storage size | ipfs repo stat |
>90% StorageMax |
| Peer count | ipfs swarm peers |
<5 |
| Bandwidth | ipfs stats bw |
>80% limit |
Common Configuration Mistakes
- Using the default profile instead of server — mDNS in a datacenter creates unnecessary traffic. Always specify
--profile server. - Exposing API port 5001 to the internet — attackers can pin others' data and exhaust your disk. Close the port via firewall.
- Missing StorageMax limit — leads to disk overflow. Always set an explicit limit.
- Ignoring GC — without pinning, data is lost. Pin everything that needs persistence.
- Incorrect
Gateway.NoFetchsetting — the node downloads any CID, consuming traffic. Disable this option if you don't want to be a public gateway.
What Is Included in the Work
When ordering a turnkey IPFS node deployment, we provide:
- Installation and configuration of Kubo with optimal settings for your project
- Integration with existing infrastructure (CI/CD, monitoring)
- Setup of nginx reverse proxy and SSL certificate
- Administration and access documentation
- Team training on basic operations (pinning, monitoring)
- Support during the warranty period
Get a consultation on configuring your IPFS node. Order deployment — we will audit your requirements and propose the optimal configuration. Contact us for a consultation.