i2pd: a C++ I2P client for people who want the router without the Java stack

What i2pd solves and who it is actually for

I2P is described in the README as a universal anonymous network layer, with communications that are anonymous and end-to-end encrypted, and with participants not revealing their real IP addresses. i2pd is one implementation of a client for that network, written in C++ and labelled a full-featured implementation. The problem it addresses is not "browse anonymously" in the sense a browser extension implies. The README names two workloads: anonymous peer-to-peer applications such as filesharing and cryptocurrencies, and anonymous client-server applications such as websites, instant messengers and chat servers. A developer or operator who wants to run an I2P service, or to build an application on top of I2P, needs a router process on the machine. That is what i2pd is.

The audience is therefore narrower than the description suggests. If you want to reach I2P sites occasionally, a client with a graphical interface is a better fit, and the README explicitly points elsewhere for that: i2pd-qt for a Qt GUI, i2pd-android for Android, and gui-i2pd for macOS. i2pd itself is the daemon. The README also advertises a rich set of APIs for developers of secure applications, which is the real signal about intent. This is infrastructure for people writing or hosting something, not a consumer privacy product.

How the daemon is put together, and what the Makefile tells you

The repository layout is unusually informative. Top-level directories separate concerns that many projects keep in one tree: libi2pd, libi2pd_client and libi2pd_wrapper are three distinct libraries, while daemon holds the executable itself and i18n holds translations. The Makefile names the artifacts explicitly, producing libi2pd, libi2pdclient and libi2pdwrapper in both shared and static form, plus libi2pdlang, and finally the i2pd binary. That split matters if you intend to embed the router rather than run it as a process. The wrapper library exists precisely so that an application can talk to the I2P stack without reimplementing it.

The build system is a hand-written Makefile with per-platform includes: Makefile.linux, Makefile.osx, Makefile.homebrew, Makefile.mingw, Makefile.bsd, Makefile.solaris and Makefile.haiku. Platform detection runs through the compiler's target triple, and the shared library suffix is chosen from that, so darwin yields dylib, mingw, windows-gnu and cygwin yield dll, and everything else yields so. Several toggles are visible with defaults: USE_STATIC and USE_UPNP default to no, DEBUG defaults to yes, TORRENTS defaults to yes, and USE_GIT_VERSION defaults to no. DEBUG defaulting to yes is worth noticing. A plain make with no arguments compiles with -g rather than -Os, which is a development posture, not a release one. Anyone building for production should set DEBUG=no deliberately rather than assume the default is tuned for deployment.

Installing i2pd and running it for the first time

The README states that the easiest way to install i2pd is by using precompiled packages and binaries, most of which are on the release page, and it defers to the documentation under user-guide/install for detail. A Docker image is published as purplei2p/i2pd, and there is a Snap. For a source build, the README links separate build instructions per platform under devs/building, so the commands below are only the generic entry point.

Clone the openssl branch, which is the default branch, and build:

git clone https://github.com/PurpleI2P/i2pd.git
cd i2pd
git checkout openssl
make DEBUG=no

Setting DEBUG=no switches the compiler flags from -g to -Os, which is what you want for a long-running router rather than a debugging session. The build produces the i2pd binary plus the three libraries described above.

For the Docker route, the README points at the purplei2p/i2pd image on Docker Hub. The exact run invocation is not given in the README, so check the documentation before wiring ports.

Configuration is where a first run actually happens. The README links an example config file at contrib/i2pd.conf on the openssl branch, and the run documentation under user-guide/run. Read that file rather than copying an option list from a blog post, because the repository is the only source that is guaranteed to match the binary you just built. The README does not document a rollback procedure, and it does not list a set of default ports in the text reproduced here, so treat any port numbers you see elsewhere as unverified.

The Java router is the real alternative, and the difference is not cosmetic

