Cloud Antidetect Browsers: Hosted vs Local, Compared

Three different things get marketed with the same word. Sorting them out takes about two minutes and changes the entire evaluation.

Cloud profile storage (sync)

Your encrypted profile blob (cookies, localStorage, fingerprint config, proxy assignment) lives on the vendor's servers. The Chromium build downloads it, runs on your laptop, and pushes the delta back on close. Multilogin, Octo Browser, Dolphin Anty, GoLogin and Incogniton all offer some version of this, and several make it the default. Detection-wise nothing has changed: your CPU renders the canvas, your NIC opens the socket, your proxy carries the traffic.

Remote browser execution (hosted)

The Chromium process runs on the vendor's infrastructure. You either watch a streamed video of it in a tab, or you attach automation to a remote DevTools endpoint. Your keystrokes travel to their host, and their host talks to the target site. This is what people usually mean when they search for a cloud antidetect browser, and it is the model with real consequences.

Cloud phone and hosted Android

A separate product line (AdsPower sells one) running Android instances rather than Chromium. Same trust model as hosted execution, different fingerprint surface. Out of scope here, though the exit IP argument in the next sections applies identically.

Ask the vendor one question to classify their product: when a profile is running, does traffic leave my IP or yours? Support answers this immediately. Marketing pages rarely do.

If you are still deciding whether you need any antidetect tooling at all, that question comes first and is answered separately in antidetect browser vs proxies. Plenty of work labelled "needs an antidetect browser" needs clean IPs and nothing more. For product-by-product coverage of the category, see the top 12 antidetect browsers.

This is the part vendor comparison pages skip, and it is the strongest argument against hosted execution.

An antidetect browser spoofs the reported values of fingerprint APIs. It cannot spoof the physics underneath. When Chromium runs on your laptop, a canvas readback is produced by your GPU, your graphics driver and your installed font set. When it runs on a GPU-less cloud VM, the same readback comes out of a software rasterizer.

The signal-by-signal split

Run this in the devtools console of a hosted profile, then in a local one with the same profile config, and compare:

// Same profile config, two execution models. These values should NOT differ.
const gl = document.createElement('canvas').getContext('webgl');
const dbg = gl.getExtension('WEBGL_debug_renderer_info');
console.log({
  renderer: gl.getParameter(dbg.UNMASKED_RENDERER_WEBGL),
  vendor:   gl.getParameter(dbg.UNMASKED_VENDOR_WEBGL),
  cores:    navigator.hardwareConcurrency,
  memory:   navigator.deviceMemory,
  screen:   [screen.width, screen.height, screen.colorDepth],
  tz:       Intl.DateTimeFormat().resolvedOptions().timeZone,
});

On a headless server without a GPU you will see renderer strings in the family of ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero)), SwiftShader driver) or Mesa/X.org, llvmpipe (LLVM 15.0.7, 256 bits). Chromium ships SwiftShader precisely so pages render without hardware acceleration, which is useful for the vendor and terrible for you, because those strings appear on almost no consumer device.

A good hosted product overwrites the string. That helps against naive checks and not against serious ones, because browser fingerprinting scripts hash the actual pixel output of a canvas draw, per the HTMLCanvasElement.toDataURL behaviour, and software rasterization produces different pixels from any real GPU. Spoofing the label while the pixels come from llvmpipe is an internal contradiction, and contradictions are more identifiable than either honest answer.

Fleet correlation: the failure nobody advertises

Here is the compounding problem. A hosted vendor runs a small number of VM images across a small number of subnets. Every customer of that vendor therefore produces canvas hashes, audio hashes, core counts and memory values drawn from a very short list, exiting through a narrow IP range. A platform that fingerprints once can cluster that vendor's entire user base, and one abuse report on one account hands them a filter for all of it.

Local installs do not cluster like that. Not because the software is better, but because consumer hardware is genuinely heterogeneous: thousands of GPU, driver and font combinations sitting behind thousands of residential networks. That variance is the actual product you give up when you move execution to someone else's rack.

Two more layers move with the process. WebRTC leaks in a hosted browser expose the vendor's host addresses rather than yours, which sounds like an improvement and is really just a different correlation key. And TLS fingerprinting reads the ClientHello of the vendor's Chromium build, so if their fleet lags a few Chrome releases behind stable, every profile you run advertises a JA4 hash that disagrees with the User-Agent it claims. Check the vendor's Chromium version against the current stable channel before you commit.

A hosted antidetect browser has to reach the internet from somewhere, and that somewhere is a rack at AWS, GCP, Hetzner, OVH or a similar provider. Its default egress is a datacenter IP registered to a hosting ASN. Anti-fraud vendors buy and maintain exactly those ASN lists.

So the marketing claim inverts under inspection. An antidetect browser with a pristine spoofed fingerprint, exiting from a well-known hosting range, is a worse starting position than plain Chrome on a home connection. The fingerprint layer got stronger and the network layer got much weaker.

