Kubo v0.43.0 combines an IPFS node, gateway, and admin API
Kubo v0.43.0 is a daemon for storing, finding, and serving content addressed by a CID. It speaks to other IPFS peers over the network, exposes a command line, provides an HTTP gateway for browsers, and accepts administrative calls through an RPC API. UnixFS supplies the file and directory model, while Bitswap and HTTP handle verifiable retrieval. The project is dual licensed under Apache 2.0 and MIT.
That breadth explains the size of the code we examined. The measured checkout had 1,022 files and about 132,100 lines of source before dependencies. Kubo is suitable when one service needs to import data, keep it pinned, announce it to peers, retrieve remote blocks, or serve an IPFS gateway. A team that only needs a library should look at Boxo or Helia before adopting a separate network daemon.
The README recommends 6 GB of RAM and 2 CPU cores
Kubo's README recommends at least 6 GB of RAM and 2 CPU cores for ordinary use. It also estimates about 1 GiB of RAM per 20 million items when large pinsets are reprovided to the Amino DHT. An underprovisioned node may restart, miss its announcement window, and leave some content undiscoverable to other peers. This is service capacity that has to be planned, not a one-time installation cost.
Our sandbox had 3 CPUs and 8 GB of RAM, enough to complete the 96-second install and 97-second build. We did not keep a daemon online, publish a large pinset, or measure retrieval speed, so those results say nothing about production throughput. Kubo's low-memory guide separately tells operators to coordinate the Go memory limit, process limits, routing mode, relay service, and DHT announcement workers on constrained hardware.
What happened when we ran it
Our sandbox installed 585 packages in 96 seconds and built Kubo successfully in 97 seconds. The test step then ran for 90 seconds and exited with code 1. Go reported 80 passed and 9 failed out of 89. These results came from commit 8967407 in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets.
The end of the log placed failures in github.com/ipfs/kubo/test/cli, its autoconf package, and its migrations package. It named TestAutoConfExtensibility_NewSystem, TestMixedMigration15ToLatest, and TestMigration16ToLatest. The integration package passed in the same tail. The excerpt does not show the error messages for those failed cases, so it does not support a claim about their cause or a workaround.
The repository scan found 17 CI workflow files, a Dockerfile, and a tests directory. The checkout occupied 13.1 MB and contained about 132,100 source lines across 1,022 files. That is a well-instrumented project on paper, yet the clean-container result still matters: the exact commit we tested did not clear its full go test command, even though installation and compilation succeeded.
Ports 4001, 5001, and 8080 need different exposure rules
Kubo's swarm listens on TCP and UDP port 4001 by default, and the firewall guide says a public node should allow both. The admin RPC API defaults to localhost port 5001. The HTTP gateway defaults to localhost port 8080. Operators may expose each service differently, but opening all three with the same firewall rule would give public clients more access than the documented defaults intend.
The configuration guide says to keep the RPC API on localhost unless API.Authorizations is configured. A basic node generates its own peer identity during ipfs init, so Kubo itself does not require a hosted account or API token. Remote administration still needs authentication and careful routing. A public gateway also needs a decision about arbitrary CID fetching, because the guide recommends Gateway.NoFetch when the operator wants to prevent it.
Shipyard exits September 30 while pull requests still arrive
The v0.43.0 release, published August 3, 2026, says it is Shipyard's last Kubo release with new features. Shipyard says its IPFS work ends September 30 and that no one there will maintain Kubo afterward. The same notice allows security and bug-fix releases before that date. It does not name the team or person who will own releases after the handoff.
Current activity is real and should not be mistaken for abandonment. GitHub recorded the last push on September 9, 2026, while new pull requests were opened on September 12 and 13. The repository had 17,132 stars and 876 combined open issues and pull requests when fetched, split by GitHub search into 794 issues and 82 pull requests. That queue and the approaching maintainer exit create an ownership risk despite recent code movement.
The 9 failed tests make a cautious trial more sensible than a blind upgrade. Choose Kubo when IPFS compatibility, the Go daemon, or its gateway behavior is the requirement, then pin a version and run the relevant migration and autoconfiguration tests in your environment. Helia is the closer fit for JavaScript and browser work. Iroh suits new Rust networking projects that can give up IPFS compatibility. After September 30, every Kubo operator should know who will review security fixes and cut the next release.