← back to blog

cloud phone bulk provisioning: 100+ devices in 2026

cloud phone bulk provisioning is the difference between launching a 100-account campaign in two hours versus two weeks. by 2026 most cloud phone vendors have a working API and a passable bulk import flow, but the patterns that actually work at scale are not always obvious from the marketing pages. this article walks through the bulk provisioning workflow on cloudf.one, the templating discipline that keeps fleets consistent, and the gotchas that show up around device 50.

if you are about to onboard a 100-device team, a 200-account warming campaign, or a multi-tenant agency rollout, the bulk provisioning layer is the operational decision that determines whether you ship on time.

the four inputs to bulk provisioning

every bulk provisioning job has four inputs. get these right and the rest is mechanical.

• device count and tier: how many devices, on what plan. mixing tiers in one bulk job is possible but adds complexity.
• device profile template: the locale, time zone, language, wallpaper, and system settings every device should match.
• app install list: the set of APKs or Play Store packages that should be installed on every device.
• account assignment plan: which device gets assigned to which user or team.

most teams underestimate the third and fourth. the first two are usually well-defined. the app install list and account assignment plan are where bulk jobs go off the rails because they involve credential management and human ownership decisions.

the admin walkthrough on cloudf.one

cloudf.one supports bulk provisioning through both the admin dashboard and the API. for jobs under 50 devices, the dashboard is faster. above that, the API is the right tool.

dashboard flow.

1. log in as admin owner, navigate to fleet → bulk provisioning. screenshot placeholder: [bulk provisioning page with template selector].
2. select a profile template. cloudf.one ships several defaults (Singapore Android, Indonesia TikTok, US generic) and supports custom templates.
3. set the device count. the dashboard caps at 50 per batch. larger batches need to be split or run via API.
4. choose the app install list. screenshot placeholder: [app install list multi-select with search].
5. assign accounts. the dashboard supports CSV upload with one row per device, mapping device label to user email and any custom metadata.
6. click provision. devices come online over the next 5 to 15 minutes depending on batch size.

the API flow is the same primitives wrapped in a script. for a 100+ device batch, the typical pattern is.

curl -X POST https://cloudf.one/api/v1/fleet/bulk-provision \
  -H "Authorization: Bearer $TOKEN" \
  -d @bulk-job.json

where bulk-job.json contains the template ID, count, app list, and assignment array.

the device profile template

the template is the single source of truth for device consistency. without it, devices drift from each other within days as different users tweak settings.

a good template specifies.

• system locale and language (e.g. id-ID, th-TH, en-US).
• time zone (e.g. Asia/Bangkok).
• screen lock policy (none for headless, PIN for shared).
• wallpaper and home screen layout (consistent for visual confirmation that the device is “on template”).
• preinstalled apps with version locks where possible.
• system settings that affect detection (developer mode off, USB debugging off, Play Protect on or off depending on use case).

cloudf.one stores templates in the admin workspace and supports versioning. when a template is updated, existing devices on that template can be re-applied via a fleet-wide action. screenshot placeholder: [template versioning panel with diff view].

the app install list

the app install list is the second most important consistency layer. drift here causes the most user-visible incidents.

best practices.

• pin to specific app versions where the app supports it. unpinned apps drift as Play Store auto-updates.
• avoid sideloaded APKs unless the use case requires it. sideloaded apps trip Play Protect and account-level fraud detection more aggressively than Play Store installs.
• group apps into purpose-driven bundles (e.g. “TikTok bundle”, “WhatsApp bundle”, “banking-test bundle”). devices get the bundles their workflow requires, no more.
• track which apps are required vs optional. required apps block device handoff if missing. optional apps are nice-to-have.

cloud phone team seat management in 2026 covers the human-side of assignment. bulk provisioning hands off devices to seats; seat management governs what users can do with them.

the assignment plan

assignment is where bulk provisioning meets organizational reality. who owns each device, who can access it, what happens when the assigned user leaves the team.

a clean assignment CSV looks like.

device_label,assigned_user,team,project,initial_owner_until
tiktok-id-001,maria@agency.com,growth,id-launch,2026-08-31
tiktok-id-002,maria@agency.com,growth,id-launch,2026-08-31
whatsapp-th-001,jane@agency.com,support,th-support,

the empty initial_owner_until field means permanent ownership. dated fields trigger automatic reassignment after the date, which is useful for project-based teams.

what breaks at scale

the gotchas that show up around device 50, 100, 200.

• API rate limits: most vendors throttle bulk operations. cloudf.one limits bulk provisioning to 20 concurrent provisions and 200 per hour. plan accordingly.
• IP pool exhaustion: each cloud phone needs a unique mobile IP. for region-specific campaigns (Indonesia, Thailand) the IP pool is finite. confirm IP availability before committing to a 100-device order.
• license bottlenecks: some apps (banking, fintech) have device-level license caps. installing the same banking app on 100 devices may exceed the vendor’s per-account install limit.
• Play Store throttling: bulk Play Store installs from the same Google account get throttled or blocked. use one Google account per 5 to 10 devices, not one Google account per fleet.

cloud phone API basics: getting started in 2026 is the deeper reference on the API itself. bulk provisioning is one of the most common API workflows.

post-provisioning verification

after a bulk job, verify the fleet matches expectations before handing off.

the standard checks.

• device count matches the order.
• every device is reachable (no provisioning failures).
• every device has the template applied (locale, time zone, wallpaper).
• every device has the required apps installed.
• every device has the correct assigned user.

cloudf.one ships a post-provisioning verification report that runs all of these automatically and flags any drift. for teams without a verification report, the equivalent is a 30-line script that hits the device list API and asserts each property.

cloud phone audit-log review for admins 2026 covers the audit trail that should accompany every bulk job. the Google Cloud bulk provisioning whitepaper is a useful adjacent reference on bulk identity provisioning principles.

try cloudf.one bulk provisioning

if you have a launch coming up that needs more than 10 cloud phones provisioned consistently, the bulk provisioning flow on cloudf.one ships templates, CSV import, and API-driven workflows out of the box.

start the free trial →

frequently asked questions

what is the maximum batch size for bulk provisioning?

on cloudf.one, the dashboard supports 50 per batch and the API supports 200 per hour. larger jobs split across multiple batches.

how long does it take to provision 100 devices?

with the API and a clean template, around 30 to 45 minutes end to end. dashboard-driven 100-device jobs take longer because of the 50-per-batch cap.

can I mix device tiers in one bulk job?

yes on cloudf.one. the bulk job CSV can specify per-row tier. but most teams find it cleaner to run one batch per tier for simpler accounting.

what happens if a single device fails to provision?

cloudf.one logs the failure in the bulk job report and continues with the rest. failed devices can be retried individually after the batch completes. the report shows the specific failure reason.

should I use one Google account for all Play Store installs?

no. one Google account per 5 to 10 devices is the safer pattern. bulk installs from a single Google account get throttled or temporarily blocked.