Skip to content

Account distribution

Distribution links your streaming machines (which consume accounts) to the centralized creator (which produces them for everyone), through the server. Everything is automatic — you install no creation machine.

Diagram of the automatic distribution of accounts between the centralized creator and streaming machines

The flow, step by step

1. Request (your streaming machine)

The streaming machine scans its proxies, computes the empty slots (capacity − assigned accounts) and declares its need to the server, bounded by your “Accounts to create per day” cap. On startup it does so immediately (after purging dead accounts to free up slots), then periodically. When a proxy is full or the cap is reached, the need drops to 0. Without a valid CapSolver key, the machine requests nothing.

2. Creation (centralized creator)

The creator (the operator’s dedicated machine, 24/7) retrieves the needs of all machines, creates each account through the exact proxy requested and with the client’s CapSolver key, tests it, then publishes it. It honours each machine’s own daily cap.

3. Handover (encryption)

The account is end-to-end encrypted for the destination machine, then sent to the server. The server only stores an encrypted blob: it cannot read the account.

4. Retrieval (streaming machine)

The streaming machine claims its accounts (periodically), decrypts them locally (only it can), persists them (credentials, session, proxy, warmup) and verifies the delivery through the proxy. It then re-declares its reduced need → creation stops on its own.

5. Use (no interruption)

The new account is taken into account immediately: the workers re-read the account pool on every cycle, so the account is used without restarting the current session. It starts in warmup.

Key guarantees

GuaranteeMechanism
No over-creationneed recomputed server-side + atomic quota reservation
Working accounts onlyaccount tested at creation and at delivery
ConfidentialityE2E encryption, only the recipient decrypts
No interruptionpool re-read on the fly, no restart
IP consistencycreation through the exact proxy requested