I2P VPS Hosting: Run an Anonymous Network Node Offshore

I2P and Tor are both anonymity networks but with fundamentally different design philosophies. Tor is optimized for anonymous access to the clearnet (regular internet sites) through exit nodes. I2P is designed primarily for anonymous communication within the I2P network itself - internal services called eepsites (equivalent to Tor's onion services) with no reliance on exit nodes to the clearnet. Tor is better for accessing regular websites anonymously; I2P is better for hosting or accessing services within the anonymous network itself.

Architecturally, I2P uses a fully distributed, peer-to-peer routing model where every participating node acts as a router, forwarding encrypted traffic for other nodes. There are no centralized directory authorities as in Tor; routing information is distributed via a distributed hash table (NetDB). This makes I2P more resistant to attacks on the directory infrastructure but somewhat slower than Tor for initial connection establishment as the router builds its integration into the network.

I2P's internal services have a rich ecosystem: I2P-Bote (anonymous email), I2PSnark (BitTorrent over I2P), Syndie (distributed forums), and numerous eepsites. These services benefit from I2P's garlic routing (similar to Tor's onion routing but bundles multiple messages together) and its lack of exit nodes that could be a point of surveillance.

Running an I2P router on a VPS rather than a home connection offers significant advantages: VPS connections have consistent uptime (no dynamic IP changes, no router reboots), high bandwidth (I2P routing benefits from fast nodes), and stable latency. A fast, always-on I2P router on a VPS becomes a high-throughput node that the network recognizes and routes significant traffic through, contributing meaningfully to network capacity.

I2P is distributed in multiple implementations. Java I2P is the original and most feature-complete; i2pd (i2p daemon) is a C++ reimplementation that is significantly lighter on resources, making it better suited for VPS deployment where memory efficiency matters. Install i2pd on Debian/Ubuntu: add the official i2pd repository and install i2pd. The package installs a systemd service and a default configuration at /etc/i2pd/i2pd.conf.

Key configuration settings for a VPS-hosted router: set bandwidth to a value appropriate for your plan (bandwidth = 1024 gives the router 1024 KB/s in each direction; increase for faster plans). Set port to a UDP/TCP port that you open in your firewall (7656 is the default; opening this port allows other I2P nodes to make direct connections to yours, improving your integration into the network). Enable floodfill mode if you want your node to act as a NetDB floodfill node (floodfill = true), which contributes more to the network but uses more bandwidth and CPU.

The I2P router console (web interface for monitoring and configuration) listens by default on 127.0.0.1:7070. Access it via an SSH tunnel: ssh -L 7070:127.0.0.1:7070 root@your-vps-ip and then open http://127.0.0.1:7070 in your browser. The console shows network integration status, tunnels, bandwidth usage, and configuration options. After starting i2pd for the first time, allow 15-30 minutes for the router to integrate into the network and establish tunnels.

For a pure network contribution node (not running any I2P services yourself), no additional configuration beyond the basics is needed. Monitor the router console's integration status indicator: the node should show "Good" or "High" integration after an hour of operation. If integration stays at "Low" or "Testing", check that the configured port is reachable from the internet (test with an external port checker tool) and that the firewall rules allow inbound UDP and TCP on that port.

An eepsite is an I2P-internal web service accessible only within the I2P network. Hosting an eepsite on your VPS makes it reachable by all I2P users without any clearnet exposure. To host an eepsite, configure i2pd to expose a local web server through an I2P server tunnel. In /etc/i2pd/tunnels.conf, add a [mysiteserver] section with type = http, host = 127.0.0.1, port pointing to your local web server (e.g., nginx on port 80), and keys = mysite.dat for the destination key file.

Start your web server (nginx, caddy, or any HTTP server) listening on localhost. After i2pd starts and creates the tunnel, find your .i2p address by checking the i2pd console's tunnels section or reading the destination from the keys file with i2pd's --print-address option. Share this .b32.i2p address with I2P users who want to access your eepsite. The address is a base32 encoding of a hash of your destination public key, so it is stable as long as you keep the same keys file.

Eepsite content is served over I2P's encrypted, anonymizing network: visitors cannot determine your server's real IP address, and your server cannot determine visitors' real IP addresses. This makes eepsites appropriate for publishing content where both operator and reader anonymity are desired, such as whistleblowing platforms, anonymous forums, or services for users in censored environments who can access I2P through bridges.

Common eepsite applications include Nginx serving static files, Gitea for anonymous code repositories, Matrix/Synapse for private messaging, and simple PHP or Python applications. Any HTTP application that runs on a Linux server can be exposed as an eepsite. The performance is similar to Tor hidden services: latency is higher than clearnet due to the multi-hop anonymization, but throughput is sufficient for web applications and file sharing.