Account pools: phones that take turns with your accounts

What a resource pool is

A pool is a named set of accounts for one app — say Facebook VN, holding a hundred Facebook logins. It lives on WarpX Phone’s Resources page. Each account in it carries three things the farm would otherwise lose track of: the device it is always shown as (a model and name of its own, down to its advertising ID), the proxy it always goes out through, and a snapshot of its apps as they were when it was last put away — signed in, with its data.

An account is only ever on one phone at a time. While a phone holds it, it is leased, and no other phone can take it; the lease runs out on its own, so an account whose run died is free again without anyone freeing it. That one rule is what makes a pool safe to point a whole shelf of phones at.

Setting one up

On the Resources page, make a pool, name the app package it is for (the first one you list is the one opened after an account loads), and paste your accounts in — one per line, the first column the account’s label, the rest its fields, read the same way the profile Resources importer reads them. Passwords and tokens are sealed with the same key the rest of WarpX uses; the page shows them dotted out.

A few pool-wide choices decide how turns are handed out:

• Order — the account rested longest (the default), the next in sequence, or one at random.
• Rest after use and uses a day — keep an account off the phones for a while after its turn, and cap how many turns it gets in a day.
• Snapshots kept — how many backups to keep per account, so you can roll one back to before a bad run.

The two blocks: Load and Save

Everything else is two blocks in a workflow. Load resource opens an account’s turn: it takes the next free one from the pool you name, makes the running phone that account’s device, puts its proxy on, and restores its apps. It writes the account into a variable — resource unless you rename it — holding its label, its pool, the device it is shown as, every field you imported under its own name, and a state:

• loaded — its apps came back from a snapshot, already signed in. Get on with the work.
• new — it has never been used, so its apps are clean. Sign it in first, with the fields the variable holds.

Save resource closes the turn: it backs the apps up into a new snapshot and gives the account back to the pool, marked ready, or checkpoint, banned or disabled if the run found it in trouble. A banned account is kept out of the rotation but not deleted — you still have its snapshots.

A worked example: warming Facebook accounts

Say you want each account to be opened, scrolled for a minute and put away — the kind of light, regular use that keeps an account healthy. The whole workflow is six steps:

1. On Resources, make the pool Facebook VN with the app com.facebook.katana and paste your accounts in.
2. Load resource, with Resource pool set to Facebook VN. Leave the account empty so the pool picks the next one.
3. A Conditions block on {{variables.resource.state}}: when it is new, go to the blocks that type {{variables.resource.Username}} and {{variables.resource.Password}} into the login screen; otherwise skip straight past them, because a loaded account is already signed in.
4. The work itself — scroll the feed, tap a few posts, wait a little.
5. Save resource, status ready. The account’s apps are backed up and it goes back in the pool.
6. Run the workflow on every phone, on a schedule, and the phones work through the pool between them — each turn a different account, none of them twice at once.

The flow reads Load resource → Conditions → sign in (if new) → work → Save resource, and because the account lives in a variable, the same workflow drives any pool: point it at Telegram VN tomorrow and nothing else changes.

Why an account looks the same every time

An account that appears on a Pixel 8 on Monday and a Galaxy A54 on Tuesday is an account asking to be flagged. A pool account is made on its first load with a device of its own — one of WarpX Phone’s device presets, a name, an advertising ID — and keeps it on whichever phone loads it next. Same device, same proxy, same signed-in state restored from its snapshot. The phone changes under it; the account does not notice.

When a run stops on a block, its log names the account and the block, and the lease frees the account for the next phone. Nothing is stranded, and nothing you have to reconcile by hand on Monday morning.