I wanted to run two separate Money4Band projects on one Raspberry Pi 5, with each project using a different internet connection. The goal was not simply to connect the Pi to two Wi-Fi networks. I wanted traffic originating from the first Docker stack to leave through one wireless adapter, while traffic from the second stack left through the other adapter.<\/p>\n\n\n\n
That distinction matters. A Linux computer can have two Wi-Fi interfaces connected at the same time, but that does not automatically mean Docker containers will use the interface I intend. The host’s normal routing table still makes routing decisions, and without additional configuration, traffic from both Docker projects can leave through the same default route.<\/p>\n\n\n\n
My solution evolved into a combination of two Docker Compose projects, two dedicated Docker bridge subnets, NetworkManager profiles bound to individual Wi-Fi adapters, and Linux source-based policy routing. I also wrote Bash functions to restore the configuration and start or stop both projects with short commands.<\/p>\n\n\n\n
This article documents the setup and troubleshooting process from my Raspberry Pi conversations and saved configuration files. It is based on the configuration I worked with, not a universal installation script. Interface names, IP addresses, image support, and resource limits will differ on other systems. It assumes Docker Engine and the Compose plugin are already installed; the saved conversation records do not preserve one complete, verified Docker installation sequence, so I have not invented one here.<\/p>\n\n\n\n
The project uses a Raspberry Pi 5 with 4 GB of RAM. The operating system reported itself as Debian GNU\/Linux 13 (Trixie), running on the 64-bit ARM architecture.<\/p>\n\n\n\n
The system information recorded during setup included:<\/p>\n\n\n\n The Pi has two wireless interfaces available. I chose to use the two adapters for different networks rather than allowing both Docker projects to share one Wi-Fi connection. In my setup, the built-in adapter was assigned to the primary connection and the USB adapter to the secondary connection.<\/p>\n\n\n\n Before building the Docker routing rules, I checked that Linux could see both interfaces and that NetworkManager considered both connected:<\/p>\n\n\n\n The interfaces had separate IPv4 addresses. In one diagnostic snapshot, The first step was to make sure both interfaces were up and scan for networks using each adapter individually.<\/p>\n\n\n\n Using I then created or reused saved NetworkManager connection profiles. The important setting was binding each connection profile to its intended interface. The relevant NetworkManager properties included:<\/p>\n\n\n\n For a new machine, I recommend entering passwords interactively rather than putting them directly into a script. For example:<\/p>\n\n\n\n After creating the profiles, I checked them with:<\/p>\n\n\n\n The helper I wrote finds an existing Wi-Fi profile by SSID, prefers a profile already bound to the desired interface, and then connects that saved profile to the correct adapter. It also disables autoconnect on other saved Wi-Fi profiles without deleting them. That prevents NetworkManager from automatically choosing an unrelated saved network and moving one of the adapters away from its assigned connection.<\/p>\n\n\n\n The important point is that Instead of putting every service into one large Compose project, I created two project directories under my home directory:<\/p>\n\n\n\n The first directory is the original Money4Band project. The second directory is a separate copy\/configuration for the second connection. Each directory has its own The environment files use different values for the settings that must not collide:<\/p>\n\n\n\n The project name keeps Compose resources separate. The device name helps give containers distinct names, and the Watchtower scope keeps each updater focused on the containers belonging to its own project.<\/p>\n\n\n\n The saved environment snapshots showed Each The final configuration uses Docker’s The first project’s environment includes:<\/p>\n\n\n\n The second project’s corresponding values include:<\/p>\n\n\n\n The Compose file defines the default network using those environment variables:<\/p>\n\n\n\n This results in two distinct Docker bridge networks:<\/p>\n\n\n\n The host gets a bridge-side address for each network. In the recorded configuration, the gateways were This separation is the key that allows the Linux host to recognize which project originated a packet. The next step is to use those source ranges in policy-routing rules.<\/p>\n\n\n\n A Docker bridge network isolates containers into a virtual network on the Pi. It does not, by itself, mean that the network is physically attached to Initially, I investigated using Docker This distinction is important:<\/p>\n\n\n\n The Docker subnet is therefore the routing identity for each stack. The policy rules do not try to attach a Compose project directly to a Wi-Fi device. Instead, they match the source IP range assigned to the project’s bridge network.<\/p>\n\n\n\n The Raspberry Pi has two active Wi-Fi connections, which means the host’s main routing table can contain two default routes. In my diagnostic output, the primary route through A normal host-originated connection will generally follow the main routing table’s route selection. That is not enough for this project because I wanted container traffic from one subnet to use Linux policy routing solves this by allowing rules to select a different routing table according to the packet’s source address.<\/p>\n\n\n\n I used these assignments:<\/p>\n\n\n\n The first table contains a connected route for the Wi-Fi network on The routing table entries are built from live NetworkManager values rather than assuming the gateway will always be the same. The helper reads the current IPv4 address and gateway from the interface and finds its connected route in the main table.<\/p>\n\n\n\n The essential commands for the first route table look like this:<\/p>\n\n\n\n The equivalent entries for the second interface use its own connected network, IP address, gateway, and table number:<\/p>\n\n\n\n Those addresses are from my recorded network state and are examples for explaining the table layout. A reusable script should discover them dynamically rather than hardcode them.<\/p>\n\n\n\n I also added an unreachable default route with metric This is a fail-closed measure. If the preferred route in a table disappears, traffic matching that table should not quietly fall through to the other Wi-Fi connection. It is intended to prevent the two Docker projects from silently swapping egress paths during a connection failure.<\/p>\n\n\n\n Once the routing tables are populated, policy rules connect each Docker subnet to its matching table:<\/p>\n\n\n\n The first rule means that packets whose source address belongs to The priority values determine where these rules are evaluated relative to other policy-routing rules. The normal built-in rules commonly include the local table at priority The helper removes previous copies of its own specific rule before adding a new one. That makes repeated runs less likely to accumulate duplicate rules.<\/p>\n\n\n\n I did not want to manually reconnect both Wi-Fi adapters, rebuild both routing tables, and start each Compose project every time I restarted the Raspberry Pi. I put the reusable functions into a separate file:<\/p>\n\n\n\n Then I added a small loader to The installer script created the functions file, added the loader to These commands are technically Bash functions rather than Bash aliases. They behave like short commands at the prompt, but each is a function containing multiple operations.<\/p>\n\n\n\n This helper searches saved NetworkManager profiles for a matching SSID. It prefers the profile already bound to the requested interface and returns its connection UUID. That UUID is then used to bring the correct profile up on the correct adapter.<\/p>\n\n\n\n This helper receives four parameters:<\/p>\n\n\n\n For example:<\/p>\n\n\n\n It waits up to 30 seconds for NetworkManager to report an IPv4 address and gateway and for the main table to contain a connected route for that interface. It then rebuilds the dedicated routing table, installs the connected and default routes, adds the unreachable fallback, removes duplicate copies of the matching policy rule, and adds one current rule.<\/p>\n\n\n\n This is the network restoration command. Its job is to:<\/p>\n\n\n\n The The important part is that the network restoration runs before the containers are started:<\/p>\n\n\n\n At the end, the function prints a table of running containers, status, and attached Docker networks.<\/p>\n\n\n\n The The four commands I wanted available at the shell were therefore:<\/p>\n\n\n\n The underscore-prefixed helpers are implementation details used by those commands.<\/p>\n\n\n\n The Compose files describe multiple services, each with its own container name, restart behavior, logging configuration, resource limits, and Watchtower labels. The saved second-stack Compose revision included services such as Honeygain, IPRoyal Pawns, TraffMonetizer, Repocket, EarnFM, ProxyRack, Bitping, Gradient, Proxybase, Watchtower, and the Money4Band web dashboard. Other iterations of the project also included additional services and experiments.<\/p>\n\n\n\n Several services use restart policies such as This keeps a container from growing its JSON log file indefinitely. The actual resource settings are read from Watchtower is configured with labels and a per-project scope. The saved settings included a polling interval of The Docker socket gives Watchtower access to the Docker API, so it should be treated as a privileged component. The scope and labels help keep the updater focused on the intended project rather than indiscriminately updating every container on the Pi.<\/p>\n\n\n\n The saved Raspberry Pi environment file used Container memory limits are ceilings, not a promise that memory is allocated immediately, but several containers can still compete for the same physical RAM. I would review both The Pi has to run the operating system, Docker, networking, and every container. Leave memory for the host and avoid assigning limits that assume the board has more RAM than it physically contains.<\/p>\n\n\n\n The Raspberry Pi 5 runs a 64-bit ARM operating system, and Docker identifies the architecture as The Compose files I worked with included a mixture of native ARM-oriented images and services explicitly configured with That allowed experimentation with images that were not available as native ARM64 images, but it does not make AMD64 emulation identical to running a native ARM64 image. Emulation can add overhead, and some images or programs may still fail. Whenever a provider publishes a suitable ARM64 image, native ARM64 is generally the better choice on this hardware.<\/p>\n\n\n\n I also experimented with EarnApp in a container, then worked with the native Linux EarnApp client as a separate system service. That native installation is distinct from the Docker Compose stacks and should not be assumed to be managed by the After running First, confirm the wireless profiles:<\/p>\n\n\n\n Then inspect the custom policy rules and route tables:<\/p>\n\n\n\n The expected policy is:<\/p>\n\n\n\nComponent<\/th> Recorded configuration<\/th><\/tr> Board<\/td> Raspberry Pi 5, 4 GB RAM<\/td><\/tr> Operating system<\/td> Debian GNU\/Linux 13 (Trixie) \/ Raspberry Pi OS<\/td><\/tr> Kernel<\/td> 6.18.50+rpt-rpi-2712<\/code><\/td><\/tr>CPU architecture<\/td> aarch64<\/code><\/td><\/tr>Docker architecture variable<\/td> arm64<\/code><\/td><\/tr>Cgroups<\/td> Version 2<\/td><\/tr> Cgroup driver<\/td> systemd<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nwlan0<\/code> is the built-in wireless adapter, while wlan1<\/code> is a separate USB Wi-Fi adapter. The USB adapter was identified as a Realtek 802.11be wireless adapter.<\/p>\n\n\n\nnmcli device status\n\nip addr show wlan0\nip addr show wlan1<\/code><\/pre>\n\n\n\nwlan0<\/code> had 192.168.18.51\/24<\/code> and wlan1<\/code> had 192.168.1.129\/24<\/code>. The gateways were 192.168.18.1<\/code> and 192.168.1.254<\/code>, respectively. These are private LAN addresses from my network at the time; your addresses and gateways will be different.<\/p>\n\n\n\n2. Confirming the two wireless adapters<\/h2>\n\n\n\n
sudo ip link set wlan0 up\nsudo ip link set wlan1 up\nsudo nmcli radio wifi on\n\n# Scan for networks visible to the built-in adapter.\nsudo nmcli device wifi list ifname wlan0\n\n# Scan for networks visible to the USB adapter.\nsudo nmcli device wifi list ifname wlan1<\/code><\/pre>\n\n\n\nifname<\/code> is useful because it asks NetworkManager to scan through the specified adapter. That helps confirm that each Wi-Fi network is visible to the interface that will eventually use it.<\/p>\n\n\n\n\n
connection.interface-name<\/code>: binds a saved profile to wlan0<\/code> or wlan1<\/code>.<\/li>\n\n\n\nconnection.autoconnect yes<\/code>: automatically reconnects the profile.<\/li>\n\n\n\nconnection.autoconnect-priority 100<\/code>: gives the intended profile a high autoconnect priority.<\/li>\n\n\n\n802-11-wireless.ssid<\/code>: identifies the network for that profile.<\/li>\n\n\n\n802-11-wireless-security.psk-flags 0<\/code>: tells NetworkManager to store the PSK in its system connection profile rather than asking for it every time.<\/li>\n<\/ul>\n\n\n\nsudo nmcli --ask device wifi connect \"PRIMARY_WIFI_SSID\" ifname wlan0\nsudo nmcli --ask device wifi connect \"SECONDARY_WIFI_SSID\" ifname wlan1<\/code><\/pre>\n\n\n\nnmcli connection show\nnmcli device status<\/code><\/pre>\n\n\n\nwlan0<\/code> and wlan1<\/code> each have a persistent, separate NetworkManager profile. The configuration does not depend on manually reconnecting to the right network every time the Pi reboots.<\/p>\n\n\n\n3. Why I used two Docker Compose projects<\/h2>\n\n\n\n
\/home\/<user>\/\n\u251c\u2500\u2500 money4band\/\n\u2502 \u251c\u2500\u2500 .env\n\u2502 \u251c\u2500\u2500 docker-compose.yaml\n\u2502 \u2514\u2500\u2500 application data and configuration\n\u2502\n\u2514\u2500\u2500 money4band2\/\n \u251c\u2500\u2500 .env\n \u251c\u2500\u2500 docker-compose.yaml\n \u2514\u2500\u2500 application data and configuration<\/code><\/pre>\n\n\n\n.env<\/code> file and its own Compose project name.<\/p>\n\n\n\nSetting<\/th> First project<\/th> Second project<\/th><\/tr> Compose project name<\/td> money4band<\/code><\/td>money4band2<\/code><\/td><\/tr>Docker network driver<\/td> bridge<\/code><\/td>bridge<\/code><\/td><\/tr>Docker subnet<\/td> 172.19.7.0\/27<\/code><\/td>172.20.7.0\/27<\/code><\/td><\/tr>Device name<\/td> Unique first-stack name<\/td> Unique second-stack name<\/td><\/tr> Watchtower scope<\/td> money4band<\/code><\/td>money4band2<\/code><\/td><\/tr>Host dashboard port<\/td> 8081<\/code> in the saved snapshot<\/td>Must be different if both dashboards publish a port<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n M4B_DASHBOARD_PORT=8081<\/code> for both projects. If both dashboard containers publish a host port at the same time, they cannot both bind the same host port. One project needs a different port, such as 8082<\/code>, and the corresponding dashboard URL must use that port. This is an important setting to check when duplicating the stack.<\/p>\n\n\n\n.env<\/code> file also contains account credentials, service tokens, UUIDs, and API keys for the services. Those values are intentionally not reproduced in this article. Keep secrets in local environment files, restrict access to those files, and do not commit them to a public Git repository or paste them into a public tutorial.<\/p>\n\n\n\n4. Configure each Docker bridge network with its own subnet<\/h2>\n\n\n\n
bridge<\/code> network driver. Each Compose project creates its own default bridge network, with a separate IP address range.<\/p>\n\n\n\nCOMPOSE_PROJECT_NAME=money4band\nNETWORK_DRIVER=bridge\nNETWORK_SUBNET=172.19.7.0\nNETWORK_NETMASK=27\nDETECTED_ARCHITECTURE=aarch64\nDETECTED_DOCKER_ARCH=arm64\nM4B_WATCHTOWER_SCOPE=money4band<\/code><\/pre>\n\n\n\nCOMPOSE_PROJECT_NAME=money4band2\nNETWORK_DRIVER=bridge\nNETWORK_SUBNET=172.20.7.0\nNETWORK_NETMASK=27\nDETECTED_ARCHITECTURE=aarch64\nDETECTED_DOCKER_ARCH=arm64\nM4B_WATCHTOWER_SCOPE=money4band2<\/code><\/pre>\n\n\n\nnetworks:\n default:\n driver: ${NETWORK_DRIVER}\n ipam:\n config:\n - subnet: ${NETWORK_SUBNET}\/${NETWORK_NETMASK}<\/code><\/pre>\n\n\n\n\n
172.19.7.0\/27<\/code><\/li>\n\n\n\n172.20.7.0\/27<\/code><\/li>\n<\/ul>\n\n\n\n172.19.7.1<\/code> and 172.20.7.1<\/code>. The containers in the first project use source addresses from the first subnet, while containers in the second project use addresses from the second subnet.<\/p>\n\n\n\n5. Why a Docker bridge network does not automatically select a Wi-Fi adapter<\/h2>\n\n\n\n
wlan0<\/code> or wlan1<\/code>.<\/p>\n\n\n\nmacvlan<\/code> networks with each wireless adapter as the parent interface. That was an early approach, but it was not the final configuration recorded in my Compose files. The implemented design uses normal Docker bridge networks and tells the Linux host which gateway to use for traffic from each Docker subnet.<\/p>\n\n\n\n\n
6. Creating separate Linux routing tables<\/h2>\n\n\n\n
wlan0<\/code> had metric 600<\/code>, and the secondary route through wlan1<\/code> had metric 601<\/code>.<\/p>\n\n\n\nwlan0<\/code> and container traffic from the other subnet to use wlan1<\/code>.<\/p>\n\n\n\nDocker source subnet<\/th> Physical interface<\/th> Routing table<\/th> Rule priority<\/th><\/tr> 172.19.7.0\/27<\/code><\/td>wlan0<\/code><\/td>100<\/code><\/td>1000<\/code><\/td><\/tr>172.20.7.0\/27<\/code><\/td>wlan1<\/code><\/td>101<\/code><\/td>1001<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nwlan0<\/code>, plus a default route through its gateway. The second table does the same for wlan1<\/code>.<\/p>\n\n\n\nsudo ip -4 route replace 192.168.18.0\/24 \\\n dev wlan0 scope link src 192.168.18.51 table 100\n\nsudo ip -4 route replace default \\\n via 192.168.18.1 dev wlan0 src 192.168.18.51 metric 10 table 100<\/code><\/pre>\n\n\n\nsudo ip -4 route replace 192.168.1.0\/24 \\\n dev wlan1 scope link src 192.168.1.129 table 101\n\nsudo ip -4 route replace default \\\n via 192.168.1.254 dev wlan1 src 192.168.1.129 metric 10 table 101<\/code><\/pre>\n\n\n\n42760<\/code> to each custom table:<\/p>\n\n\n\nsudo ip -4 route replace unreachable default metric 42760 table 100\nsudo ip -4 route replace unreachable default metric 42760 table 101<\/code><\/pre>\n\n\n\n7. Source-based policy rules<\/h2>\n\n\n\n
sudo ip -4 rule add priority 1000 \\\n from 172.19.7.0\/27 lookup 100\n\nsudo ip -4 rule add priority 1001 \\\n from 172.20.7.0\/27 lookup 101<\/code><\/pre>\n\n\n\n172.19.7.0\/27<\/code> should use routing table 100<\/code>. The second rule sends packets sourced from 172.20.7.0\/27<\/code> to table 101<\/code>.<\/p>\n\n\n\n0<\/code>, the main table at 32766<\/code>, and the default table at 32767<\/code>. My custom rules use priorities 1000<\/code> and 1001<\/code>, so they are evaluated before the normal main-table rule.<\/p>\n\n\n\n8. The Bash functions that manage the setup<\/h2>\n\n\n\n
~\/.money4band-functions<\/code><\/pre>\n\n\n\n~\/.bashrc<\/code>:<\/p>\n\n\n\n# Load Money4Band management commands in Bash.\n[ -f \"$HOME\/.money4band-functions\" ] && source \"$HOME\/.money4band-functions\"<\/code><\/pre>\n\n\n\n.bashrc<\/code> if it was not already present, and sourced .bashrc<\/code> so the functions became available in the current terminal. The installer also set the functions file to permission mode 600<\/code> because an earlier version contained local Wi-Fi credentials. For a public tutorial or a cleaner implementation, I would keep passwords out of shell scripts and use NetworkManager’s saved connection profiles or interactive prompts instead.<\/p>\n\n\n\n_m4b_wifi_uuid_for_ssid<\/code><\/h3>\n\n\n\n_m4b_apply_route<\/code><\/h3>\n\n\n\ninterface, Docker subnet, routing-table ID, rule priority<\/code><\/pre>\n\n\n\n_m4b_apply_route wlan0 172.19.7.0\/27 100 1000\n_m4b_apply_route wlan1 172.20.7.0\/27 101 1001<\/code><\/pre>\n\n\n\ndockernetwork<\/code><\/h3>\n\n\n\n\n
sudo -v<\/code>.<\/li>\n\n\n\nwlan0<\/code> and wlan1<\/code>.<\/li>\n\n\n\ndockerup<\/code><\/h3>\n\n\n\ndockerup<\/code> function manages both projects. It first looks for a supported Compose filename in each project directory (docker-compose.yaml<\/code>, compose.yaml<\/code>, docker-compose.yml<\/code>, or compose.yml<\/code>). It validates both configurations with docker compose config --quiet<\/code>, runs dockernetwork<\/code>, and then starts both projects with docker compose up -d<\/code>.<\/p>\n\n\n\nsudo docker compose -f \"$compose1\" config --quiet\nsudo docker compose -f \"$compose2\" config --quiet\n\ndockernetwork || return 1\n\nsudo docker compose -f \"$compose1\" up -d\nsudo docker compose -f \"$compose2\" up -d<\/code><\/pre>\n\n\n\ndockerdown<\/code><\/h3>\n\n\n\ndockerdown<\/code> function finds both Compose files and runs docker compose down<\/code> against each project. It records the exit status from each command so it can attempt to stop the second project even if shutting down the first one reports an error.<\/p>\n\n\n\ndockernetwork\ndockerup\ndockerdown<\/code><\/pre>\n\n\n\n9. What the Money4Band Compose configuration manages<\/h2>\n\n\n\n
always<\/code> or unless-stopped<\/code>, so Docker can restart them after a container or host restart. The Compose files also use JSON-file log rotation settings such as:<\/p>\n\n\n\nlogging:\n driver: json-file\n options:\n max-size: 10m\n max-file: \"3\"<\/code><\/pre>\n\n\n\n.env<\/code> variables and applied using Compose properties such as cpus<\/code>, mem_reservation<\/code>, and mem_limit<\/code>.<\/p>\n\n\n\n14400<\/code> seconds (four hours), rolling restarts, cleanup of replaced images, and access to the Docker socket:<\/p>\n\n\n\nvolumes:\n - \/var\/run\/docker.sock:\/var\/run\/docker.sock<\/code><\/pre>\n\n\n\nPay attention to RAM limits on a 4 GB Pi<\/h3>\n\n\n\n
RAM_CAP_MB_DEFAULT=1536<\/code> and memory limits ranging from 614m<\/code> to 1536m<\/code> for its resource classes. A later saved environment file for the second project contained a 6144<\/code> MB RAM cap and higher per-class limits. That later value is larger than the Pi’s 4 GB of physical memory and should not be copied as a safe recommendation for this hardware.<\/p>\n\n\n\n.env<\/code> files together and monitor actual use with:<\/p>\n\n\n\nsudo docker stats\nfree -h<\/code><\/pre>\n\n\n\n10. ARM64 images and AMD64 compatibility<\/h2>\n\n\n\n
arm64<\/code>. Not every image in a multi-service stack necessarily publishes an ARM64 build.<\/p>\n\n\n\nplatform: linux\/amd64<\/code>. For example, the saved second-stack Compose revision specified AMD64 for some services and ARM64 for others. I also installed binfmt<\/code> emulation support and checked that the host reported additional supported platforms.<\/p>\n\n\n\ndockerup<\/code> function.<\/p>\n\n\n\n11. Verifying that the two stacks use different routes<\/h2>\n\n\n\n
dockernetwork<\/code> or dockerup<\/code>, I check the network state instead of assuming the script worked.<\/p>\n\n\n\nnmcli -f DEVICE,TYPE,STATE,CONNECTION device status<\/code><\/pre>\n\n\n\necho \"========== POLICY RULES ==========\"\nip -4 rule show\n\necho \"========== ROUTING TABLE 100 ==========\"\nip -4 route show table 100\n\necho \"========== ROUTING TABLE 101 ==========\"\nip -4 route show table 101<\/code><\/pre>\n\n\n\n\n
172.19.7.0\/27<\/code> use table 100<\/code>, whose default route exits