Deploy IPFS Node on a US Server to Host Static Website

You can host a decentralised static website quickly with a public US server. First, you provision a US server and install Kubo. Next, you upload your site files to obtain a content identifier (CID). You then pin your content locally and remotely. Finally, you map your custom domain using DNSLink.

Why choose a US server? A US-based server provides a public IP address. You bypass restrictive local NAT setups and enjoy high bandwidth for faster North American peer discovery.

Let us Deploy IPFS Node software now and launch your site.

Key Takeaways

• A US server provides a public IP address for fast peer connections.

• Convert your content hash to CIDv1 to ensure modern web browser compatibility.

• Pin your website files locally and remotely to prevent accidental file deletion.

• Link a custom domain name to your content hash using simple DNSLink records.

Prepare US Server Infrastructure

Server Specs and OS Setup

When you prepare to deploy IPFS node infrastructure, choose a modern 64-bit Linux distribution such as Ubuntu 22.04 LTS. Your server needs adequate resources to handle peer routing and maintain fast content delivery.

You can review the recommended hardware baseline below:

💡 Tip: Monitor your storage growth regularly. Your space requirements will grow as you pin more static website assets and cache network data.

Firewall and Port Configuration

Host your server on a public US infrastructure to solve common peer-to-peer networking issues. Home internet connections use Network Address Translation (NAT). NAT restricts incoming traffic and hides your device behind router rules. A US server gives you a public IPv4 address. This direct connection bypasses restrictive local NAT environments, allowing peer nodes across North America to find your content instantly.

You must configure your firewall to open specific communication ports. Execute these standard ufw terminal commands to adjust your network security:

# Allow IPFS Swarm traffic for peer discovery
sudo ufw allow 4001/tcp
sudo ufw allow 4001/udp

# Allow Web Gateway access for public HTTP requests
sudo ufw allow 8080/tcp

# Enable firewall rules
sudo ufw enable

Keep port 5001 closed to the public internet. Port 5001 controls the API. You must restrict API access to your local machine to prevent unauthorized control over your server node.

Deploy IPFS Node and Configure Daemon

Install Kubo on Linux

Kubo provides the official command-line implementation for IPFS. You can download and install Kubo directly on your Linux server using simple terminal commands:

# Download the latest Kubo archive
wget https://dist.ipfs.tech/kubo/v0.26.0/kubo_v0.26.0_linux-amd64.tar.gz

# Extract the archive file
tar -xvzf kubo_v0.26.0_linux-amd64.tar.gz

# Run the installation script
cd kubo
sudo bash install.sh

Verify your installation by running ipfs --version in your terminal screen.

Initialize Node and Swarm Ports

You must initialize your node repository before launching network connections. Run the standard initialization command:

ipfs init --profile server

The server profile configures your node for data center environments. It disables local network scanning to keep your server secure.

⚡ Note: A newly started IPFS daemon requires initial warm-up time. Your node actively discovers network peers and builds routing tables during the first few minutes to optimize transfer speeds.

You now Deploy IPFS Node resources with optimized peer routing settings.

Configure Systemd and Gateway

To host static web pages successfully, you must allow cross-origin requests. Configure the Cross-Origin Resource Sharing (CORS) headers on your gateway:

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'
ipfs config --json Gateway.HTTPHeaders.Access-Control-Allow-Origin '["*"]'

Next, set up systemd to keep your node running continuously in the background:

1. Create the service unit file: Open /etc/systemd/system/ipfs.service using your favorite text editor:

   sudo nano /etc/systemd/system/ipfs.service
   

2. Configure unit parameters: Add the service configuration and replace your-user-name with your actual Linux user account:

   [Unit]
   Description=IPFS Daemon
   After=syslog.target network.target remote-fs.target nss-lookup.target
   
   [Service]
   Type=simple
   ExecStart=/usr/local/bin/ipfs daemon --enable-namesys-pubsub
   User=your-user-name
   Restart=always
   
   [Install]
   WantedBy=multi-user.target
   

3. Enable and launch on startup: Reload systemd files, enable automatic boot startup, and start the daemon immediately:

   sudo systemctl daemon-reload
   sudo systemctl enable ipfs
   sudo systemctl start ipfs
   

You successfully Deploy IPFS Node services as a resilient background process.

Deploy and Pin Static Web Content

Add Website Files to IPFS

You must upload your static website directory to the IPFS network using simple command-line tools:

• CLI Command: ipfs add -r <directory_name> (e.g., ipfs add -r testdir)

• Function: Uploads all files inside your specified directory recursively.

• Generated Root CID Output: Generates unique content identifiers for single files and outputs a final directory root hash (e.g., QmPCwGkDRjW8B2SHoS3P9Cc4hKDjtdgytrfHQhg8n1BdGE testdir).

💡 Tip: Always convert your root hash to CIDv1 format for website hosting.

