any-auto-register: a plugin-based account factory for 11+ AI platforms

What any-auto-register actually takes off your plate

The repository's own framing is that comparable projects stop at "how do I register on one platform" and leave the operational work undone. That work is the product here. Registration is the first step; the rest is mailbox provisioning, captcha solving, proxy rotation, token renewal, trial expiry warnings, and error attribution when a run fails.

The target user is not someone signing up for a single ChatGPT account. It is a person or small team holding accounts across several AI services, where each service has its own signup form, its own verification mail, and its own token lifetime. The README lists ChatGPT, Cursor, Kiro, Trae.ai, Tavily, Grok, Blink, Cerebras, OpenBlockLabs and Windsurf, plus an "Anything" generic adapter for platforms not yet covered. Thirteen-plus is the number the repository description gives.

The honest scope statement is in the README itself: the project is for study and research, and the user is told to evaluate and comply with each target platform's terms of service. That sentence is doing real work. Automating signup on services that forbid it is a decision the tool does not make for you.

Protocol mode, browser mode, and the plugin boundary

The execution model is the most interesting design choice. Each platform can run in one of three modes: protocol, headless, or headed. Protocol mode drives the HTTP flow directly with no browser, which the README calls the fastest option. Headless and headed fall back to a real browser, and the README notes that mode availability depends on what each platform supports. That is a per-platform capability, not a global switch, so a run on one platform may be pure HTTP while another needs Chromium.

Everything around that core is plugin-shaped. Platforms, mailbox providers, captcha services, SMS receivers and proxy drivers are all described as hot-pluggable. The mailbox layer is the clearest example: nine channels are listed, including MoeMail, a self-hosted Cloudflare Worker, Laoudo, DuckMail, Testmail, Freemail, TempMail.lol, Temp-Mail Web and DuckDuckGo Email. The README states that mailbox, captcha and SMS configuration is driven by a backend provider catalog, and that the frontend renders each provider's form from that catalog rather than hardcoding options. Add a provider on the backend and it appears after a refresh.

Data flows through a FastAPI backend into a SQLite database, with the frontend fed by SSE for live registration logs. The README describes the log stream as covering OAuth code exchange, token acquisition, and quota lookup step by step, so a failure points at a specific stage rather than a generic error. The Dockerfile confirms the shape: a Node 20 build stage produces the frontend bundle, a Python 3.12 stage installs the backend and copies the built static files in.

Installing any-auto-register with Docker and running a first job

The README recommends the desktop build for most people: download the .dmg or .exe from Releases, launch it, enter an activation code obtained from the community group, pick a platform, configure a mailbox, and start. The activation code is a real gate, not a formality, and it is worth knowing before you commit.

If you would rather self-host, the README gives a docker-compose file. Create a directory, write the compose file, and bring it up:

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

docker compose up -d

After that, three services should be reachable. The Web UI is on port 8000, noVNC for the visual browser on 6080 at the /vnc.html path, and the Turnstile solver on 8889. On a cloud server you need to open all three.

The repository's own docker-compose.yml differs slightly from the README snippet: it uses build: . instead of a prebuilt image and sets the database URL explicitly. That is the file to use if you are building locally.

services:
  app:
    build: .
    ports:
      - "8000:8000"
      - "6080:6080"
      - "8889:8889"
    environment:
      - DISPLAY=:99
      - ACCOUNT_MANAGER_DATABASE_URL=sqlite:////app/data/account_manager.db
    volumes:
      - ./data:/app/data
    restart: unless-stopped

The volume matters: without ./data mounted, the SQLite file and everything you registered disappear when the container is recreated. Note also that APP_PASSWORD is commented out in both files. The Dockerfile sets it to an empty string by default, which the comments describe as no password protection, suitable for local use. If the UI is reachable from a network, set it.

Running from source is the third path. It needs Python 3.11 or newer and Node.js 18 or newer. The README's sequence creates a virtual environment, installs requirements, builds the frontend, and starts uvicorn on port 8000:

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 uvicorn main:app --port 8000

Browser modes need extra browser binaries, which the README installs separately:

python3 -m playwright install chromium
python3 -m camoufox fetch

