i2pd preinstalled, tuned for floodfill eligibility (≥ 128 KBps shared bandwidth) with a bandwidth-ledger dashboard. Non-exit only at this tier — the network needs more honest-floodfill operators more than it needs another opt-in exit.
// pre-configured defaults
i2pd built from upstream, statically linked, run as unprivileged i2pd user
Configured for floodfill role by default (toggleable via /etc/i2pd/i2pd.conf)
Reseeder participation opt-in (default: off — opt in via the console)
Bandwidth ledger persisted to disk; rolling 30-day burndown chart
Java I2P legacy template available as an alternative OS
No exit-tunnel role — explicit by config, not by accident
I2P's threat model is closer to a Tor middle relay than a Tor exit. Running a stable, well-bandwidthed floodfill is one of the most useful single contributions you can make to the network — and the Romania / Iceland jurisdictions are friendlier to that role than most of the EU heartland.
i2p-node is the right pick when the workload is an I2P participant — running an i2pd router for personal use (eepsite hosting, Bote messaging, IRC over I2P), contributing routing capacity to the network, or operating a floodfill once the box has demonstrated stable uptime. The xmrhost i2p-1 tier ships with i2pd ≥ 2.50 from the upstream apt repo, configured as a regular router by default with floodfill opt-in via /etc/i2pd/i2pd.conf.
i2p-node is not the right pick when the workload is Tor-flavoured (use /node/tor-hidden-service or /node/vps with /docs/provision-tor-hidden-service), when the workload needs Lokinet routing (use /node/lokinet-exit), or when the customer wants a generic VPS that happens to also run an I2P client (a /node/vps with i2pd installed works fine for that). The single-tier i2p-1 is sized for a real router, not for additional unrelated services.
Iceland or Romania, customer's pick. The I2P network is dominated by EU + US routers; an additional well-connected EU router is welcome rather than redundant. The /vs/i2p-vs-tor-vs-lokinet comparison covers when each network fits which workload.
// TIER COMPARISON
$ diff /etc/xmrhost/tiers.d/*
Single tier at MVP (i2p-1, 1 vCPU / 2 GB / 50 GB SSD) — the operator ships one tier until demand justifies splitting into per-role sizes. The tier is sized for a real router with floodfill capacity and headroom for an eepsite or two; over-provisioning would be marketing rather than a real spec choice.
If the customer's workload outgrows the tier (running multiple eepsites at scale, mid-traffic floodfill on a popular subnet), the operator can route them to a /node/vps tier with i2pd installed manually — the i2p-* tier is opinionated about the role, the VPS tier is general-purpose.
// FAQ
$ faq -t i2p-node
Q.What's the difference between a router, a floodfill, and an eepsite?
A.Router — normal I2P participant proxying its own and (optionally) others' traffic. Floodfill — well-connected router that participates in the DHT for the network's address book; only well-resourced routers should be floodfills. Eepsite — a TCP service tunneled through I2P, equivalent to a Tor hidden service. The full breakdown is at /notes/i2p-floodfill-vs-router.
Q.Should I run a floodfill?
A.Only if the box has high uptime (95%+ monthly), 200+ Mbps reserved bandwidth, and sysadmin attention available. Floodfills carry the network's DHT — running an unreliable floodfill degrades the addressbook reliability. The operator's recommendation for a first deployment is a regular router, then promote to floodfill once 30 days of stable uptime are demonstrated.
Q.Where is the I2P node hosted?
A.Iceland (Reykjavik, RIPE) or Romania (Bucharest, RIPE) — customer's pick at order time. Both jurisdictions accept I2P operation under the AUP (/legal/aup); both are inside the I2P network's EU geographic distribution.
Q.Do you accept I2P abuse reports?
A.Per the AUP (/legal/aup) — same routing as for any other workload. The operator does not have access to the contents of routed I2P traffic (the I2P transport is end-to-end encrypted and the local node is participating, not de-anonymising). Complaints are handled at the AUP layer; CSAM is the explicit exclusion.
Q.Can I bridge I2P with Tor on the same box?
A.Not preconfigured — i2p-* is I2P-only. Customers wanting to bridge networks typically run two separate boxes with explicit boundary controls. The /vs/i2p-vs-tor-vs-lokinet comparison covers when each network fits which workload; the i2pd documentation (https://i2pd.readthedocs.io) covers cross-network configuration for advanced operators.