CIDv0 hashes break inside modern browsers because web address bars automatically force hostnames into lowercase text. CIDv1 uses case-insensitive Base32 encoding to grant each site its own security origin. This isolation protects your local browser storage and handles relative file paths seamlessly.

Local and Remote Pinning Setup

IPFS nodes automatically perform garbage collection to free up disk space. During this automated cleanup process, your node deletes unpinned CIDs from local cache memory. Pinned CIDs stay safe on your drive forever.

Automatic garbage collection relies on key server settings:

• Data Removal: Deletes unpinned cached files to preserve storage.

• GCPeriod: Controls how often the cleanup runs (defaults to every 1 hour).

• StorageGCWatermark: Triggers cleanup when disk usage hits a specific limit (defaults to 90% capacity).

Local pinning keeps your content online, but server outages can still take your site offline. You can connect third-party remote pinning services like Pinata to maintain multi-node redundancy.

Configure your remote pinning provider using these sequential steps:

1. Add the Remote Pinning Service to Kubo: Run ipfs pin remote service add <nickname> <endpoint> <accessToken> by entering your chosen nickname, provider API endpoint URL, and secret access token.

2. Pin Content Remotely: Push your root CID to the remote service using ipfs pin remote add --service=<nickname> --name=<optional-name> <CID>.

3. Monitor Pin Status: Check your status using ipfs pin remote ls --service=<nickname> to view completed or queued requests.

Automate Deployments via CI/CD

Manual deployments waste time whenever you update website code. You can build automated CI/CD pipelines through GitHub Actions or deployment tools like ipfs-deploy.

Configure your automated pipeline to build your site assets, upload fresh directories to your US server, update remote pinning services, and output the newest CIDv1 string automatically on every code commit.

Map Custom Domain via DNSLink

Configure DNS Records for IPFS

DNSLink maps your complex IPFS Content Identifier to a readable domain name. You can update your website content without changing your primary website link. You simply update a TXT record in your domain registrar control panel.

To configure DNSLink, create a TXT record for the subdomain _dnslink.yourdomain.com and assign it the string value dnslink=/ipfs/<CID>.

You must also direct your main domain to a public IPFS gateway. Point a CNAME record to gateway.ipfs.io or point an A record to your US server IP address.

After updating your DNS settings, verify the propagation of your TXT record using terminal tools:

• Query Command: dig +short TXT _dnslink.yourdomain.com

• Expected Result: Output containing the IPFS path, such as "dnslink=/ipfs/bafybeiay2koog2jnndn5gr2raytxh7evobry5lo2w4s7nhugc7xipy6aze"

Integrate Gateway and Test Resolution

Your US server needs a reverse proxy to handle secure web traffic. NGINX routes incoming web requests directly to your local IPFS gateway port. Secure Sockets Layer (SSL) encryption protects your visitors and builds trust. You can generate free SSL certificates using Let’s Encrypt and Certbot.

Follow these ordered steps to enable HTTPS on your custom domain gateway:

1. Deploy Certbot alongside the specialized NGINX plugin on the host system (e.g., Ubuntu).

2. Execute sudo certbot --nginx -d ipfs.my-domain-name.com to trigger certificate generation.

3. Complete the interactive CLI prompts to automatically update NGINX configurations and enforce HTTPS redirection.

Now, test your deployment in any web browser. Enter your custom domain name into the browser address bar. Your local US IPFS node fetches the content from the network instantly. Your decentralized static website is live and securely accessible to the public!

You successfully combined local server management with public DNS records to host a decentralized website.

Maintain your setup with these simple daily checks:

• Track your peer counts after node warm-up to ensure stable connectivity.

• Manage disk usage limits to prevent unexpected garbage collection.

• Verify remote pinning status across external providers for redundancy.

• Keep in mind that public gateways cache updated DNSLink records using your DNS TTL as the max-age header value alongside a Last-Modified timestamp.

When you Deploy IPFS Node site updates, test your custom domain resolution through public gateways to verify global performance!

FAQ

How do you check if your IPFS node functions properly?

Run ipfs stats bw in your terminal screen to view bandwidth usage. You can also check active network peer connections with a simple command:

ipfs swarm peers

⚡ Note: High peer counts confirm strong connectivity across the global IPFS network.

Why should you use CIDv1 instead of CIDv0 for static websites?

Modern web browsers force domain names to lowercase text. CIDv1 uses case-insensitive Base32 encoding. It prevents broken web links, preserves relative file paths, and provides isolated browser security origins for your hosted applications.

What happens when your server runs out of storage space?

Your node triggers automatic garbage collection when storage reaches capacity limits. It safely deletes unpinned cached files from your drive.

| Content Status | Garbage Collection Action | | : | : | | Unpinned Files | Removed automatically | | Pinned Files | Retained permanently |

Can you host dynamic websites on an IPFS node?

No, IPFS natively serves static assets like HTML, CSS, client-side JavaScript, and images. You can still add dynamic features by integrating external public APIs or Web3 smart contracts into your frontend code.