Dolphin Anty Cloud Profiles: How Sync, Storage and Team Access Actually Work

Most guides to Dolphin Anty cloud profiles stop at "your profiles are stored in the cloud so you can use them anywhere", which is true and almost useless. The interesting part is the mechanism underneath: when the data is written, what a second person sees, and which actions quietly depend on the cloud being switched on. Those three details decide whether a shared profile behaves the way a team expects, and they are the reason handovers go wrong.

Everything below is drawn from Dolphin's own help centre, checked on 29 August 2026, with the page linked at each claim. If you want the broader product picture instead of the mechanism, our review of Dolphin Cloud covers the plans and the profile model.

What a Cloud Profile Is Holding

A browser profile in this category is a container for an identity: the fingerprint configuration that makes a site see a distinct device, plus the cookies, local storage and session state that make it a returning device. Cloud synchronisation adds one thing to that — a copy of the container on Dolphin's servers, which is what allows the same profile to be opened from a second machine or handed to a colleague. (Dolphin help centre, Profile Cloud Sync.)

The toggle sits in two places. At creation time there is a "Synchronise to cloud" switch at the bottom of the creation window, so a profile you already know will stay on one machine can be created local from the start. For an existing profile, the same setting lives behind the three-dot menu, under "Cloud synchronization".

The One Fact Worth Knowing: It Writes on Close

This is the detail that explains most confused handovers.

Profile data syncs to the cloud at the moment the profile is closed. While a profile is running, everything it produces — new cookies, new tabs, cache — is held locally and has not reached the cloud yet. The documentation is direct about the consequence: leaving profiles open for days on end means the sync may simply never happen, and the next person to open that profile, on any machine, will not see the latest state.

The confirmation signal is specific too: the Stop button switching back to Start with a green check mark is what tells you the write completed. Not the window closing. Not the profile disappearing from the running list.

Three habits follow from this, and they cost nothing:

• Close and reopen long-lived profiles periodically, so progress is committed rather than accumulated locally.
• Wait for the green check before you tell a colleague the profile is theirs.
• Never open a profile on a second device until the first device has finished syncing it.

What a Second Person Actually Sees

Once you know the write happens on close, the answer becomes mechanical rather than mysterious: a second person sees the state of the last clean close, not the state of the session that is currently running somewhere else.

That makes cloud profiles sequential by nature. They are excellent at "you had it yesterday, I have it today" and structurally poor at "we are both in it right now", because there is no continuous merge — there is a snapshot, written at a moment you control. Teams that treat the profile like a shared document get surprised; teams that treat it like a physical key being handed across a desk do not.

Turning Sync Off: Three Conditions and Forty-Five Days

Disabling cloud sync is not a simple switch, and the guardrails around it are sensible once you see what they protect.

Three conditions have to be met first. The profile must have been launched at least once on that PC, so a local copy of the data exists — otherwise turning sync off would mean discarding the profile. The profile must be closed, because synchronisation cannot be managed while it is running. And if the profile is shared with another user, sharing must be stopped first.

Then the consequences, in the order they bite:

That last row is the one to write on a sticky note. Sync can be turned back on only from the machine holding the current local copy — not from a different device, and not from an admin account.

Team Access: Roles, and the Two Different Verbs

Dolphin's team model has three roles, and the differences between them are about scope, not about seniority. (Dolphin help centre, Teamwork.)

• Admin — full access to all features and all users: can see, edit and launch anyone's profiles, assign team leads, change roles and passwords, and create or delete users.
• Teamlead — manages only the users an admin assigned to them. Can see, launch and edit those users' profiles, but cannot change passwords, or create and delete users.
• User — creates, uses and deletes their own profiles, manages their own proxies, and can share profiles with teammates.

Then the two verbs that people mix up constantly, and that mean genuinely different things:

Share grants rights on a profile. Owner and colleague both work on it, the granted rights are visible under "Show accesses" on the profile, and they can be revoked later. This is collaboration.

Transfer hands the profile over. It disappears from the sender's list, the recipient must accept it — until then it shows as blocked for launching — and afterwards only the recipient sees it, although inside a team an admin or team lead can still surface it with a filter. This is a handover, and it is not reversible by the sender.

Transfers also depend on plans, in a matrix that is easy to hit by accident: paid to paid works, paid to free works, and anything originating from a free account does not. There is a whitelist and blacklist of trusted senders in settings, which is worth configuring before someone starts pushing profiles at your team rather than after.

Two more details in the same area. An admin can cap how many profiles an individual user is allowed to create. And when a user is deleted, an option called "Transfer profiles to my account" pulls their active profiles back to the admin, with the data as of the last synchronisation — local profiles are not transferred, which is the same close-and-sync rule reappearing at the worst possible moment.

