Multilogin alternatives when the profile is not the unit of work

Where Multilogin is still the right answer

This is the part most "alternatives" pages skip. Multilogin is a profile manager, and for a large amount of real work that is exactly the correct shape — Wayfern would be a downgrade.

Two different units of identity

A Wayfern identity lives exactly as long as you hold the socket: you connect, you get a browser in a pooled container, and when the connection drops the container goes back to the pool.

Multilogin inverts that. The profile is the durable object and the browser run is the disposable one — you launch profile 47, it comes back with the cookies, local storage and fingerprint it had last week, and closing it saves that state rather than discarding it. That is why it can support the workflows it does, and why it charges by how many identities you keep.

Wayfern has no such object anywhere in its public surface. The gateway proxies raw Chrome DevTools Protocol from your client into a browser container; the pool only ever reuses a container for connections carrying the same link token and the same exit, never across links, and the reaper terminates it once it has been idle (five minutes by default). State can survive inside a container while it stays warm, but there is nowhere to save it, name it, export it or deliberately re-open it. If your workflow depends on that, this is a real loss and not a framing difference.

The platform does contain a durable-profile fleet — long-lived Windows and macOS browser sessions on leased hardware, addressed by profile id. It is deliberately not part of the product an ordinary Wayfern account can reach: the controller is guarded to service accounts and returns 404 to everybody else, at every plan tier. Read the capability table below as describing what a normal customer can actually buy.

Line by line, including the lines we lose

Competitor cells are drawn from Multilogin’s own documentation and pricing page, cited underneath. Where the published material does not settle a question, the cell says so rather than guessing.

Proxy traffic: an included allowance versus a live meter

Wayfern routes datacenter egress for free and only escalates to a residential exit when you ask for one or when a page is classified as blocked, metering the bytes as they move.

Multilogin bundles proxy bandwidth into the plan: 1 GB a month on Pro 10, 3 GB on Pro 50, 5 GB on Pro 100 and 10 GB on Business, with a traffic saver to stretch it. That is the right model for account work, where the traffic is a person clicking through a handful of sites and the allowance is effectively invisible.

Wayfern meters instead of allocating, because a scraping run’s bandwidth is not predictable enough to bundle. Datacenter egress costs nothing and is not counted. A residential exit is billed per byte at 320 credits per GB: a sidecar in the container counts real rx+tx, the manager samples it every five seconds, debits the elapsed bytes, and terminates the session when the account can no longer pay. A session that cannot be metered is refused outright rather than allowed to stream unbilled.

The practical consequence is that a heavy month costs more on Wayfern than a plan allowance would, and a light month costs nothing at all. Neither model is more honest than the other; they are sized for different traffic shapes.

You are buying identities, or you are buying browser time

The two price lists do not convert into one another, so comparing headline numbers is meaningless. Compare the units.

Multilogin prices the identity. Pro tiers are a profile count with a seat count and a bandwidth allowance attached — 10 profiles / 1 seat, 50 profiles / 2 seats, 100 profiles / 5 seats — and Business is a slider from 300 to 10,000 profiles with unlimited seats. On monthly billing the Pro tiers run $11, $29 and $40 a month and Business runs $89 a month at 300 profiles to $900 at 10,000; annual billing advertises 35% off, with the Pro tiers at $85, $230 and $320 a year and the Business slider’s own figures running $685 to $6,885 a year. What you never pay for is usage: a profile you open every day and a profile you open once cost the same.

Wayfern has no profile line item at all. A plan buys a monthly credit grant, a concurrency ceiling and seats — Developer at $19/mo grants 1,520 credits, 20 concurrent pages and 1 seat; Business at $99/mo grants 9,000 credits, 100 concurrent pages and 10 seats; Scale at $499/mo grants 46,000 credits, 400 concurrent pages and 50 seats. Everything then burns from that one balance: 8 credits per open-page hour, prorated per second with a 60-second floor on each page, 320 credits per GB of residential egress, and a scrape at 1 credit per page. Credit packs are one-time and roll over; plan grants do not.

So the question that decides it is not "which is cheaper" but "what does my cost scale with". If it scales with how many accounts you hold, Multilogin’s unit matches your bill and Wayfern’s does not. If it scales with how many pages you open, the reverse is true — and a Multilogin plan large enough to hold the identities is beside the point, because the bandwidth allowance runs out first.

Porting a Playwright script off the launcher

On Multilogin the script talks to the launcher, not to the browser: you start a profile through the launcher endpoint and attach a remote driver to what it returns. The documentation is explicit that this must be a remote WebDriver — a local one breaks automation — so the profile id and the launcher are load-bearing parts of every script.

On Wayfern there is no launcher and no profile id. You point a CDP client at the gateway and the link token in the query string is the whole credential; exit geo is set on the same URL. Link tokens are named, revocable, can carry an expiry, and each one has its own concurrency cap between 1 and 100, so a runaway job is bounded by the credential rather than by the plan.

The part that does not port is state. There is no equivalent of re-opening profile 47 tomorrow with its cookies intact, so anything that depended on that has to be rebuilt around storage you own — inject cookies at the start of a run and read them back before you disconnect, or keep the workload stateless.

// Multilogin: start the profile through the launcher, then attach a REMOTE
// driver to what it hands back. A local WebDriver will break automation.
//
//   GET …/start?automation_type=puppeteer&headless_mode=true

// Wayfern: no launcher, no profile id. Connect straight to the gateway.
import { chromium } from 'playwright';

const url = new URL('/ws', process.env.WAYFERN_GATEWAY); // wss://…
url.searchParams.set('token', process.env.WAYFERN_LINK_TOKEN);

// Optional: pick the residential exit. Omit these and you egress datacenter,
// which is free and unmetered.
url.searchParams.set('country', 'de');
url.searchParams.set('city', 'berlin');
url.searchParams.set('session', 'run-42'); // sticky exit for this run

const browser = await chromium.connectOverCDP(url.toString());
const context = browser.contexts()[0];

// State you care about is yours to carry — nothing is saved for you.
await context.addCookies(JSON.parse(await fs.readFile('session.json', 'utf8')));

const page = await context.newPage();
await page.goto('https://example.com');

await fs.writeFile('session.json', JSON.stringify(await context.cookies()));
await browser.close(); // container returns to the pool; billing stops

Questions worth asking before you switch