Gmail Creator Pro: a Selenium bot that automates Gmail signups and buys phone numbers through 5sim

What Gmail Creator Pro actually automates

The README frames the project as a bulk Gmail signup tool: fill the Google account form, get past the phone step, save the credentials. The repository layout backs that up. There is an auto_gmail_creator.exe at the top level, a config/ directory, a data/ directory, and a requirements.txt listing selenium, webdriver-manager, rich, requests, unidecode, beautifulsoup4 and fp. Nothing in that list is an email library. This is a browser driver plus a console UI, not a client that reads mail.

The audience implied by the README is someone who wants many accounts rather than one: the feature list talks about bulk creation, a statistics dashboard with a success rate, and JSON storage of every account created. That is a different job from signing yourself up once. If you need a single personal mailbox, Selenium is the wrong layer entirely and you should close the tab.

The README also states the platform as Windows and the Python requirement as 3.8 or higher, with 3.12 recommended. Those two constraints together define the realistic deployment: a Windows desktop with Chrome installed, not a container.

How the signup flow is driven: Selenium, warm-up browsing and proxy rotation

The mechanism described in the README is a scripted Chrome session. Selenium drives the browser, webdriver-manager handles ChromeDriver download and setup, and rich renders the terminal interface with progress bars and color-coded messages. The anti-detection section lists the specific behaviors: typing with random delays between keystrokes in the 0.1 to 0.3 second range, random waits of 0.5 to 1.2 seconds between actions, rotation of user agents per account, and modification of navigator properties to hide automation signatures.

One detail is more interesting than the rest. The README describes session warming, where the browser pre-visits Google, BBC, Wikipedia and YouTube before touching the signup form. That is an attempt to give the session a browsing history before the account creation request, which is a common pattern in automation tooling and also the part most likely to break silently when any of those sites changes its consent or cookie flow.

Proxy handling is described as FreeProxy integration with random selection per account and a validation step before use. The README does not say what happens when validation fails for every candidate, nor how many proxies it tries before giving up. That gap matters, because a failed proxy usually surfaces as a Google error page rather than an exception, and the README's troubleshooting section is not reproduced in enough detail here to say how that case is handled.

Installing it on Windows and creating one account

The README lists the requirements as Windows 10 or 11, Python 3.8 or higher with 3.12 recommended, and the latest Chrome. Dependencies come from requirements.txt at the repository root. Install them into a virtual environment so the pinned Selenium and webdriver-manager versions do not collide with anything else on the machine.

python -m venv venv
venv\Scripts\activate
pip install -r requirements.txt

After that, the README points to the config/ directory for customization: separate config files for settings, a password file, and API key storage, with the stated goal of keeping secrets out of the main script. The README does not print the exact file names or keys inside config/, so open the directory and read what is there before running anything. The 5sim integration will need an API key in whichever file holds keys.

The repository also ships auto_gmail_creator.exe at the top level. The README does not document how that binary relates to the Python entry point, whether it is a frozen build of the same code, or which version it corresponds to. Treat the Python path as the documented one.

From there the README describes an interactive menu with five options and a statistics dashboard. Running the script and choosing the account-creation entry is the documented first use. Accounts land in data/ as JSON with email, password, creation date and status, saved immediately after creation. Check that file after the first run: if it is empty, the signup failed and the console output is where the reason will be.

The phone verification path and its 5sim dependency

Google's signup form asks for a phone number, and this project attacks that step two ways. The first is skipping: the README says the tool detects and clicks skip buttons, tries "Try another way" options, and handles both English and Arabic button text. The second is buying a number: 5sim API integration for automatic number purchase and SMS code retrieval, with retry logic across multiple strategies.

Both paths have failure modes the README does not resolve. Skip-button strategies depend on Google's current UI, and the README gives no version pinning or selector changelog, so a Google interface change breaks the strategy without warning. The 5sim path moves the problem rather than removing it: you now depend on a paid third-party SMS service, on number availability for the target country, and on the SMS arriving before Google's timeout. The README does not state which countries are supported, what the cost per number is, or what the tool does when a purchased number has already been used on Google. Those are the questions to answer before relying on this path.