Check it before you trust anything. Open a profile with no proxy attached and hit an echo endpoint:

# From inside the hosted profile, or through its automation endpoint
curl -s https://www.sparkproxy.io/ip

Then look the address up. If the ASN belongs to a hosting provider, every session you run without your own proxy is announcing that. This is why bring-your-own-proxy is still the norm in this category, and why serious hosted vendors expose a per-profile proxy field instead of selling you their egress.

SparkProxy runs datacenter proxies on a single host, gateway.sparkproxy.io, with three ports:

# Rotating exit
curl -s --proxy http://USER:PASS@gateway.sparkproxy.io:11000 https://www.sparkproxy.io/ip

# Sticky exit, session label carried in the username
curl -s --proxy http://USER-session-acct42:PASS@gateway.sparkproxy.io:11002 https://www.sparkproxy.io/ip

# SOCKS5, resolving DNS at the exit rather than on the host
curl -s --proxy socks5h://USER:PASS@gateway.sparkproxy.io:13000 https://www.sparkproxy.io/ip

Use socks5h, not socks5. The h moves name resolution to the exit. A large share of "my proxy leaked" reports are really DNS resolving on the machine running the browser, which in the hosted model means the vendor's resolver in the vendor's region, contradicting whatever country your proxy exit claims.

One honest note about our own product: these are datacenter IPs. For a cloud profile that has to look like a person's home connection on a platform that scores ASN type, a residential or ISP exit is the right call and we will say so. Datacenter exits are the right call for the large volume of work where the target scores rate and reputation rather than connection class, and they cost far less per identity.

Rotating proxies and persistent identities are incompatible, and the hosted model sharpens the conflict.

A profile that is logged into an account is a stateful thing. The platform holds a session cookie, a device record, and a history of which IPs that device used. Change the exit IP mid-session and you produce the textbook account-takeover signal: same cookie, new network, no re-authentication. Platforms answer that with a challenge, and challenges on a farmed account are how profiles die.

Local browsers hold one long-lived process, so a rotating gateway may hand out one IP and keep it for the life of the connection pool almost by accident. Hosted browsers break that assumption. The profile is suspended and resumed, the VM is rescheduled, the connection pool is rebuilt, and every rebuild opens a fresh TCP connection to the gateway. On port 11000 each of those gets a new exit. On port 11002, with a session label in the username, they all land on the same one:

# One label per identity. Same label, same exit, across suspends and resumes.
http://USER-session-acct42:PASS@gateway.sparkproxy.io:11002
http://USER-session-acct43:PASS@gateway.sparkproxy.io:11002

Map one session label to one profile, and never reuse a label across identities, because two accounts sharing an exit IP is the cheapest link a platform can draw. Session lifetime, rotation triggers and what happens when an exit disappears are covered in what is a sticky session proxy.

Set the profile timezone, locale and Accept-Language from the proxy exit's geography, never from the vendor host's. In hosted execution the operating system underneath is theirs, so any value your profile does not explicitly pin defaults to their region. A profile exiting in Chicago with a Frankfurt system timezone is a contradiction that costs nothing to avoid and plenty to leave in place.

Both cloud models put your session cookies on someone else's disk. Only one puts them in someone else's RAM while you are typing.

What each model exposes

"Is it encrypted?" is the wrong question, because everything is encrypted and the answer is always yes. The question is key custody. If the vendor can decrypt your profile without a secret only you hold, encryption protects you against their disks being stolen and against nothing else. If they use client-side encryption with a passphrase they never receive, a support engineer cannot open your session, and neither can anyone who compromises their infrastructure.

Ask these six before you move a revenue-bearing account:

1. Is profile encryption client-side, and who holds the key?
2. What is the data residency of the execution hosts, and can you pin a region?
3. Which subprocessors touch the traffic, and is there a signed processor agreement under GDPR Article 28 if any session carries EU personal data?
4. How long are profile snapshots retained after deletion, and is deletion verifiable?
5. Under what internal process can staff attach to a running profile, and is that logged somewhere you can read?
6. Has there been a breach, and what did the disclosure look like?

A vendor that answers all six in writing is a reasonable counterparty. A vendor that answers "your data is encrypted with AES-256" and stops has told you nothing.

The clean rule: hosted execution is fine for accounts you could afford to lose and rebuild. It is the wrong architecture for the one account that carries the business, however good the vendor is, because you have moved a single point of failure outside your control in exchange for convenience.

This is where cloud genuinely wins, and it is worth being precise about why.

Handing a browser identity from one operator to another on local-only tooling means exporting a profile and importing it elsewhere, which is the most dangerous routine operation in multi-account work. Cookie jars go stale in transit, localStorage gets dropped by lossy export formats, the receiving machine has a different font stack and GPU so the canvas hash shifts, and the new operator sits on a different network. You changed hardware, network and possibly timezone in one step, on an account that has been stable for months. Platforms notice.

