Turn an always-on Raspberry Pi into a remotely manageable Income Generator node
Income Generator, also known as IGM, manages containerized bandwidth-sharing applications through a command-line interface, terminal UI, or browser dashboard. This guide walks through the documented Linux installation, container runtime setup, WebUI startup, local verification, routine updates, and Raspberry Pi considerations before introducing remote access. Once the dashboard works locally at http://localhost:4747, we will connect it to a Localtonet HTTP tunnel as a separate step. Because the project is in beta and its supplied documentation does not establish WebUI authentication or authorization, the guide also explains why public exposure must be handled cautiously.
📋 What's in this guide
What this Raspberry Pi workflow does
Income Generator is an open-source manager for deploying and operating a collection of passive-income and bandwidth-sharing applications in containers. The manager itself provides a CLI, a terminal UI, and a browser-based WebUI. Its documented features include configurable resource limits, application updates, multi-proxy deployments, fleet management, and encrypted storage for application credentials. The exact behavior, account limits, network eligibility, and payout rules still depend on each application managed by IGM.
A Raspberry Pi can be a practical host because it is compact, consumes relatively little power, and can remain online without dedicating a desktop computer to the task. The Income Generator project lists Ubuntu and Debian on arm64 and amd64 among its tested Linux environments, and specifically identifies Raspberry Pi 4 as fully supported. The project also says older devices such as Raspberry Pi 3 using arm32v7 can run IGM, but warns that some applications may not work and that overall performance may be reduced.
This distinction matters. Installing the IGM management layer does not guarantee that every managed application has an image compatible with every ARM architecture. It also does not guarantee meaningful earnings, eligibility on a particular network, or acceptance of a residential, mobile, VPS, or hosting IP address. Treat this as a software self-hosting project, not as a promise of revenue.
igm runtime command sets up the required runtime when it is not already available.
http://localhost:4747 and can also be opened through the host's LAN IP when reachable.
Bandwidth-sharing software sends third-party traffic through your internet connection. Before deploying any managed application, verify local law, your internet service provider's contract, your network owner's policies, and the application's terms. You are responsible for understanding how your public IP address, bandwidth allowance, electricity use, account information, and device are affected.
Why installation comes before tunneling
A tunnel does not install, repair, or authenticate the application behind it. Localtonet forwards requests to a service that must already be running and reachable from the Localtonet client device. We therefore begin by installing IGM, preparing its container runtime, starting its WebUI, and testing the dashboard directly on the Raspberry Pi.
This order creates a useful troubleshooting boundary. If http://localhost:4747 does not work on the Pi, the problem is local to Income Generator, its runtime, or the host. If the local page works but the public address does not, the investigation can focus on the Localtonet client, selected device, local target, relay selection, or tunnel lifecycle.
Prerequisites and compatibility checks
Prepare the Raspberry Pi as a stable Linux host before running the installer. The evidence for this guide covers Ubuntu and Debian on Linux, including arm64 Raspberry Pi 4. It does not establish a particular Raspberry Pi OS image, required storage capacity, minimum memory allocation, or exact package list. We will not invent those requirements. If your image is derived from Debian but is not explicitly listed by the project, confirm compatibility before relying on it for an unattended deployment.
| Requirement | What is established | What you should check |
|---|---|---|
| Raspberry Pi model | Raspberry Pi 4 is listed as tested and fully supported. | Older Raspberry Pi 3 devices can run IGM, but performance and application compatibility may be reduced. |
| Operating system | Ubuntu and Debian are listed as tested Linux environments. | Use a maintained installation and confirm that your exact distribution and architecture meet project expectations. |
| Architecture | The tested Linux list includes arm64 and amd64. Older arm32v7 hardware has qualified support. |
Confirm that every application you plan to deploy is compatible with the Pi's architecture. |
| Container runtime | The WebUI requires a container runtime. The project provides igm runtime to set it up. |
Allow the runtime setup to finish before starting the WebUI. |
| Network connectivity | The installer downloads content from the project's repository, and managed applications require network access. | Confirm that outbound access is permitted and that bandwidth-sharing is allowed on this connection. |
| Local administration | Installation is initiated from a terminal with the project's shell installer. | Use an account authorized to install and run the required software on the Pi. |
| Remote access | A Localtonet client must run on the Pi or another device that can reach the Pi's dashboard. | Keep the device-specific Localtonet authentication token private. |
Plan resource use before deployment
IGM is described as lightweight, but it orchestrates other applications, and those workloads determine much of the real CPU, memory, storage, and network consumption. The project provides configurable resource limits, which are especially relevant on a single-board computer. Start with a limited deployment, observe the Pi's stability, and add workloads only when the host has sufficient capacity.
Temperature, power quality, storage reliability, and network stability are practical concerns for any continuously running Raspberry Pi. The supplied project evidence does not define safe thermal thresholds, recommended power supplies, or storage endurance requirements, so use the hardware manufacturer's guidance rather than assuming a universal value.
The official quick-start command downloads a shell script and immediately pipes it to sh. This is convenient, but it also means the downloaded code executes directly. If your security policy requires inspection, retrieve and review the installer from the project's official repository before executing it. Do not run similarly named commands copied from unofficial mirrors.
Install Income Generator on the Raspberry Pi
The following process uses the project's documented macOS and Linux installer. Run it in a terminal on the Raspberry Pi itself, or through an administrative shell connected to the Pi. Do not substitute the Windows installer. The Windows path is separate and relies on WSL, while this guide targets a Raspberry Pi running Linux.
Open a terminal on the Raspberry Pi
Sign in to the Linux environment where IGM will run. Confirm that this is the intended always-on host and that it has outbound internet connectivity.
Run the documented Linux installer
Execute the official installation command shown below. Allow the installer to finish and review any messages it prints rather than assuming installation succeeded.
Open the IGM interface
Run igm after installation. The project documents this as the command for opening its terminal interface and confirms that IGM is available from the command line.
curl -fsSL https://raw.githubusercontent.com/XternA/income-generator/installer/install.sh | shOnce installation completes, launch IGM:
igmReaching the IGM terminal interface is a useful first installation check. It confirms that the command was installed and can be invoked in the current shell. It does not yet confirm that the browser dashboard or container runtime is ready.
Installing the command-line manager is only the first stage. The browser interface requires a container runtime and must be started explicitly. Follow the next section before testing port 4747.
Set up the runtime and start the WebUI
The Income Generator documentation places the container runtime before WebUI startup. Preserve that sequence. On ARM devices, the project says QEMU is configured automatically during the container runtime installation. This can help with container compatibility, but it does not guarantee that every application will perform well under emulation.
Set up the container runtime
Run igm runtime. This is the project's documented setup path when the WebUI's required container runtime is not already installed.
Start the WebUI with boot startup enabled
Run igm web start --auto. The documented --auto option configures the WebUI to start automatically when the host boots.
Open the documented dashboard endpoint
On the Raspberry Pi, browse to http://localhost:4747. The project also documents access through the host's LAN IP, which is useful for testing from another trusted device on the same network.
igm runtimeWait for runtime setup to complete before continuing. Then start the browser interface:
igm web start --autoOpen the local address:
http://localhost:4747The dashboard is the interface for configuring, deploying, monitoring, and managing supported applications. Account creation and credential requirements vary by application, so there is no safe universal credential template to provide here. Register only through the official service associated with each application, follow its device and IP limits, and never paste application credentials into an unrelated website or support request.
What not to assume about the dashboard
The evidence confirms the dashboard address and its management purpose. It does not establish a default WebUI username, default password, authentication mechanism, role model, authorization policy, CSRF protection, or built-in HTTPS listener. We therefore cannot claim that the dashboard is safe to publish openly just because managed application credentials are encrypted at rest.
Encryption at rest protects a different boundary. It concerns how IGM stores supported application secrets. Dashboard authentication determines who can reach the management interface and issue actions. Both matter, but one does not replace the other.
Verify Income Generator locally before remote access
Complete local verification before creating a tunnel. A successful check should establish that the installed command works, the runtime is available, the WebUI process is running, and the dashboard can be loaded from the expected endpoint.
Confirm the installed version
Run igm version. This command is documented by the project for checking the installed release.
Load the dashboard on the Pi
Open http://localhost:4747 in a browser available on the Raspberry Pi. Confirm that the interface loads rather than relying only on a startup message.
Test trusted LAN access if needed
From another device on the same trusted network, open http://LAN-IP:4747, replacing LAN-IP with the Raspberry Pi's actual local address. Do not literally use the placeholder.
Check behavior after a planned reboot
If you used --auto, verify during a maintenance window that the dashboard returns after the Pi reboots. This confirms the boot-start behavior in your actual environment.
igm versionLAN access is optional for the final Localtonet design when the Localtonet client runs directly on the Raspberry Pi. In that arrangement, the tunnel can target the loopback address on the same machine. LAN testing is still useful when the Localtonet client will run on another trusted device that must connect to the Pi over the local network.
If the Localtonet client runs on the same Raspberry Pi, target the local dashboard on 127.0.0.1:4747. If the client runs elsewhere, it must target an address for the Pi that is actually reachable from that client device. Verify that path locally before involving a public tunnel.
Access the Income Generator dashboard with Localtonet
Once the WebUI is working locally, an HTTP tunnel can expose it through Localtonet. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, a public IP address, VPN setup, or an inbound firewall change.
An HTTP tunnel points to a local IP address and port. For a Localtonet client running directly on the same Raspberry Pi as IGM, the target is 127.0.0.1 on port 4747. If the client runs on another machine, use the Raspberry Pi's reachable LAN address instead. Do not use 127.0.0.1 from a different machine because loopback always refers to the machine running the client.
The supplied Income Generator documentation does not establish WebUI authentication, authorization, or an access-control layer suitable for an internet-facing management console. A Localtonet tunnel provides connectivity and a public address, but it does not automatically add application-level login protection. Do not leave the tunnel running broadly unless you have independently verified appropriate protection for the installed IGM version. For temporary administration, start the tunnel only when needed and stop it immediately afterward.
Install and run the Localtonet client
Install our client on the Raspberry Pi, or on another trusted device that can reach the Pi's WebUI. Keep the client running for as long as remote access is required. Current installation details can vary by operating system and client version, so use the current instructions available through our Localtonet documentation.
Authenticate and select the client device
Use the device-specific authentication token associated with the client that will run the tunnel. Never publish, hardcode, or share this token. Select that connected device when creating the tunnel.
Select an available relay server
Choose a currently available Localtonet relay server or region from the product interface. Available values can change and may vary by plan, so do not copy a server code from an unrelated tutorial.
Create the HTTP tunnel configuration
Select an HTTP tunnel and set its local target to 127.0.0.1 with port 4747 when the Localtonet client is on the Pi. If the client runs on another device, enter the Pi's verified LAN IP and port 4747. Choose the available process type appropriate to your deployment.
Start the tunnel and test its assigned address
Creating a tunnel does not start it. Press Start, then use the public address assigned to the running tunnel. Test only after confirming that the selected client device is connected and IGM still responds locally.
Stop or delete access when finished
Stop the tunnel as soon as remote administration is complete, particularly when the WebUI's authentication status has not been established. Delete the tunnel if it is no longer needed.
Choosing an HTTP process type
Localtonet HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain process types. All three serve the target content at a public HTTPS address. Availability can vary, and custom-domain DNS requirements must be checked against current documentation rather than inferred from another setup.
| Process type | Appropriate use | Important consideration |
|---|---|---|
| Random Sub Domain | Temporary testing or occasional administration | Use the assigned public HTTPS address and stop the tunnel after the session. |
| Custom Sub Domain | A selected subdomain where supported | Availability may depend on the current product configuration or plan. |
| Custom Domain | A domain name controlled by the operator | Verify current DNS instructions before changing records. Do not guess record types or targets. |
The public tunnel remains available only while the selected Localtonet client is connected and the tunnel is running. The Income Generator WebUI must also remain active. If any part of that chain stops, the public endpoint cannot deliver the dashboard.
Routine operation and updates
A self-hosted service needs maintenance after installation. For Income Generator, the supplied release instructions establish commands for updating IGM, checking its version, and restarting the WebUI. Use these commands deliberately, especially on an unattended Raspberry Pi where a failed update could interrupt the dashboard.
Check the installed version
igm version
The official release evidence identifies 3.0.0-beta.7 as a beta release and documents igm version for confirming what is installed. Because beta software can change behavior and interfaces, check the release information applicable to the version you actually install before exposing it remotely.
Update Income Generator
igm updateAfter updating, check the version again:
igm versionIf the WebUI still displays a previous version, the documented corrective action is:
igm web restartIf the normal update does not work, the project instructs Linux users to run the installer again to force the update:
curl -fsSL https://raw.githubusercontent.com/XternA/income-generator/installer/install.sh | shRestart the WebUI afterward when required:
igm web restartUse a maintenance sequence
Before changing the runtime or updating IGM, stop the public Localtonet tunnel if remote access is not required during maintenance. Perform the update locally, verify the installed version, restart the WebUI when needed, and load http://localhost:4747. Only restart the public tunnel after the local dashboard has passed verification.
This prevents a broken or partially updated interface from being needlessly internet-accessible. It also ensures that a public failure is not mistaken for a Localtonet problem when the underlying WebUI is unavailable.
Monitor managed workloads conservatively
Add applications gradually and observe CPU use, memory pressure, storage activity, temperature, and network consumption with the normal monitoring tools for your Linux environment. IGM supports configurable resource limits, but the supplied evidence does not provide one universal limit profile for Raspberry Pi hardware. A safe configuration depends on the Pi model, memory, cooling, architecture, container images, and number of application instances.
Be equally careful with multi-proxy scaling. The project supports deploying multiple instances from a proxy list, but that capability does not override an application's device limits, per-IP limits, account rules, or a proxy provider's terms. Technical capability should not be interpreted as permission.
Security and exposure checklist
This workflow combines three security boundaries: the Raspberry Pi host, the IGM management application, and the Localtonet tunnel. Each must be considered separately. A public HTTPS address protects the browser-to-edge transport used for the tunnel, but it does not prove that the dashboard requires a login or that every action is appropriately authorized.
The Localtonet address and the Income Generator dashboard solve different problems. The tunnel transports requests to the local service. IGM must determine whether a requester is allowed to view credentials, deploy applications, change proxy settings, or perform management actions. If the installed WebUI does not enforce suitable authentication and authorization, keep it private rather than relying on an unguessable URL.
A safer decision process
First, verify whether the exact IGM version you installed requires authentication before showing any dashboard content. Second, determine whether all sensitive actions are protected, not merely the landing page. Third, use any applicable access restrictions available in your current environment. Finally, expose the interface only for the minimum time and audience required.
If you cannot establish these properties, remote public exposure should be deferred. You can still manage IGM locally from the Pi or through a trusted local administrative path. Convenience should not take priority over protecting a dashboard that can control bandwidth-sharing workloads and stored account information.
Troubleshooting the installation and tunnel
Troubleshoot from the inside out. Begin with the IGM command, then the container runtime, then the local WebUI, followed by LAN reachability if applicable, and only then the Localtonet tunnel. This order keeps unrelated problems from being mixed together.
| Symptom | Likely boundary | Recommended check |
|---|---|---|
igm does not launch after installation |
Installation or command availability | Review the installer's output and confirm that it completed. Do not invent an executable path. If necessary, use the project's documented installer again. |
| The WebUI does not start | Container runtime or WebUI startup | Run igm runtime first, allow it to finish, then run igm web start --auto. |
localhost:4747 does not load |
Local IGM WebUI | Confirm the WebUI startup command completed. Use igm web restart, then test the local endpoint again. |
| The WebUI shows an older version | WebUI process lifecycle | Run igm version to check the installed version, then run igm web restart as documented. |
| The update command does not work | IGM update process | Run the official Linux installer again to force the update, then restart the WebUI and verify locally. |
| The dashboard works on the Pi but not over the LAN | Local network reachability | Confirm that the other device is using the Pi's real LAN IP and port 4747. Review host and network policy without disabling security controls indiscriminately. |
| The dashboard works locally but not through Localtonet | Tunnel configuration or lifecycle | Confirm the selected client is connected, the local target is correct, the relay selection is current, and the tunnel has been started. |
The tunnel targets 127.0.0.1:4747 from another device |
Incorrect target addressing | Replace loopback with the Raspberry Pi's reachable LAN IP. From another machine, 127.0.0.1 points back to that machine, not the Pi. |
| An application performs poorly on Raspberry Pi 3 | Hardware or architecture compatibility | The project warns that older arm32v7 SBCs can have reduced performance and unsupported applications. Test a smaller workload or move it to supported hardware. |
| The public URL stops working unexpectedly | Client, tunnel, or local service availability | Check that the IGM WebUI is running, the selected Localtonet client remains connected, and the tunnel is still in its running state. |
Separate local failures from tunnel failures
If the local dashboard is unavailable, stop troubleshooting the public address and repair IGM first. Localtonet cannot forward to a service that is not listening. Once the dashboard loads locally, verify the target from the client device. If the client is on the Pi, that target is 127.0.0.1:4747. If the client is elsewhere, verify the Pi's LAN address from that machine.
When the target is reachable but the public address fails, confirm that creating the tunnel was followed by starting it. Also confirm that the intended device token was selected. A tunnel associated with an offline or different device cannot reach the Raspberry Pi dashboard.
Frequently asked questions
Does Income Generator officially support Raspberry Pi?
The project lists Raspberry Pi 4 among its tested and fully supported environments, using Linux on ARM. It says older devices such as Raspberry Pi 3 with arm32v7 can run IGM, but some applications may not work and performance may be reduced.
What port does the Income Generator WebUI use?
The documented dashboard endpoint is http://localhost:4747, so the WebUI uses local TCP port 4747. The project also documents opening it through the Raspberry Pi's LAN IP.
Does the WebUI require a container runtime?
Yes. The project states that the WebUI requires a container runtime. Run igm runtime to set it up before starting the dashboard with igm web start --auto.
Does the WebUI start automatically after a reboot?
The documented --auto flag in igm web start --auto configures the WebUI to start on boot. Test this behavior after installation during a planned reboot rather than assuming it works in every host configuration.
Do I need router port forwarding to reach the dashboard with Localtonet?
No. Our client creates an outbound connection to a Localtonet relay server. The resulting HTTP tunnel provides a public address without inbound router port forwarding, a public IP address, VPN setup, or inbound firewall changes.
Should the Localtonet target be localhost or the Raspberry Pi's LAN IP?
Use 127.0.0.1 and port 4747 when the Localtonet client runs directly on the Raspberry Pi. If the client runs on another device, use a Raspberry Pi LAN address that is reachable from that device. Loopback on another machine does not point to the Pi.
Does Localtonet add a password to the Income Generator dashboard?
An HTTP tunnel provides connectivity to the configured local target. It does not automatically create application-level authentication for IGM. The supplied project documentation does not establish WebUI authentication, so verify protection independently and avoid persistent public exposure when that protection is uncertain.
How do I update IGM and refresh the WebUI?
Run igm update, then use igm version to check the installed version. If the WebUI still displays an earlier version, run igm web restart. If updating fails, the project documents rerunning the Linux installer to force the update.
Does running Income Generator guarantee passive income?
No. Results depend on application eligibility, network type, geographic demand, account limits, uptime, bandwidth, electricity costs, and each service's rules. Installation and technical compatibility do not guarantee acceptance, traffic, payouts, or profit.
Connect your verified Raspberry Pi dashboard with Localtonet
Install and test Income Generator locally first, confirm how your WebUI is protected, then create a temporary HTTP tunnel to 127.0.0.1:4747 from the same Raspberry Pi. Stop the tunnel whenever remote administration is no longer required.