The README also claims multi-language support for English and Arabic interfaces. That is a narrow set. Anyone targeting other locales should assume the skip selectors will not match.

Where this breaks: no rollback, no rate-limit story, no tests

The README does not document rollback. If a run creates an account and then fails before writing to data/, there is no described recovery path, and the account exists with credentials nobody recorded. That is the single most damaging failure mode for a bulk creation tool, and the auto-save-on-creation design only helps if the write happens before the failure.

There is no rate-limit or quota discussion either. The feature list mentions parallel processing as a future direction rather than a current capability, so runs are sequential, but the README says nothing about how many accounts per hour are reasonable before Google starts refusing. The proxy rotation and session warming are presented as the mitigation, with no stated success rate.

Testing is absent from the repository layout: no tests directory, no CI configuration among the top-level entries. For a tool whose correctness depends on external web pages that change without notice, that means every breakage is discovered by a user mid-run.

Finally, the licence situation is contradictory. The README badge says Proprietary, while the repository metadata reports NOASSERTION, and there is a LICENSE file at the root. Read that file. Do not assume you can fork, redistribute or ship the .exe in a product.

Alternatives: Playwright, undetected-chromedriver, or a mail API

The closest technical alternative is Playwright with its Python bindings. The difference is architectural: Playwright ships its own browser builds and bundles driver management, so the webdriver-manager dependency and the ChromeDriver-version mismatch class of bugs disappear. It also has first-class async support, which matters if you ever want the parallel creation the README lists as future work. What you lose is this project's assembled pieces: the warm-up browsing sequence, the skip-button strategies, the 5sim wiring and the rich console UI all have to be rebuilt.

A second option is undetected-chromedriver, which patches ChromeDriver and the browser fingerprint at the driver level rather than by modifying navigator properties from injected script. If your problem is specifically that Google detects the automated browser, that approach targets the detection layer more directly than per-account user-agent rotation.

If the actual goal is receiving mail rather than owning a Gmail mailbox, the right comparison is a transactional email API or a mail server you control. Those give you programmatic inboxes with an API contract and no signup form to fight, which removes the phone verification problem entirely. The trade-off is that you no longer have a Gmail address, which is the whole point of this project.

Maintenance status, upgrade cost and licence

The last push to the default branch was on 2026-09-16, and the repository is not archived. That is recent enough that the project is not abandoned, but the README documents no releases and the repository has no tags or changelog among its top-level entries, so upgrades are whatever lands on main. There is no versioned dependency contract beyond requirements.txt, which uses lower bounds (selenium>=4.15.0 and similar) rather than pins. That means a fresh pip install can pull a newer Selenium than the code was written against, and Selenium's API has changed across major versions. Pinning those versions yourself is the cheap insurance.

Operational cost sits in two places: the 5sim account, which is a paid service, and the proxy source. The README describes FreeProxy integration, which implies free proxy lists, and free proxy lists are unreliable by nature. A budget for paid residential proxies is realistic if you intend to run this at any volume.

The licence needs a direct read. The README badge says Proprietary, the repository metadata says NOASSERTION, and a LICENSE file exists. Those three signals do not agree, and none of them tells you whether redistribution is permitted. This is not legal advice: open LICENSE and SECURITY.md, and if the terms matter to your use, get them reviewed.

Editorial conclusion

Adopt this only if you specifically need to drive Google's signup form from a scripted Chrome session and you accept a Windows-only, proprietary-licensed tool whose README documents no rollback, no rate-limit handling and no test suite. Do not adopt it if you need a maintained library with a stable API, if you run headless Linux CI, or if you need the creator to be the account holder. Before anything else, read LICENSE and SECURITY.md in the repository, because the README calls the licence Proprietary while the repository metadata reports NOASSERTION, and check whether the 5sim path in config/ is wired to your own API key rather than a placeholder.

Frequently asked questions

Official sources

1. Issues
2. README
3. ShadowHackrs/gmail-account-creator on GitHub