How to Use Firefox and Chrome Profile Data in InternetIncome Containers

InternetIncome containers require pre-packaged browser profiles in firefoxprofiledata.zip and chromeprofiledata.zip to persist login states and custom settings across container restarts.

The engageub/internetincome repository orchestrates browser-based income apps inside Docker containers. To stay logged into platforms like Ebesucher and Adnade, you must supply packed profile archives that the main script automatically extracts, duplicates, and mounts into each browser instance.

Prerequisites: Profile Archives

The orchestration script internetIncome.sh expects two specific archives in the repository root. The required files list is hardcoded at line 59 in internetIncome.sh:

• firefoxprofiledata.zip
• chromeprofiledata.zip

If either archive is missing, the script aborts immediately with an error message (Chrome profile file does not exist or Firefox profile file does not exist). These archives serve as the master templates copied to every container instance on startup.

How the Script Handles Browser Profiles

The workflow follows four distinct phases coded into internetIncome.sh:

1. Archive Extraction

Before launching any container, the script extracts the zip files into working directories. This ensures fresh copies are available for duplication.

• Chrome extraction occurs at lines 319–326:

  unzip -o $chrome_profile_zipfile

  This creates or overwrites the chromeprofiledata folder.

• Firefox extraction occurs at lines 385–393:

  unzip -o $firefox_profile_zipfile

  This creates or overwrites the firefoxprofiledata folder.

2. Per-Instance Data Preparation

Each browser instance receives its own isolated data directory to prevent conflicts. The script creates numbered folders (e.g., chromedata/data1) and populates them with the extracted profile contents.

• Chrome data setup at lines 41–46 copies the unpacked profile into the instance-specific folder.
• Firefox data setup at lines 450–456 performs the same operation for Firefox instances.

Permissions are explicitly set to user 911, the UID employed by the LinuxServer/jlesage base images used in these containers.

3. Bind-Mounting into Containers

The prepared profile folders are mounted into the container’s /config directory via Docker bind mounts. This allows the browser to read from and write back to the host filesystem.

• Chrome mount (line 57):

  --mount type=bind,source=$PWD/$chrome_data_folder/data$i/$chrome_profile_data,target=/config

• Firefox mount (line 452):

  --mount type=bind,source=$PWD/$firefox_data_folder/data$i,target=/config

4. Persistence Across Restarts

Because the script copies the master profile before each --start invocation, changes made inside a running container (new cookies, extensions, or settings) are retained in the numbered data folders. Subsequent restarts re-read these modified folders, ensuring continuity without requiring you to repack the zip archive after every change.

Customizing Your Browser Profiles

To inject your own logged-in sessions or extensions, modify the archives before starting the script.

Modifying Firefox Profiles

Extract the default archive, launch Firefox with the extracted directory, make your changes, then repack:

# Extract the master profile

unzip -o firefoxprofiledata.zip -d firefoxprofiledata

# Launch Firefox using this profile path

firefox -profile "$(pwd)/firefoxprofiledata"

# After logging in and configuring settings, repack the archive

zip -r firefoxprofiledata.zip firefoxprofiledata/*

Modifying Chrome Profiles

The process is identical for Chromium-based browsers:

# Extract the master profile

unzip -o chromeprofiledata.zip -d chromeprofiledata

# Launch Chromium with the custom user data directory

chromium --user-data-dir="$(pwd)/chromeprofiledata"

# Repack after configuration

zip -r chromeprofiledata.zip chromeprofiledata/*

Using Symlinks for Custom Paths

If you prefer maintaining your profile folders outside the repository root, replace the zip file with a symbolic link:

rm firefoxprofiledata.zip
ln -s /path/to/your/firefoxprofiledata firefoxprofiledata.zip

The existence check at line 59 treats symlinks identically to regular files, allowing you to version-control your profiles separately while satisfying the script’s requirements.

Summary

• Required files: The script mandates firefoxprofiledata.zip and chromeprofiledata.zip in the repository root (line 59).
• Extraction logic: internetIncome.sh unpacks both archives using unzip -o before container creation (lines 319–326 and 385–393).
• Instance isolation: Profiles are copied into numbered subdirectories (chromedata/data1, etc.) with UID 911 permissions (lines 41–46, 450–456).
• Container injection: Bind mounts map host profile folders to the container’s /config path (lines 57 and 452).
• Customization workflow: Extract, modify with standard browser binaries, repack, then run sudo bash internetIncome.sh --start.

Frequently Asked Questions

What happens if I delete the zip files after the first extraction?

The script will abort at the validation step (line 59) during the next --start invocation. While the extracted folders in chromeprofiledata/ or firefoxprofiledata/ may persist, internetIncome.sh requires the master archives to exist before it will proceed with container creation.

Can I use the same profile for multiple simultaneous instances?

Yes. The script copies the master profile into separate per-instance folders (e.g., data1, data2) before mounting. Each container writes to its own isolated copy, preventing collisions while allowing you to scale horizontally from a single source archive.

Do I need to repack the zip file after every browser session?

No. Because the bind mount allows writes back to the host filesystem, cookies and settings persist in the numbered data folders between restarts. You only need to repack the zip when you want to update the master template used to initialize new instances or when moving to a fresh deployment.

Which Docker images consume these profiles?

The profiles are mounted into containers based on LinuxServer and jlesage images (using UID 911). These specifically support the Ebesucher and Adnade browser automation apps defined in properties.conf. The mount target /config is the standard configuration path expected by these image maintainers.

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