How Browser-Based Apps Differ from Standard Container Apps in InternetIncome

Browser-based apps in InternetIncome run a full graphical browser stack inside Docker containers, while standard apps are lightweight headless services that require only environment variables and data volumes.

InternetIncome is an open-source automation framework by engageub/internetincome that monetizes idle bandwidth and computing resources through various containerized applications. The architecture distinguishes between standard headless containers (like Earnapp and Mysterium) and browser-based applications (like Ebesucher and Adnade) that require a complete UI rendering environment to simulate legitimate web traffic.

Execution Model and Architecture

Standard Headless Containers

Standard applications operate as single-process daemons without graphical interfaces. In internetIncome.sh, these containers mount minimal volumes and run lightweight images such as fazalfarhan01/earnapp:lite or mysteriumnetwork/myst:latest. They expose only service-specific ports (e.g., port 3000 for Earnapp) and consume minimal CPU and memory resources.

Browser-Based Containers with UI Stack

Browser-based apps launch a complete Chromium or Firefox instance inside the container. According to the source in internetIncome.sh, these containers use images like lscr.io/linuxserver/chromium:latest or jlesage/firefox, requiring --shm-size="1gb" to accommodate the browser's shared memory needs. Unlike headless services, these containers must handle profile data, VNC access, and periodic restarts to maintain session persistence.

Configuration and Setup Requirements

Simple Boolean Flags for Standard Apps

Standard apps require minimal configuration in properties.conf. Users enable them with simple boolean flags and occasionally a UUID or API key:

# properties.conf

EARNAPP=true
EARNAPP_UUID='your-uuid-here'

The script checks these flags in internetIncome.sh and starts containers only when the value equals true, mounting standard data directories without additional user credentials.

User Credentials and Profile Data for Browser Apps

Browser-based apps demand more complex configuration marked by the section #### Browser based Apps #### in properties.conf【/tmp/instagit_5ue0xwxd/properties.conf#L97-L100】. These require:

1. Username variables: EBESUCHER_USERNAME or ADNADE_USERNAME
2. Chrome preference flag: EBESUCHER_USE_CHROME=true to select Chromium over Firefox
3. Profile archives: chromeprofiledata.zip or firefoxprofiledata.zip containing pre-configured browser sessions

The extraction logic in internetIncome.sh handles these archives automatically:

# From internetIncome.sh - Profile extraction logic

if [ -f "chromeprofiledata.zip" ]; then
    mkdir -p chromeprofiledata
    unzip -o chromeprofiledata.zip -d chromeprofiledata/
fi

Container Runtime Differences

Docker Images and Resource Allocation

Standard apps use slim production images optimized for specific services. Browser apps require substantially larger base images containing full browser binaries and dependencies.

Resource allocation differs significantly:

# Browser-based Chrome container with shared memory allocation

sudo docker run -d --name ebesucher${UNIQUE_ID}${i} \
  --shm-size="1gb" \
  lscr.io/linuxserver/chromium:latest

The --shm-size="1gb" parameter is mandatory for Chromium to prevent crashes during rendering, while standard containers run without this flag.

Port Mapping and Access Methods

Standard containers expose single service ports for API or proxy access. Browser containers expose dual interfaces:

