Browser Automation for n8n: Nodes, Browserless, and More

The core conclusion first: n8n has no browser of its own, so every workflow borrows one, and the four borrowing options split on two axes: monthly cost and whether your logged-in sessions come along. Scheduled public scraping at scale points at hosted Browserless or self-hosted community nodes; budget-sensitive work behind your own logins points at a local browser through Execute Command.

That local route runs on ego (lite), an agent browser for browser automation: a free browser where every site you've signed into stays signed in, driven through the ego-browser skill from n8n's Execute Command node, with the work happening in an isolated Space. It's the only route on the list where your logged-in sessions exist, and the browser costs nothing.

Here are all four with real capabilities and prices, then the complete shape of the local login-wall workflow, since that's the case the cloud options quietly can't serve. Everything below assumes standard n8n; no plugin you can't name is required for any route.

What are the four routes?

Route 1: Browserless over HTTP Request nodes.

No special node needed: Browserless's own n8n docs say to "use n8n's HTTP Request node to call Browserless REST endpoints and BrowserQL," with your API token as a query parameter and copy-paste workflow templates.

The endpoint menu is real: /screenshot, /pdf, /content for HTML, /scrape with CSS selectors, /unblock for bot-detection bypass with session details, and BrowserQL for multi-step GraphQL flows. Hosted, regional endpoints for latency, metered billing.

Route 2: Browse AI.

No-code scraping robots you train by clicking, connected to n8n through its integration. The fastest route for a non-developer monitoring a competitor's pricing page; the least flexible when a flow needs logic a robot recorder can't express.

Route 3: community nodes on your own infrastructure.

Free software, self-managed: community packages like n8n-nodes-browserless give you typed nodes against a Browserless instance you host yourself in Docker. No per-request bill, full control, and the operational load (updates, memory, crashes) is yours.

Route 4: a local browser through Execute Command.

Self-hosted n8n runs on a machine; that machine can have a real browser. n8n's Execute Command node runs shell commands, and any agent browser becomes a workflow step. ego (lite) fits this slot precisely: an agent browser for browser automation, free, driven through the ego-browser skill, and, uniquely on this list, carrying your logged-in sessions, since every site you've signed into stays signed in and the work happens in an isolated Space.

How do costs and capabilities compare?

The four routes, on the axes that decide real deployments. Note the login-state column: it has exactly one yes.

What does the local logged-in workflow look like?

The concrete case: every morning, pull order statuses from a supplier portal that lives behind a login, into a sheet. Cloud routes stall at the login wall (or demand scripted credentials you'd rather not ship); the local route walks through it. The workflow is five nodes, and every one of them is a stock n8n node:

Schedule Trigger (07:30 daily)
  → Execute Command: ego-browser nodejs <<'EOF'
      const task = await useOrCreateTaskSpace('supplier order check')
      await openOrReuseTab('https://portal.supplier.com/orders', { wait: true })
      const rows = await js("[...document.querySelectorAll('.order-row')]" +
        ".map(r => r.innerText).join('\n')")
      cliLog(rows)   // stdout becomes the node's output
      EOF
  → Code node: parse stdout lines into JSON items
  → IF node: any status changed since yesterday?
  → Google Sheets append / Slack notify

Requirements: n8n self-hosted on the same machine as ego (lite) (Execute Command runs on the n8n host), and the portal signed into once in ego (lite), after which the session persists like any real browser's. No credentials appear anywhere in the workflow; the browser simply is logged in. The same shape covers dashboard pulls, listing checks, and any "behind my login, every day" task, swapping the URL and the selector.

Three hardening notes from running this shape in practice. Give the Execute Command node a generous timeout (page loads plus script beat n8n's default on slow mornings). Make the script's last cliLog line the only stdout you parse, so incidental logging can't corrupt the Code node's input.

And branch on the command's exit code before parsing: a non-zero exit should route to a notify path rather than feeding empty text downstream, which is the difference between "the workflow told me the portal changed" and "the sheet quietly got a blank row."

Which route for which workflow?

Public pages at volume, on a schedule, with anti-bot pressure: Browserless hosted, whose /unblock endpoint and stealth BrowserQL exist for exactly this, or the self-hosted community-node version of the same when you'd rather trade ops work for the platform fee. Non-developer building a simple monitor: Browse AI, accepting the flexibility ceiling.

Data behind your own logins, personal or team scale, budget-sensitive: the local route; it's the only one where the login problem doesn't exist, and the browser costs nothing.

And when one workflow spans both worlds (public discovery at scale, then logged-in detail checks), split it: hosted nodes for the wide half, an Execute Command step against ego (lite) for the authenticated half, joined by ordinary n8n plumbing. The join costs one Merge node and saves you from forcing either route out of its lane.

Download ego (lite) for Mac, free, or read the login-wall guide for the session model behind route 4.

FAQ

Does n8n have a built-in browser automation node?

No first-party browser node exists; the officially documented path for hosted browsing is the plain HTTP Request node against a service like Browserless, and everything else is community packages or shell commands. That absence is why this article is a four-way comparison instead of a settings page, and why the login-state column above matters more than any single feature.

Which route is cheapest to start with?

Route 4, unambiguously: self-hosted n8n and ego (lite) are both free, so the first login-wall workflow costs an afternoon and zero dollars. Browserless's free tier makes route 1 nearly as cheap to trial for public pages; the paid meters only start when volume does.

Can n8n Cloud use the local browser route?

Not directly: Execute Command runs on the n8n host, and n8n Cloud's host isn't your machine. Cloud users wanting route 4 either self-host n8n locally or bridge with a webhook: the cloud workflow calls a small local listener that runs the ego-browser step and returns results.

How do I handle sites that block automation?

For public targets, that's Browserless's stated specialty (unblock endpoint, stealth flows, CAPTCHA handling in BrowserQL), with the usual caveat that no vendor wins every arms race. For your own accounts, blocking mostly stops being a topic: a real browser with a real session you opened yourself doesn't look like automation in the first place.

Does the local route work while I'm logged out of my machine?

The machine needs to be on with ego (lite) running, since route 4's whole premise is a real desktop browser; a laptop that sleeps at 7:29 will miss the 07:30 trigger. Users who need true unattended scheduling either keep a desktop machine awake for it or split the workflow: hosted route for the unattended half, local route for the logged-in half run when present.

What about AI agent nodes in n8n?

n8n's AI agent tooling handles the reasoning layer, and it still needs one of these four routes as its hands whenever a step touches a real page. The pairing works fine: agent node decides, browser route executes, and the route choice follows the same table above.