# any-auto-register: batch AI account registration with a plugin provider stack

> any-auto-register automates signup and lifecycle management for ChatGPT, Cursor, Kiro, Grok, Windsurf, Trae and other AI platforms. It ships as an Electron desktop app or a Docker image, and its real substance is the provider layer for mail, captcha, SMS and proxies.

**lxf746/any-auto-register** — Auto-register & manage accounts for ChatGPT, Cursor, Kiro, Grok, Windsurf, Trae & 13+ AI platforms · Protocol/browser dual-mode · Plugin-based · One-click Mac/Windows desktop app

- Repository: https://github.com/lxf746/any-auto-register
- Website: https://github.com/lxf746/any2api
- Stars: 3,322 · Forks: 1,067
- Language: Python
- License: AGPL-3.0
- Published: 2026-09-14 · Updated: 2026-09-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/lxf746-any-auto-register

## The gap any-auto-register fills between signup scripts and account operations

Most registration scripts stop when the account exists. The README states the project's own framing of that gap: mail management, captcha solving, proxy rotation, continued use after signup, token expiry, and error diagnosis are the parts it claims to cover. Whether you agree with the comparison table in the README is secondary; the useful question is whether you have those problems. If you register one account a month, you do not.

The target user is someone running a pool. The account pool view groups accounts by platform tab and shows password, manager, status, quota, payment link and last query time. A lifecycle layer runs scheduled validity checks, renews tokens, and warns before a trial expires. A risk center collects expired tokens, near-exhausted trials and proxy connectivity failures in one place. That is operations tooling, not a one-shot script.

The desktop client is the recommended path. The README describes it as zero-configuration, with the backend and frontend embedded in Electron, and requires an activation code obtained by joining a community group. That activation requirement is the first thing to think about, because it sits between you and the software.

## Protocol, headless and headed modes, and why the plugin boundary matters

Execution mode is a per-platform choice, not a global setting. The README lists three: pure protocol with no browser, which it calls the fastest; headless browser; and headed browser. Platforms that can be driven by direct HTTP calls use protocol mode. Platforms that need a real browser context fall back.

The repository layout supports the plugin claim. There are separate top-level directories for platforms, providers, services, core, api, application, infrastructure, domain and tools, plus a frontend and an electron directory. The README says platform, mail, captcha, SMS and proxy drivers are all hot-pluggable. A provider catalog on the backend drives the configuration UI, so the README states that adding a backend provider makes it appear in the frontend after a refresh without hardcoding options.

Mail is where the plugin model earns its keep. The README lists nine channels, including MoeMail built on cloudflare_temp_email, a self-hosted Cloudflare Worker, Laoudo with a fixed owned domain, Testmail with namespace mode and automatic tag plus time filtering, DuckDuckGo Email aliases read over IMAP, Freemail, DuckMail, TempMail.lol and Temp-Mail Web. Captcha is YesCaptcha, 2Captcha or a local Camoufox solver. SMS is SMS-Activate or HeroSMS. Requirements.txt confirms the runtime shape: fastapi, uvicorn, sqlmodel, curl_cffi, playwright, camoufox and patchright are all present.

The honest read on the architecture is that the platform adapters are the fragile part. Mail and captcha providers are commodity services with stable APIs. Platform signup flows are not, and the README's own note that enhanced implementations for the latest platform adaptations ship with the desktop version tells you the source tree and the binary can diverge.

## Running any-auto-register with Docker Compose

The Docker path is the reproducible one and needs no activation code. The README gives a compose file that maps three ports: 8000 for the web UI, 6080 for a noVNC browser view, and 8889 for the Turnstile solver. The repository's own docker-compose.yml builds from the local Dockerfile instead of pulling an image, and sets ACCOUNT_MANAGER_DATABASE_URL to a SQLite file under /app/data.

Create a directory, write the compose file, and bring it up:

```bash
mkdir -p any-auto-register && cd any-auto-register

docker compose up -d
```

The README's version of the file uses the published image `ghcr.io/lxf746/any-auto-register:latest` and sets DISPLAY=:99. The repository version builds locally and additionally accepts APP_PASSWORD and VNC_PASSWORD. Both persist data through a ./data volume mount. If you deploy on a cloud host, the README says to open ports 8000, 6080 and 8889.

After startup, the web UI is at http://localhost:8000, the noVNC view at http://localhost:6080/vnc.html, and the solver at http://localhost:8889. The Dockerfile confirms what is inside: it builds the frontend with Node 20, installs Chromium, Xvfb, x11vnc and noVNC on a python:3.12-slim base, runs playwright install --with-deps chromium and python -m camoufox fetch, and injects the version into core/version.py. First use means opening the global configuration page, adding one mail provider and one captcha provider, then starting a registration task for a platform.

## Building any-auto-register from source and the activation-code boundary

The source path needs Python 3.11 or newer and Node.js 18 or newer. The README's sequence clones the repository, enters the account_manager directory, creates a virtual environment, installs requirements, builds the frontend, optionally fetches the browser binaries, and starts uvicorn on port 8000.

