IPFS Web UI for Kubo and IPFS Desktop

What IPFS Web UI Manages Through Kubo

IPFS Web UI solves the problem of controlling a Kubo node through a graphical interface. Its intended users are people running Kubo directly, users of IPFS Desktop, and developers who need to inspect or configure a local IPFS node without translating every operation into command-line instructions. It does not implement an IPFS node by itself. The README describes it as a frontend that communicates with a Kubo node through the Kubo RPC API.

The interface divides the main tasks into five areas. Status presents connection state, peer count, bandwidth, and repository statistics. Files provides browsing, upload, download, and file management. Explore opens the IPLD DAG and allows users to navigate CIDs and inspect linked data. Peers shows connected peers geographically and supports connection management. Settings covers Kubo configuration, pinning services, and interface preferences.

This division makes IPFS Web UI more than a file browser. It places operational status, content-addressed data, network participants, and node configuration in one browser-based application. However, its capabilities remain bounded by what the connected Kubo API exposes. The README does not document storage classes, remote clusters, multi-user accounts, or a hosted service tier, so those should not be inferred from the existence of these pages.

The kubo-rpc-client Data Path

The central technical dependency is `kubo-rpc-client`. Based on the README, the browser application uses that client to communicate with the local Kubo RPC API. User actions in the React frontend therefore lead to client requests against Kubo, and Kubo returns the node data or operation result that the interface renders.

The repository metadata identifies JavaScript as the primary language and lists React, Redux, and redux-bundler among its topics. The file layout also includes `src/`, `public/`, tests, Babel configuration, TypeScript configuration, and Storybook configuration. This supports the description of a conventional JavaScript web application rather than a static status page. The frontend contains the interface and state organization, while node operations remain the responsibility of Kubo.

That separation has practical consequences. A successful page load does not prove that the Kubo daemon is healthy. Likewise, an unavailable RPC API can make status, file, peer, and settings views fail even if the frontend itself is reachable. The documentation does not specify retry behavior, API version negotiation, partial failure handling, or offline operation. Those are relevant questions for engineers assessing the project, but they cannot be answered from the README and should be checked against the connected Kubo version and the frontend release.

Opening Web UI with Kubo or Docker

For a normal Kubo installation, the README directs users to start the daemon and open the bundled Web UI at `http://127.0.0.1:5001/webui`. This is the shortest path to a real use because it uses the Web UI shipped with Kubo instead of setting up a separate application server.

The documentation also gives a Docker command for launching Kubo. This command publishes ports 8080 and 5001, starts the container interactively, and uses the `ipfs/kubo` image. The README points to the Kubo Docker Hub page for additional options, so the command is a starting point rather than a complete container deployment guide.

docker pull ipfs/kubo
docker run -p 8080:8080 -p 5001:5001 -it ipfs/kubo

After the daemon is running, browse to the local Web UI path. The interface should connect through Kubo's RPC service and expose the Status, Files, Explore, Peers, and Settings areas. The README does not say that `http://webui.ipfs.io` should replace the local endpoint for a private node. The latest release and the `main` preview are documented as hosted Web UI destinations, but the repository does not state that those hosted pages can operate an arbitrary local Kubo node.

Developing the JavaScript Frontend Locally

For contributors, the README requires Kubo and a separate development process. The documented quick start installs dependencies, configures CORS, starts the Kubo daemon in another terminal, and then starts the frontend development server. The server is documented at `http://localhost:3000`.

npm install
./cors-config.sh
ipfs daemon
npm start

Run `ipfs daemon` separately, then run `npm start` after it is available. The repository's `package.json` defines `start` as an OS-dependent script. On macOS and Linux, it sets `REACT_APP_ENV=development`, records the current Git revision in `REACT_APP_GIT_REV`, and launches `react-app-rewired-esm start`. The Windows script uses PowerShell and sets the same Git revision variable.

The README pins the Node.js version in `.tool-versions`. Contributors using asdf can install the selected version before running the npm workflow. This matters because the application has separate scripts for linting, building, unit tests, end-to-end tests, and Storybook.

npm run lint
npm test
npm run build
npm run storybook

`npm run lint` runs ESLint, type checking, and dependency checking. `npm test` runs unit, build, and end-to-end stages according to `package.json`. `npm run build` creates a production build, while `npm run storybook` starts the component viewer on port 9009. The README does not claim that all commands are required for ordinary use; they are mainly relevant to development and verification.

Translations, Releases, and Upgrade Surface

The interface supports multiple languages through Transifex. Users can change language from the Settings page or append `?lng=<lang-code>` to the URL. Translation files are stored under `./public/locales`, and contribution details are kept in `docs/LOCALIZATION.md`.

The release workflow has two distinct hosted targets. Every merge to `main` is deployed to `dev.webui.ipfs.io`, while tagged releases are deployed to `webui.ipfs.io`. The repository records releases including v4.13.0, v4.12.0, and v4.11.1, and the current `package.json` version is 4.13.0. The last push was on 2026-10-11. The repository is not archived, but the README explicitly states that there is no dedicated maintainer at the moment and that Shipyard's maintenance work ended on 2026-09-30. That makes ownership and release continuity a concrete adoption concern rather than an abstract quality question.

The MIT license permits use and modification under its terms, subject to the license text and applicable obligations. It is a frontend repository, so adopting it does not by itself settle the licensing of Kubo, IPFS Desktop, node configuration, hosted Web UI deployments, or the content stored through IPFS. The README does not provide legal guidance, and it does not document a compatibility matrix between each Web UI release and each Kubo release.

Where IPFS Web UI Falls Short

The first limitation is architectural. IPFS Web UI depends on a running Kubo node and its RPC API. It is therefore the wrong tool for someone who wants a complete IPFS implementation with no daemon, no RPC service, and no local node management. The hosted `webui.ipfs.io` destination may be useful for inspection or development, but the README does not document it as a replacement for a locally controlled node.

The second limitation is operational. Kubo version changes can affect API behavior, CORS requirements, configuration fields, and pinning-service interactions. The frontend has a versioned build and test scripts, but the README does not publish a supported compatibility table or a rollback procedure for a broken Web UI release. An engineer should not assume that matching the latest frontend release automatically makes every earlier Kubo configuration compatible.

A real alternative is using Kubo's CLI directly. That removes the browser UI and its RPC-facing frontend layer from the workflow, which can be preferable on servers, automated deployments, restricted browsers, or environments where every operation should be scripted. IPFS Desktop is another practical interface for desktop users, but the documentation here describes Web UI as bundled with it rather than documenting a difference in every management feature. The choice is between a browser frontend for Kubo and alternative interfaces around the same node, not between two independent IPFS implementations.

Editorial conclusion

Adopt IPFS Web UI when you operate Kubo or IPFS Desktop and want day-to-day node management without using the CLI. Do not treat it as a standalone IPFS node, a general-purpose hosted file service, or a deployment independent of Kubo. Before adoption, verify that your Kubo daemon and RPC endpoint are available, that the bundled Web UI matches your node, and that your operating plan accounts for the absence of a dedicated maintainer.

Frequently asked questions

Official sources

1. ipfs/ipfs-webui on GitHub
2. License: MIT
3. Project website
4. README
5. Releases