Overview

Frequently asked questions about running the Bitping node (bitpingd) in Docker, typically on a Raspberry Pi at home. If you’re new to running a node, start with Installing the Node and System Requirements.

Can I run the node without Bandwidth Sharing (proxy)?

Yes. Each protocol the node serves (HTTP, DNS, ping, video streaming, traceroute and Bandwidth Sharing) can be toggled independently:

bitpingd config protocol proxy disabled

docker run --rm \
  --mount type=volume,source=bitpingd-volume,target=/root/.bitpingd \
  --entrypoint /app/bitpingd bitping/bitpingd:latest \
  config protocol proxy disabled

In Docker, the command runs against the same bitpingd-volume your node uses.

The setting is persisted in the node’s local database and a running daemon picks it up within about 30 seconds; no restart required. With Bandwidth Sharing off, the node refuses all customer proxy traffic and only performs measurement jobs (ping, HTTP, DNS, video streaming, traceroute).

The available protocol names are: http, dns, icmp (alias ping), hls, traceroute and proxy.

What can customer proxy traffic do on my node?

Destinations are open by default, apart from a fixed set of hard floors that are always blocked and cannot be overridden:

• TCP port 25 (SMTP), because relaying mail would get your home IP spam-listed.
• Private, local and reserved IPv4 ranges (listed below), so customers can never reach your home network, your router or cloud metadata endpoints.
• Non-public IPv6: anything outside global unicast (2000::/3), which covers loopback, link-local and unique local addresses.
• Local hostnames: localhost, home.arpa and anything ending in .local, .localdomain, .internal, .lan or .home.arpa.

Beyond those floors:

• Egress blocklist: on top of those floors you can block additional destinations. Your blocklist starts empty, and the node records what customers ask for so you can decide what to block:

  bitpingdDocker

  bitpingd config egress block-port 6667
  bitpingd config egress block-ip 198.51.100.7/32
  bitpingd config egress import blocklist.txt
  bitpingd config egress history 20

  history 20 lists the most-requested destinations with their denied counts. Edits apply within about 30 seconds without a restart.

• Concurrency: up to 256 simultaneous proxy sessions per node (128 per customer), with idle UDP sessions dropped after 30 seconds.

• Who can use it: every customer session is authenticated with a signed token issued by Bitping. Customers in bad standing (banned) are refused at the door, and Bitping can blacklist abusive accounts centrally; you don’t manage customer access yourself.

• What your node sees: a proxy exit knows each session’s destination address and byte counts; it does not inspect content.

Does the Docker container need special permissions or root?

No extra configuration is needed if you use the official image as documented:

• bitping/bitpingd is a multi-arch image (linux/arm64 for Raspberry Pi 4/5, linux/amd64 otherwise) and runs as root inside the container by default.
• Docker’s default capability set already includes NET_RAW, which covers the raw-socket paths (ICMP ping, traceroute). Nothing else needs it: all traffic is outbound, there are no inbound ports to expose, no TUN device, and it works behind home NAT/CGNAT.

If you prefer to run it as a non-root user:

docker run -d --name bitpingd --restart unless-stopped \
  --cap-add=NET_RAW \
  --user 1000:1000 -e HOME=/data \
  --mount type=volume,source=bitpingd-volume,target=/data \
  bitping/bitpingd:latest

The --cap-add=NET_RAW keeps ICMP ping working for a non-root user; without it, ping jobs degrade (traceroute falls back to unprivileged probing, and jobs that can’t open a socket are reported as failed rather than crashing the node). DNS, HTTP, video streaming and proxy traffic are unaffected by either choice.

Will my node be used as an exit node for Bitping’s mobile clients?

When Bandwidth Sharing is enabled, your node can be selected to exit customer proxy traffic, including Bitping’s proxy clients on mobile, so yes. The same single toggle is the opt-out: with the proxy protocol disabled (see the first question), no customer traffic of any kind is routed through your node.