The camoufox fetch is also what the local captcha solver needs, so skipping it removes the offline captcha option. The README is explicit that the source tree contains the core registration flows and the full provider system, while advanced task queue controls, activation code management, payment flow enhancements and the newest platform adaptations ship with the desktop build. That is a meaningful split: cloning the repository does not give you the same feature set as the installer.

Where any-auto-register breaks or is the wrong tool

The dependency list tells you what you are signing up for. playwright, camoufox and patchright are all present, which means browser automation is not an optional extra in the Docker image: the Dockerfile installs Chromium, Xvfb, x11vnc and noVNC so that headed mode can run inside a container. A protocol-only workflow still carries that weight.

Third-party captcha services are the practical bottleneck. YesCaptcha and 2Captcha both require paid keys from their own sites, and the local solver is a Camoufox-based fallback that the README presents as an alternative rather than a replacement. If a target platform changes its challenge, the run fails at that step, and the fix depends on whether the solver or the platform plugin gets updated.

Mailbox providers are the second dependency, and several are public temporary services. The README itself notes that DuckMail needs a proxy in some regions. Public temp-mail domains are also the kind of thing platforms block at signup, which is exactly the failure the error attribution is meant to surface: the README lists "mailbox domain anomaly" and "proxy flagged by risk control" as distinct categories. Those categories exist because they happen.

If you need one account on one platform, none of this is worth it. The setup cost, the captcha keys, the proxy pool and the mailbox configuration all assume volume. The same applies if you are unwilling to run proxies: residential proxy services are featured in the README, and running registrations from a single datacenter IP is the fastest route to the risk-control bucket the tool is built to avoid.

any-auto-register versus a plain Playwright script

The realistic alternative is a repository-specific Playwright or curl_cffi script, one per platform, with a small mailbox helper. That approach is transparent: you own every step, there is no provider catalog to learn, and nothing is gated behind an activation code.

The difference is everything after the first successful run. A hand-written script registers an account and stops. any-auto-register adds a scheduler for validity checks, automatic token renewal, trial expiry warnings, and a risk centre that groups expired tokens, near-exhausted trials and proxy connectivity problems. It also keeps a task queue with per-job logs and an SSE stream, and it exports accounts in several formats including JSON, CSV, CPA, Sub2API, Kiro-Go and an Any2API admin.json.

The most concrete difference is the Any2API handoff. The companion project at github.com/lxf746/any2api is an OpenAI-compatible gateway, and the README describes pushing newly registered accounts straight into it. A bespoke script would need that integration written and maintained by hand. The cost of the integrated path is coupling: your registration tool and your API gateway now share a data format, and the export format list shows how many consumers that format already serves.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-08-25, which is recent. The release history is more uneven: v1.0.23 is dated 2026-05-06, v1.0.22 the day before, and v1.0.20 on 2026-05-01. So the repository is being worked on between releases, and the release cadence in May does not match the push activity in August. The README also references screenshots from desktop version v1.0.29, which is a version number that does not appear in the release list given here. Treat the desktop build as the actively developed artifact and the tagged releases as a lagging signal.

The licence is AGPL-3.0. That is a strong copyleft licence with a network clause: if you run a modified version as a service that others interact with over a network, the source of your modifications is expected to be offered to those users. For internal, single-operator use this rarely matters. For anyone wrapping this in a hosted product, it matters a great deal. This is a description of the licence, not legal advice; read the LICENSE file and talk to someone qualified if the network clause applies to you.

The upgrade cost is concentrated in the provider layer. Because platforms, mailboxes, captcha services and proxies are all plugins, a platform changing its signup flow means updating one plugin rather than the core. That is the design paying off. The counterweight is the desktop-versus-source split: if you deploy from source, you are on a different feature track from desktop users, and the newest platform adaptations arrive on the desktop side first. Anyone self-hosting should decide early whether that lag is acceptable.

Editorial conclusion

Adopt it if you already operate several AI platform accounts and want the registration, mailbox, captcha and proxy plumbing in one place, and read the AGPL-3.0 terms before you ship anything derived from it. Skip it if you only need one account on one platform, or if you cannot supply your own mailboxes and proxies: the project assumes you have both. Verify first that the platform you care about is in the provider catalog, that your chosen mailbox provider still issues addresses, and that the desktop activation code path is something you can live with, because the source tree alone does not include the advanced queue and activation features.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. lxf746/any-auto-register on GitHub
3. Project website
4. README
5. Releases