If your operation is one person on one workstation, this advantage is worth nothing to you and you should ignore it. If you have three operators covering different hours on the same set of accounts, it is the whole reason to pay. Most vendors also gate seats and simultaneous profile launches separately, so read the concurrency row of the pricing table rather than the profile-count row, since concurrency is the limit teams actually hit. That pattern shows up clearly in head-to-heads like Multilogin vs GoLogin.

Antidetect pricing has four axes, and moving to the cloud adds the fourth.

Runtime is the line that changes the arithmetic, because it is the only one that scales with how much work you actually do. Work an example. Twenty identities, six hours of genuine activity each per working day, 22 working days a month: that is 2,640 profile-hours. At an illustrative $0.10 per profile-hour you are at $264 in runtime alone, before seats, profiles, proxies or bandwidth. Double the activity and the local cost stays flat while that line doubles.

On the local side those 2,640 hours cost you electricity and RAM. Twenty concurrent Chromium profiles is roughly a 32 GB workstation, a one-time purchase you have probably already amortised. The crossover therefore sits at low utilisation: cloud runtime is cheaper when profiles idle most of the month, and gets steadily worse as usage rises. Hosted execution is priced for bursty, occasional, geographically spread work. It is priced badly for a team running the same twenty accounts all day.

Three lines nobody puts in the comparison table:

• Proxies per identity. Independent of model. Twenty identities need twenty sticky exits, and a sticky exit shared between two accounts is not really two identities.
• Bandwidth on streamed variants. Watching a remote browser is video. That is metered egress at the vendor and a real cost on the operator's connection.
• Warmup time. A new profile is not yet a usable identity. Whatever you paid for the profile slot, the expensive part is the operator hours spent making it look lived-in, and that cost is identical in both models.

Hosted execution inserts a hop. Your input reaches the vendor host, the vendor host reaches your proxy, the proxy reaches the target. Two things follow.

For manual work, what you feel is the round trip to the vendor host, delivered as a streamed UI, so it behaves like remote desktop rather than a browser. Fine for checking a dashboard. Unpleasant for eight hours of form filling. Pick a vendor region near your operators, not near your proxy exits.

For automation, the streaming is irrelevant and the picture is better. Most hosted products expose the Chrome DevTools Protocol per running profile, usually through a local agent that tunnels to the remote instance, so your script connects to a localhost websocket and does not care where Chromium lives:

from playwright.sync_api import sync_playwright

# The local agent returns a ws:// endpoint even when the profile runs remotely.
with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp("ws://127.0.0.1:35000/devtools/browser/<id>")
    ctx = browser.contexts[0]
    page = ctx.pages[0] if ctx.pages else ctx.new_page()
    page.goto("https://www.sparkproxy.io/ip", wait_until="domcontentloaded")
    print(page.inner_text("body"))

connect_over_cdp attaches to the vendor's already-configured profile, which matters: launching your own Chromium instead throws away the fingerprint configuration you are paying for. The CDP surface is itself detectable and some anti-bot stacks look for it, which is covered in headless browser detection.

There is a third option that people shopping this category skip. If the work involves no login, no persistent identity and no account, you do not need a browser profile at all. A scraping API renders the page and returns content, and you can still pin your own sticky exit through it:

import requests

r = requests.get(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY"},
    params={
        "url": "https://example.com/pricing",
        "render_js": "true",
        "stealth": "true",
        "own_proxy": "http://USER-session-de1:PASS@gateway.sparkproxy.io:11002",
        "format": "md",
        "tag": "pricing-watch",
    },
)
print(r.text)

The own_proxy parameter accepts ip:port, ip:port:user:pass, http://user:pass@host:port and socks5://host:port, so the same sticky label you assign to a profile works here unchanged. That path costs a fraction of any antidetect subscription, and a meaningful share of people searching for cloud antidetect browsers are trying to solve a data-collection problem with an identity-management tool.

Hosted execution makes the vendor's uptime your uptime, with no degraded mode. Their control plane goes down and you cannot open a profile, answer a message or fulfil an order. Local execution with cloud sync fails softer, since many clients cache the last known profile and open it offline, but plenty still hard-fail on a licence check. Test that deliberately: pull your network, try to launch, and find out before it matters.

Test the export path while you are still a happy customer. A proprietary blob that only the vendor's client can open is not a backup, it is a hostage. What you want is cookies in a documented format, localStorage and IndexedDB contents, and the fingerprint parameters as readable configuration. What you frequently get is a signed archive and a support ticket.

Migration carries the risk from the handoff section: moving an identity to a new vendor changes the hardware fingerprint underneath it, because you are moving from one VM image to another. Migrate a few low-value profiles first, watch for challenges over two weeks, then move the rest.

The pattern is simple. Cloud sync is close to a free upgrade and you should take it if your vendor offers client-side encryption. Hosted execution is a real architectural trade, buying operational reach with fingerprint quality, cost predictability and control. Buy it deliberately, for the cases in rows three and four, and always with your own proxy attached.