Scalebrowser
Sign inDownload free

Migrate from GoLogin to Scalebrowser

Move from GoLogin: attach your Puppeteer or Playwright code to a profile on your own machine, create the profiles fresh, and store their logins again.

A typical GoLogin script starts a profile through GoLogin's SDK and then attaches Puppeteer or Playwright to the browser it gets back. The second half stays: a Scalebrowser profile hands out the same kind of DevTools address. The first half changes, and so does where the profile lives. Here it is on your own machine, created fresh, and its logins are made again.

Where the profile lives

GoLogin's SDK takes an API token, asks GoLogin's API for the profile's settings, downloads the profile's browser data as an archive, writes the fingerprint into the browser's preferences and starts their browser. After the run the data goes back up (read from their SDK source, July 2026).

A Scalebrowser profile lives on the machine that runs it. Its browser directory with the cookies and storage is on that disk, and the daemon draws its identity from a seed stored with it. There is no token to send and no archive to fetch before a start. Profile sync moves a profile to another of your machines, encrypted with a key our server never holds.

Start a profile and attach

Start the profile through the daemon and hand its cdp_ws to the code you already have:

ts
import puppeteer from 'puppeteer-core';
import { ScalebrowserClient } from '@scalebrowser/sdk';

const sb = new ScalebrowserClient({
  baseUrl: 'http://127.0.0.1:8787',
  token: process.env.SCALEBROWSER_TOKEN,
});
const profileId = 'prf_7d2a…';

const started = await sb.startProfile(profileId);
try {
  const browser = await puppeteer.connect({
    browserWSEndpoint: started.cdp_ws,
    defaultViewport: null,
  });
  const [page] = await browser.pages();
  await page.goto('https://example.com');
  // … your code, unchanged …
  await browser.disconnect();
} finally {
  await sb.stopProfile(profileId);
}

Three things to know against a browser the GoLogin SDK started:

  • There are no launch options. The profile already keeps its cookies and storage, and headless goes on the start call. Omit it and the start is headless.
  • Stop the profile through the daemon. Disconnecting leaves the browser running, and it keeps holding one of your plan's browsers until stopProfile or stop_profile.
  • The address is new at every start. Read cdp_ws from the start response each time.

Migrate from Playwright or Puppeteer covers the rest of an attached browser: the profile's own context, defaultViewport: null, and what to do for sites that grade input.

What carries over, and what does not

Your code after the connect carries over. The profiles and everything in them do not, because nothing is imported from GoLogin:

  • Profiles are created fresh. Make them one at a time in the app or with POST /v1/profiles, or many at once from a preset with POST /v1/bulk/profiles (Groups, presets & bulk).
  • Each new profile draws its own identity. There are no fingerprint settings to copy across: the identity comes from the profile's seed, and its GPU, screen, fonts and voices are your machine's own. See Profiles & personas.
  • The operating system is the machine's. GoLogin's API draws a fingerprint for Windows, macOS, Linux or Android on request (read from their SDK source, July 2026). Here a profile claims the operating system of the machine it runs on, which today is Windows, and a profile built for another system is refused at start with 4005. See Tier.
  • Cookies and logins start empty. Session import opens only a bundle that a Scalebrowser profile exported, and the credential bundle works the same way. Logins below is how a new profile gets signed in.
  • Proxies and extensions are added again. See Proxies below and Extensions.

Count your profiles before you recreate a large fleet. Your plan sets how many profiles you keep and, separately, how many browsers run at the same time. A batch that would pass the profile number creates nothing and answers 4014. See Plans & limits.

Logins

Two ways, and you can mix them per site:

  • Sign in by hand once. Start the profile with a window, sign in, and stop it. Cookies and storage stay in the profile's browser directory between starts.
  • Store the login in the profile's vault. With Add login on the profile's page in the app, with PUT /v1/profiles/:id/credentials/:platform, or from an agent with credential_store. An agent then signs in with credential_fill and never sees the password. Store the 2FA setup key beside it, and the daemon computes the six-digit codes itself. See Credentials & logins.

Proxies

Store each proxy once, as http, socks5 or a provider gateway, and assign it to the profile: in the app, with PATCH /v1/profiles/:id and a proxy_id, or for many profiles at once with POST /v1/bulk/assign-proxy. Under the default geo_mode, a profile takes its timezone and language from the country its proxy exits in.

One exit address belongs to one profile. A second profile that draws an address another profile owns is refused at start with 4013. A provider gateway gives every profile its own address from one account. See Proxies & exits.

Next