The obvious comparison is the reference I2P router implemented in Java, which the i2pd README implicitly positions against by calling itself a full-featured C++ implementation. The difference in approach is concrete. A C++ daemon with a hand-written Makefile and three linkable libraries is meant to be embedded, packaged by distributions and run headless. A Java router depends on a JVM, which changes the deployment story on small machines, on routers and in containers, and it changes how you integrate with the router from another process. i2pd's wrapper library is the clearest expression of that difference: the project ships an interface intended for other software to link against.

That is not automatically better. Java tooling is more uniform across platforms, and a JVM gives you a single artifact that behaves the same everywhere. i2pd instead carries per-platform Makefiles for Linux, macOS (with a separate Homebrew variant), MinGW, BSD, Solaris and Haiku, which is more code paths to keep working. The README lists supported systems including Debian and Ubuntu, CentOS, Fedora and Mageia, Alpine, ArchLinux, openSUSE and Gentoo, Windows, macOS, Docker, Snap, FreeBSD, Android and iOS, with CI badges attached to several of them. Breadth of platform support is a maintenance burden as much as a feature, and the repository layout reflects that cost.

Where i2pd is the wrong tool, and the limits the README admits

The README is candid in one place that matters: the note at the top directs Android users to i2pd-android, Qt users to i2pd-qt, and macOS GUI users to gui-i2pd, a repository under a different owner. If your requirement is a desktop application with windows and buttons, i2pd is not it, and the project does not pretend otherwise. Building a GUI on top of the daemon is your work.

A second limit is the contribution policy. The README states plainly: no LLM or AI generated code for pull requests, and no LLM or AI generated texts for issues. Whatever your view of that rule, it is a hard constraint on how you interact with the project, and it is unusual enough that a contributor should read it before opening anything. Combined with the absence of a documented support channel beyond issues, the wiki and a Twitter hashtag, this is a project where you are expected to read the specifications at geti2p.net/spec when behaviour is unclear.

A third limit is operational. The documentation is hosted separately on Read the Docs, and the README repeatedly defers to it rather than restating configuration. That is good hygiene, but it means the README alone is not enough to run a router. If you need a self-contained quickstart in one file, this is not that project.

Maintenance cadence, licence and the cost of upgrading

The last push to the repository was on 2026-07-20, the same day release 2.61.0 was tagged. The two previous releases, 2.60.0 and 2.59.0, landed on 2026-04-25 and 2026-02-08, which is a rough rhythm of one release every two to three months. Nothing in the repository metadata indicates the project is archived. That cadence is the number that matters for planning: if you pin a version, expect to revisit it a few times a year, not once.

Upgrade cost is mostly configuration drift. The README points at contrib/i2pd.conf as the example config and at the user-guide documentation for running, which means the authoritative option list lives in the tree and changes with it. There is no documented migration tool and no documented rollback, so the practical upgrade procedure is to diff your config against contrib/i2pd.conf from the new tag before restarting. The build toggles add a second axis: USE_STATIC, USE_UPNP, DEBUG, TORRENTS and USE_GIT_VERSION all have defaults that a packager may override, so a distribution build and your own build can differ in behaviour without differing in version number.

The licence is BSD 3-clause, with the text in the LICENSE file at the root of the source tree. That is a permissive licence, which generally means you can link the libraries into proprietary software, but the obligations around retaining the copyright notice and the disclaimer are for your legal team to read, not for this article to summarise. Note that the licence covers the code; it says nothing about the legal status of what you run over I2P in your jurisdiction.

Editorial conclusion

Adopt i2pd if you want an I2P router with a small dependency set, a C++ codebase you can read, and packaging that already exists for Debian, Ubuntu, Fedora, Alpine, Arch, openSUSE, Gentoo, Windows, macOS, FreeBSD, Android and iOS. Do not adopt it if you need a bundled GUI, since the README points to separate i2pd-qt and i2pd-android repositories, or if you want an official support channel, because the README only lists issues, a wiki and a Twitter hashtag. Before deploying, verify the current configuration keys against contrib/i2pd.conf on the openssl branch rather than against an older tutorial, and confirm the release page still carries a binary for your platform.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes