Skip to content
Browserberg Browserberg

Persistent profiles: keep the logged-in state

Name a profileId and the browser state — cookies, storage, logged-in sessions — survives teardown and is restored into the next session that names it.

Last updated:

The logged-in state problem

Browsers are disposable here; the work you did in one is not. Signing in to a partner portal takes time, sometimes a one-time code, sometimes a colleague — repeating that at the top of every run is the biggest single waste in automation against authenticated sites.

A profile fixes it. Pass a profileId when creating a session; naming an id that does not exist yet creates the profile, quota-checked against your plan. When the session tears down, the browser state is captured; the next session naming the same id starts with that state restored.

A round trip through one profile

Requires: api-key 

import { Browserberg } from '@browserberg/sdk';

const bb = new Browserberg({
  apiKey: process.env.BROWSERBERG_API_KEY!,
  baseUrl: 'https://browserberg.com',
});

// Naming a profile that does not exist yet creates it: the browser state is
// captured when this session ends.
{
  await using first = await bb.sessions.create({
    profileId: 'docs-example-profile', ttlSeconds: 120,
  });
  await first.act({
    steps: [{
      encodedId: null, action: 'navigate', role: 'none',
      description: 'open example.com', value: 'https://example.com',
    }],
  });
}

// Give the capture a moment to land, then start a second session on the same
// profile: cookies, storage and logged-in sessions come back with it.
await new Promise((resolve) => setTimeout(resolve, 3000));

await using second = await bb.sessions.create({
  profileId: 'docs-example-profile', ttlSeconds: 120,
});
console.log('second session ready:', second.id.length > 0);
console.log('warm start:', second.warmStart);

What travels with a profile

A profile carries cookies, local storage and the logged-in sessions they represent. At rest it is encrypted with your tenant's key — the platform holds ciphertext, not a browsable copy of your portal logins.

The pattern that works in practice: use a vault credential for the first login, then run everything after it on the profile. The credential handles the sign-in once; the profile lets the next hundred runs skip it.