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

> Discover how browser-based apps differ from container apps in InternetIncome. Learn about full browser stacks vs lightweight headless services for your applications.

- Repository: [engageub/internetincome](https://github.com/engageub/internetincome)
- Tags: deep-dive
- Published: 2026-03-01

---

**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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/properties.conf). Users enable them with simple boolean flags and occasionally a UUID or API key:

```bash

# properties.conf

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

```

The script checks these flags in [`internetIncome.sh`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh) handles these archives automatically:

```bash

# 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:

```bash

# 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:

```bash

# 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`](https://github.com/engageub/internetincome/blob/main/internetIncome.sh) creates a companion container (`dind$UNIQUE_ID`) that manages the browser lifecycle:

```bash

# 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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/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`](https://github.com/engageub/internetincome/blob/main/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.