how to run multiple Mastodon accounts across instances
how to run multiple Mastodon accounts across instances
if you want to run multiple Mastodon accounts in 2026, the federation model changes the rules. unlike Twitter, Threads, or Bluesky, Mastodon is not a single platform; it is a network of thousands of independent servers that talk to each other via ActivityPub. each server has its own admin team, its own moderation rules, and its own block list. running multi-account on Mastodon means navigating that diversity rather than fighting one centralized anti-abuse system.
cloud phones help here for the same reasons they help on every other platform: real arm64 device fingerprint, clean install state, real Singapore mobile IP, and isolation per account. but the biggest constraint on Mastodon is not technical detection, it is human moderation. instance admins read user reports and act fast. mass-following, mass-DMing, or repetitive content gets your account suspended and sometimes gets the entire instance you registered on defederated by larger instances.
why Mastodon is different from centralized social
three differences shape multi-account strategy. first, federation. when your account on mastodon.social follows someone on mas.to, both servers exchange ActivityPub messages. behavior visible from mastodon.social is also visible to anyone polling the public ActivityPub stream. second, instance moderation. each instance has its own admin team that reads reports manually. there is no algorithmic black-box to game. third, defederation. if instance admins decide your home instance hosts too many bots, they block all federation with that instance, cutting your accounts off from the rest of the fediverse.
cloud phones address device-side fingerprinting and IP. they cannot fix bad behavior at the content layer.
the right setup: spread accounts across instances
the cardinal rule of Mastodon multi-account: do not put more than 1 or 2 accounts on the same instance. instance admins notice when 10 new accounts register from the same IP in the same hour, and they suspend the cluster.
per account, you need: one cloud phone in Singapore with a real Singapore mobile IP, one fresh email per account (use a different mailbox per persona), one target instance that fits the persona’s niche.
instance choices matter. mastodon.social is the default but heavily moderated. small niche instances (an art instance, a tech instance, a regional instance) have looser onboarding but harsher moderation if you misbehave. for a 20-account fleet, spread across 10 to 20 different instances.
if you need cloud phone basics, see how to share a cloud phone with your team and how to rotate mobile IP on a cloud phone.
step-by-step: registering a Mastodon account on a cloud phone
-
log in to cloudf.one. pick a phone that has not run Mastodon before. confirm the IP is a Singapore mobile carrier ASN via
ifconfig.me. -
open Google Play. install the official Mastodon app, or alternatively a third-party client like Tusky or Mona. the official app is the safest first install.
-
open the app. tap “get started” or “log in.” pick the instance for this account. enter the instance domain manually (e.g.
mstdn.social,infosec.exchange,tech.lgbt). -
tap “create account.” enter username, email, password. agree to the instance rules (read them, instance admins enforce them).
-
confirm the email. some instances require manual approval from an admin; this can take hours to days. plan accordingly.
-
set a profile photo, header image, bio, and pinned post. the bio is the first thing instance admins and other users see. write something specific to the persona.
-
follow 20 to 30 accounts on the local timeline of your instance and 20 to 30 on the federated timeline. let the algorithm-free home feed populate.
-
day 2: post your first toot. introduce yourself, mention the niche. use the
#introductionhashtag if your instance encourages it.
the federation timeline as a moderation surface
every instance shows three timelines: home (accounts you follow), local (everyone on your instance), federated (everyone your instance has seen). instance admins watch the local and federated timelines manually. spammy posts get reported within minutes.
if you mass-follow 200 accounts in your first hour, the instance moderator sees the activity in their admin dashboard and suspends you. follow at a human pace: 5 to 10 accounts per hour, with reading time in between.
why custom domains and self-hosting matter at scale
at small scale (under 20 accounts), spread across public instances. at larger scale, run your own Mastodon instance on a domain you control. self-hosted instances let you set your own moderation policy and avoid the risk of someone else suspending your accounts.
self-hosting comes with two costs: server operations and reputation. a brand-new instance has no federation reputation, so other instances may rate-limit or even silently drop your messages. a self-hosted instance becomes useful for multi-account work after 6 to 12 months of clean federation history.
scripting Mastodon: the API is open
Mastodon has a fully documented public API supported by every client. you can post, follow, boost, and read via REST. like Bluesky, this cuts both ways: instance admins can replay API calls and see exactly what your accounts are doing.
if you automate, two rules. first, do not exceed the per-instance rate limit (300 requests per 5 minutes per token by default). second, never use the API to mass-follow or mass-DM. those are the patterns admins look for.
UI-driven automation via ADB on a cloud phone is safer for multi-account workflows. our guide on how to set up ADB on cloudf.one covers the connection setup.
# example: open Mastodon app and tap compose via ADB
adb -s 192.168.x.x:5555 shell am start -n org.joinmastodon.android/.MainActivity
sleep 3
adb -s 192.168.x.x:5555 shell input tap 950 1900 # compose fab
sleep 1
adb -s 192.168.x.x:5555 shell input text "hello%sfediverse"
defederation: the worst-case outcome
if your home instance hosts too many spam or bot accounts, larger instances block all federation with it. your accounts can still post locally but cannot reach anyone on the major instances. for a marketing or outreach use case, defederation effectively ends the account.
prevention: spread your accounts across many instances, never bulk-register, behave like a normal user. if you self-host, invest in clean federation reputation before adding multi-account workflows.
scaling 5, 20, 100 Mastodon accounts across instances
5 accounts on 5 different instances: manage by hand. 20 accounts on 10 instances: spreadsheet with phone ID, instance, username, niche, last-post date. 100 accounts: orchestrator that picks a phone, runs ADB taps to post or boost, polls the home timeline for new replies.
the unique constraint: instance diversity. running 100 accounts on mastodon.social is impossible (admins will notice and suspend). running 100 accounts spread across 50 to 100 instances is feasible if you respect each instance’s rules.
if you want context on detection mechanics, our post on mobile fingerprinting techniques explained covers what most apps see when they build a device profile.
try Mastodon multi-account on real Singapore phones
you can register for a free trial and confirm a Mastodon registration end to end on a real Singapore cloud phone. once you confirm one instance accepts the account, scale to a paid plan and spread future accounts across other instances at sustainable cadence.
frequently asked questions
can I have multiple Mastodon accounts on one instance?
most instances allow it but limit to 1 to 5 per IP per day. for serious multi-account, spread across instances rather than concentrating on one.
will instance admins ban me for using a cloud phone?
no, real cloud phones look like normal Android handsets. admins ban for behavior (spam, mass-follow, repetitive content), not device type. emulators sometimes get caught because they fail Play Integrity, but cloud phones pass.
what happens if an instance defederates from another?
users on each side stop seeing posts from the other. existing follows break. defederation is the harshest moderation outcome and is reversible only if both admins agree.
is the Mastodon API rate-limited per account or per IP?
per access token (which is per account). default is 300 requests per 5 minutes for authenticated calls. respect the rate limit; the API rate limit docs cover the specifics.
can I run a private Mastodon instance for my multi-account fleet?
yes, but expect a 6 to 12 month ramp-up before federation reputation is good enough that major instances do not silently drop your messages. self-hosting is a long-term investment, not a quick fix.