Kubo (IPFS)

Last reviewed Aug 26, 2026 · 842 words

Add a file to Kubo and you get back a CID, a hash that names the content rather than its location. Anyone on the IPFS network can fetch that file from any node that holds it, and the hash proves they got exactly what you published. That is the whole deal, and it is a genuinely good deal for publishing. The catch, which the catalogue flags and which trips up nearly everyone, is that nothing on IPFS is stored anywhere unless a node has explicitly pinned it. Your file is available exactly as long as your daemon is running or someone else cares enough to pin it.

What Kubo is and what it is not

Kubo is the reference IPFS implementation, written in Go, MIT-licensed, around 17,100 stars, first shipped in 2015 under the name go-ipfs. The catalogue lists it as a Dropbox alternative and it is the wrong shape for that: there are no accounts, no folders that sync between two laptops, no sharing links with expiry, and by default everything you add is readable by anyone who learns the CID. It is closer to a peer-to-peer CDN with an honest name for every object. If you want two-way sync between your machines, Syncthing is the tool, and if you want a Dropbox-shaped web interface, Nextcloud is; the file sync category covers both.

Three ports and a profile choice

The daemon listens on 3 ports: 4001 (TCP and UDP) for the swarm, 5001 for the RPC API, and 8080 for the HTTP gateway that serves /ipfs/<cid> paths to normal browsers. The API has no authentication and can add, pin and delete anything, so it stays on localhost. Initialise with the server profile if the node lives on a VPS or anywhere with a public IP, because the default profile probes local network ranges and cloud providers dislike that:

ipfs init --profile server
ipfs daemon

In Docker the image is ipfs/kubo with the repo at /data/ipfs; publish 4001 to the world, bind 5001 and 8080 to 127.0.0.1 and reverse-proxy the gateway if you want it public. Kubo needs 512 MB to be comfortable and will use more under load; on a Raspberry Pi the lowpower profile cuts the peer count and makes it liveable.

Pin it or lose it

Adding is pinning on the local node, so ipfs add -r ./site keeps the content until you unpin it or run ipfs repo gc. Content you merely fetched is cached, not pinned, and garbage collection reclaims it. Repo size is capped by Datastore.StorageMax, which defaults to 10 GB, and GC kicks in as you approach it. So a "backup to IPFS" that consists of adding files on one node is a backup with one copy on one disk, which is not a backup. Durability comes from a second node you control pinning the same CIDs (ipfs pin add <cid> on the other machine), or from a paid pinning service. Either is fine; assuming the network will hold your data out of goodwill is not.

Mutable names come from IPNS and DNSLink

A CID changes every time the content does, which is correct and annoying for a website. IPNS gives you a stable name backed by your node's key: ipfs name publish <cid> points the name at the latest CID, and viewers fetch /ipns/<key>. It is slow to resolve and records expire unless republished, which the daemon does while running. DNSLink is the practical version: a TXT record at _dnslink.example.com containing dnslink=/ipfs/<cid> lets example.com resolve through any gateway, and updating it is a DNS change rather than a protocol dance.

The daemon is chatty by design

Bandwidth is the con people underestimate. A publicly reachable Kubo node acts as a DHT server, answers routing queries for strangers, and keeps dozens of peer connections open, which on a metered or asymmetric home link adds up to a constant few hundred kilobits each way. The server and lowpower profiles help, Routing.Type set to dhtclient stops you serving the DHT, and the connection manager's high-water mark in the config caps peers. If you are on a residential line with a data cap, set those before you notice the bill, not after.

What I'd do

Use Kubo for what it is good at: publishing a static site or a large dataset that you want to be fetchable by hash and mirrored by others. Run it on a small VPS with the server profile, pin the content on a second node at home so it survives the VPS, publish through DNSLink, and put the gateway behind a reverse proxy only if you actually want to serve the public. For syncing your own files between your own devices, ignore the Dropbox alternative framing entirely and run Syncthing; the two tools solve different problems and only one of them is the one you probably have.