Folders, Proxies and the Rest of the Sharing Surface

Sharing is not limited to single profiles. Folders can be shared with team members, either at creation time through a "Share folder" toggle or afterwards through the folder's edit window, with per-user access settings. Proxies have their own sharing path, either by enabling "Transfer with proxy" when a profile changes hands or by sharing the proxy directly from the Proxy section.

The reason to care: a profile handed over without its proxy is a profile that will look like a different device the next time it opens. The two things travel together in practice, so they should travel together in the gesture.

Profile Passwords

For an extra lock, a password can be set on an individual profile, restricting launching, editing, exporting and importing cookies or local storage, deletion, and other profile functions. It can be set by the profile owner or by an Admin, who can also manage passwords on other members' profiles. Minimum six characters; three wrong attempts in a row blocks that profile for an hour; a reset sends a confirmation code by email. (Dolphin help centre, Profile Password.)

For a team, this is the difference between "everyone can open everything" and "the account with the spend on it needs a second key" — the same instinct behind not sharing passwords across an ad ops team.

The Synchroniser, Which Is a Different Feature

Worth separating, because the names collide. Cloud synchronisation is about storage. The profile synchroniser is about input: you pick a master profile, and the actions you perform in it are repeated across the other selected profiles. (Dolphin help centre, Profile synchronizer.)

It is available from the Starter plan upwards on macOS, Windows and Linux, and it comes with real constraints that are easy to trip over: it is sensitive to differences in window size, and if the number of tabs or extensions differs between profiles it will not behave correctly, because what is duplicated is the click position, not the target element. The documentation's own advice is to use copies of a profile so the layouts are identical while cookies and fingerprints differ.

The Free Plan and the Cloud

One boundary that surprises people: on the Free plan, cloud synchronisation is not available. Profiles opened on a second device come up empty rather than carrying their data across, and the profile synchroniser is not part of that plan either. (Dolphin help centre, Restrictions on working with profiles.)

It is a plan boundary rather than a limitation of the technology, but it changes how a free profile should be treated: as a single-machine object, with everything in this article about handover and second devices simply not applying.

Handing Accounts Over to Dolphin Cloud

The two Dolphin products connect, and the mechanism is specific. Profiles created with the "FB" type automatically carry an extension that moves Facebook accounts from Dolphin Anty into Dolphin Cloud. You take an access token from the Dolphin Cloud settings, paste it once into the "Integration with Dolphin" block in Dolphin Anty's own settings, and from then on the token is filled into the extension inside every Facebook-type profile. (Dolphin help centre, Integration with Dolphin Cloud.)

From there there are two routes. In bulk: select the profiles, then "More" and "Transfer to Dolphin{cloud}" from the actions bar — the profile needs to contain cookies and a proxy first. Or one at a time: open the profile, go to Ads Manager, click the extension icon, and fill in the name, user agent, proxy, tags and whether cookies come along.

This is also the clearest illustration of what the layer is for. Everything in that flow is about getting an account into a place where work can happen. None of it is the work itself.

Where This Layer Stops

That boundary is not a criticism — it is the design. A profile knows which device it looks like and which session it holds. It does not know what a campaign spent yesterday on another network, what a tracker recorded as revenue, or whether an ad set is under break-even once refunds and cost of goods come out. Those answers live on the ad platforms' APIs, and they are a separate trade with separate tooling. If you want that argument in full, it is in what the browser layer solves and what stays open, and the practical version — running both without moving anything — is in how the two fit together.

Wevion is an ad operations platform that connects Meta, Google, TikTok, Taboola, Snapchat and Outbrain through their official APIs with OAuth, syncing insights roughly every fifteen minutes, so bulk launch, rules, budget allocation and contribution margin all sit in one panel instead of six.

Key Takeaways

• Cloud profiles write on close, not continuously. The green check on the Stop button is the confirmation, and a profile left open for days may never sync.
• A second device sees the last clean close. Treat profiles as sequential handovers, never as a shared live document.
• Disabling sync requires the profile to have been launched on that PC, to be closed and to be unshared; the cloud copy goes immediately or after 45 days, and only that same PC can turn sync back on.
• Share grants revocable rights; transfer hands the profile away and needs the recipient to accept. Deleting a user recovers their cloud profiles but not their local ones.
• The Free plan has no cloud synchronisation and no profile synchroniser, so everything about handover applies only from a paid plan upward.

If the profile side of your setup is solved and the campaign side is not, start on the free plan and connect a single ad account — the browser layer stays exactly as it is.