```bash
git clone https://github.com/lxf746/any-auto-register.git
cd any-auto-register/account_manager

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

cd frontend && npm install && npm run build && cd ..

python3 -m playwright install chromium
python3 -m camoufox fetch

python3 -m uvicorn main:app --port 8000
```

The two fetch commands are only needed for browser modes. Playwright installs Chromium; camoufox fetch pulls the browser the local captcha solver uses. If you stay in protocol mode and use a hosted captcha service, you can skip both and save a large download.

The README is explicit that the source build is not feature-identical to the desktop build. Task queue advanced controls, activation code management, payment flow enhancements and the newest platform adaptations are described as shipping with the desktop version. So the source tree is the right choice for self-hosting and for writing providers, and the wrong choice if you need the newest adapter on release day. Note also that the desktop app requires an activation code from a community group, so the zero-configuration path has a gate the Docker path does not.

## Where any-auto-register breaks down

The AGPL-3.0 licence is the first constraint, and it is not a formality. If you modify the code and expose it as a network service, the licence's network clause applies. The README adds its own restriction on top, stating the project is for learning and research and must not be used for commercial violations, with users responsible for complying with target platform terms. That is a statement of intent from the author, not a legal shield for you.

Platform terms are the second constraint, and the more practical one. Automating account creation on ChatGPT, Cursor or Grok is exactly the behaviour those services write anti-abuse rules against. The README's own risk center categories name the failure modes: proxy flagged by risk control, abnormal email domain, secondary verification. Those are not hypothetical; they are the taxonomy the project built to describe its own failures. Expect a nonzero failure rate and expect it to move whenever a platform changes its signup flow.

The third constraint is the activation code. The desktop build, which is the recommended path and the one with the newest platform support, requires a code obtained by joining a community group. The README does not document an offline or self-service issuance path. If you need something you can install without talking to anyone, use Docker or the source build and accept the feature gap.

Finally, this is the wrong tool if you need one or two accounts, if the platforms you care about are not in the list, or if you need vendor support with an SLA. The last push to the repository was on 2026-08-25, and the most recent release listed is v1.0.23 from 2026-05-06, so the release cadence and the commit cadence are not the same thing.

## any-auto-register against a plain Playwright or Selenium script

The obvious alternative is writing your own Playwright script. The difference is not the browser automation; it is everything around it. A hand-written script gives you one platform, no mail abstraction, no captcha service integration, no proxy health tracking, and no persistence layer. You write the retry logic, the token refresh job and the error taxonomy yourself.

any-auto-register already has those as named subsystems. The proxy pool does static rotation weighted by success rate, dynamic API extraction and rotating gateways, with automatic disabling of dead entries. Statistics break down success rate by platform, by day and by proxy, and attribute failures to one-time success, secondary verification, proxy flagged, or abnormal email domain. Export formats include JSON, CSV, CPA, Sub2API, Kiro-Go and the Any2API admin.json.

The trade-off is control and transparency. A script you wrote is one you can debug line by line. any-auto-register is a FastAPI backend plus a React frontend plus an Electron shell plus a provider catalog, and when a platform changes its flow you are waiting for an adapter update rather than patching a selector. If your need is narrow and stable, the script wins. If you are juggling several platforms and several mail providers, the abstraction is the point.

## Conclusion

Adopt it if you already operate a pool of AI platform accounts and want the mail, captcha and proxy plumbing in one place, or if you plan to write your own platform plugin. Do not adopt it if you need a supported commercial product, if you cannot accept AGPL-3.0, or if the platforms you care about are not in the provider list. Before committing, verify that your chosen email provider works from your network, that the activation code path is something you can satisfy, and that the registration flow for your target platform is present in the source tree rather than only in the desktop build.

## FAQ

### How do I install any-auto-register?

The README recommends the desktop build, downloaded as a .dmg for macOS or an .exe for Windows from the releases page. Alternatively, run the published Docker image with docker compose, or build from source with Python 3.11+ and Node.js 18+ and start uvicorn on port 8000.

### Does any-auto-register need an activation code?

The desktop version does. The README's quick start says to download, install, launch, enter an activation code obtained by joining a community group, then choose a platform and configure email. The Docker and source paths described in the README do not mention an activation code.

### Which AI platforms and email providers does any-auto-register support?

The README lists ChatGPT, Cursor, Kiro, Trae.ai, Tavily, Grok, Blink, Cerebras, OpenBlockLabs and Windsurf, plus an Anything generic adapter. Email channels include MoeMail, a self-hosted Cloudflare Worker, Laoudo, Testmail, DuckDuckGo Email, Freemail, DuckMail, TempMail.lol and Temp-Mail Web.

## Sources

- [License: AGPL-3.0](https://github.com/lxf746/any-auto-register/blob/main/LICENSE)
- [lxf746/any-auto-register on GitHub](https://github.com/lxf746/any-auto-register)
- [Project website](https://github.com/lxf746/any2api)
- [README](https://github.com/lxf746/any-auto-register/blob/main/README.md)
- [Releases](https://github.com/lxf746/any-auto-register/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lxf746-any-auto-register