• Chromium: Port 3000 for the web interface (exposed via $eb_port="-p $ebesucher_first_port:3000"【/tmp/instagit_5ue0xwxd/internetIncome.sh#L48-L55】)
• Firefox: Port 5800 for VNC access (exposed via $eb_port="-p $ebesucher_first_port:5800"【/tmp/instagit_5ue0xwxd/internetIncome.sh#L14-L21】)

Users access these via http://127.0.0.1:<port> to view the actual browser UI, unlike headless services that operate invisibly.

Security Context and Privileges

Standard apps run with default Docker seccomp profiles. Browser-based Chromium requires relaxed security constraints:

# Security configuration for Chromium in internetIncome.sh

sudo docker run -d \
  --security-opt seccomp=unconfined \
  lscr.io/linuxserver/chromium:latest

The --security-opt seccomp=unconfined flag is necessary for Chromium's sandboxing mechanisms to function within the container environment, representing a significant security model difference from standard headless containers.

The Docker-in-Docker Helper Pattern

Browser-based apps implement a unique Docker-in-Docker (DinD) helper pattern absent in standard applications. The script internetIncome.sh creates a companion container (dind$UNIQUE_ID) that manages the browser lifecycle:

# Docker-in-Docker helper creation from internetIncome.sh

sudo docker run -d --name dind${UNIQUE_ID}${i} \
  --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
  --mount type=bind,source=$(which docker),target=/usr/bin/docker \
  --mount type=bind,source=$PWD,target=/chrome \
  docker:18.06.2-dind \
  /bin/sh -c 'apk add --no-cache bash && cd /chrome && chmod +x restart.sh && while true; do sleep 3600; ./restart.sh --restartChrome; done'

This helper mounts the host's Docker socket and binary to execute restart.sh periodically, ensuring the browser container restarts hourly to maintain session freshness—a complexity unnecessary for headless services that run continuously without UI state concerns.

Summary

• Standard container apps in InternetIncome are lightweight, headless services requiring only boolean flags and minimal environment variables in properties.conf.
• Browser-based apps require full graphical browser stacks (Chromium or Firefox), pre-configured profile data from chromeprofiledata.zip or firefoxprofiledata.zip, and specific username variables.
• Resource allocation differs significantly: Browser containers need --shm-size="1gb" for shared memory and --security-opt seccomp=unconfined for Chromium sandboxing.
• Port exposure varies: Standard apps use service-specific ports, while browser apps expose port 3000 (Chrome web UI) or 5800 (Firefox VNC).
• Docker-in-Docker pattern: Browser apps uniquely utilize a dind helper container to manage periodic restarts via restart.sh, maintaining browser session persistence.

Frequently Asked Questions

What configuration files are required for browser-based apps versus standard apps?

Standard apps require only a boolean flag in properties.conf (e.g., EARNAPP=true). Browser-based apps require the EBESUCHER_USERNAME or ADNADE_USERNAME variable, the EBESUCHER_USE_CHROME preference flag, and pre-packaged profile archives (chromeprofiledata.zip or firefoxprofiledata.zip) that the script extracts automatically in internetIncome.sh【/tmp/instagit_5ue0xwxd/internetIncome.sh#L18-L30】.

Why do browser-based containers need special security options?

Browser-based containers running Chromium require --security-opt seccomp=unconfined to allow the browser's internal sandboxing mechanisms to function correctly within the Docker environment. Standard headless containers operate with default seccomp profiles. Additionally, browser containers require --shm-size="1gb" to allocate sufficient shared memory for rendering web content, a resource constraint not present in standard app containers.

How does the Docker-in-Docker helper work for browser apps?

The internetIncome.sh script creates a companion dind container that mounts the host's Docker socket and binary. This helper runs a loop executing restart.sh --restartChrome every 3600 seconds to restart the browser container periodically, ensuring session freshness and preventing UI timeouts. Standard containers run continuously without this restart orchestration mechanism【/tmp/instagit_5ue0xwxd/internetIncome.sh#L32-L39】.

Can I access the browser UI of browser-based apps locally?

Yes. Browser-based apps expose web interfaces on specific ports that you can access via http://127.0.0.1:<port>. Chrome-based containers expose port 3000 for the web UI【/tmp/instagit_5ue0xwxd/internetIncome.sh#L48-L55】, while Firefox containers expose port 5800 for VNC access【/tmp/instagit_5ue0xwxd/internetIncome.sh#L14-L21】. This allows direct interaction with the browser session, unlike standard headless apps that operate invisibly in the background.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}