7836246/aws-builder-id

1. This repository is a Python 3.10+ automation tool for registering AWS Builder ID accounts. The architecture centers on a Selenium-based browser automation flow, with supporting modules for environment simulation, email verification, and proxy/IP control.

2. The top-level execution boundary is under src/runners/. These entrypoints orchestrate the full lifecycle: start a browser session, prepare the target locale/device/proxy environment, complete the signup flow, wait for verification, and persist the resulting account record. The presence of main.py, single_outlook_run.py, batch_run.py, and smart_run.py suggests multiple orchestration modes rather than multiple business domains.

3. Browser interaction is abstracted in src/pages/. base_page.py is the likely shared layer for Selenium page actions and synchronization, while the actual AWS Builder ID signup steps are driven from the runner/service side. This creates a clear separation between page mechanics and workflow orchestration.

4. The external account verification path is handled in src/services/. email_service.py is the abstraction for receiving verification codes, with the README indicating integration with a Cloudflare Worker-based temporary email service. outlook_service.py and outlook_accounts.py indicate an alternative email backend centered on Outlook/IMAP account handling.

5. Persistence of successful registrations appears to be handled as structured local output, likely via a JSONL account store. The README explicitly mentions accounts.jsonl, and the services/outlook_accounts.py file suggests account metadata management is part of the service layer rather than embedded in the runners.

6. Environment simulation is split into helper modules under src/helpers/. fingerprint.py covers browser fingerprint shaping such as CPU, memory, and WebGL characteristics. multilang.py and the config/languages.yaml file support locale-specific text handling. ip_location.py likely maps or validates the current IP geolocation against the target region. utils.py is the shared utility boundary for cross-cutting tasks.

7. Proxy control is isolated in src/managers/. proxy_manager.py handles static proxy and dynamic proxy API modes described in the README, while whitelist_manager.py suggests support for allowlisting or brokered access setup. This manager layer sits between runner logic and network configuration, keeping IP concerns separate from signup workflow code.

8. The configuration boundary is explicit in config/config.yaml and config/languages.yaml, and loaded through src/config.py. The main configuration controls email backend, region, device type, proxy mode, and wait timeouts. Language configuration gives the automation layer localized strings for region-specific flows.

9. Region and device selection are first-class concerns in the architecture. The project supports USA, Germany, and Japan environments, and desktop/mobile device profiles. That means the system is not just registering accounts; it is also simulating a plausible client environment that matches the target locale.

10. The scripts under scripts/ are operational utilities around the core automation pipeline. They do not appear to be primary business logic; instead they validate or mutate environment state: checking fingerprints, testing proxies, switching regions or devices, debugging runs, probing email flow, and verifying Outlook login. This indicates the repo is designed for interactive operations and troubleshooting, not only unattended batch execution.

11. The main data flow is: configuration and region/device selection feed into proxy and fingerprint setup, the runner launches a hardened browser session, the signup form is completed, a verification code is retrieved from the configured email service, and successful account details are written locally. The browser, proxy, and email systems are therefore the three main external boundaries.

12. The project’s infrastructure dependencies are important to the architecture: Chrome/ChromeDriver for browser execution, Selenium for automation, and an anti-detection browser setup noted in the README. The temporary email service is externalized rather than embedded, which keeps inbox ingestion outside the core repo.

13. The documentation split under docs/ mirrors the major subsystems: region management, mobile mode, fingerprinting, proxy setup, and overall usage. That reflects the design of the codebase itself: a small orchestration core surrounded by specialized support modules for environment realism and verification.