Home / Guides / n8n Browser Automation

Browser Automation in n8n Without Per-Minute Fees

Last updated: July 17, 2026

n8n is great at moving data between APIs, but the moment a step needs a real webpage, a price, a form, a site with no API, most teams reach for a metered cloud browser and start paying per browser-minute. There's a simpler shape: run the browser where n8n already runs and call it over HTTP.

The architecture in one sentence

A local browser exposes a REST API on localhost; n8n's built-in HTTP Request node calls it; no community node, no Docker sidecar per run, no per-minute billing. LumaBrowser is built for exactly this: it's a desktop browser with a documented REST API in the same install.

Your first flow: read a rendered page

Three nodes: a trigger of your choice, then two HTTP Request nodes, one to open the page in a tab, one to pull its rendered text.

# Node 1: open the page in a tab
POST http://localhost:3000/api/browser/tabs
{ "url": "https://example.com/product/42" }

# Node 2: get the rendered page text
GET http://localhost:3000/api/browser/tabs/0/source?type=text

The response is JSON your next node consumes directly, after the page's JavaScript has actually run, which is what request-based scraping nodes can't give you.

Filling forms and clicking through

Multi-step interactions chain the same way: fill, click, wait, each an HTTP Request node against the same tab. Interaction endpoints accept an llmFallback description alongside the CSS selector:

POST http://localhost:3000/api/browser/tabs/0/click
{
  "selector": "button[type=submit]",
  "llmFallback": "Click the login button"
}

The strict selector is the fast path. If the site ships a redesign and it stops matching, the LLM resolves the element from the description and the flow keeps running, with the fallback logged so you can update the selector on your own schedule. Because the browser holds a persistent profile, logins survive between runs; sites behind authentication behave the way they do when you browse manually.

Triggering a workflow when a page changes

Polling a page from a Cron node wastes runs and still misses fast changes. Flip the direction: LumaBrowser's website change monitor watches an element you pick visually and fires a webhook the moment it changes. Point it at an n8n Webhook node and the workflow starts with the diff already in the payload:

{
  "monitorName": "Acme Pricing Page",
  "url":         "https://acme.com/pricing",
  "timestamp":   "2026-07-17T09:14:02.412Z",
  "diffSummary": "+1 / -1\n+ $39/mo\n- $49/mo",
  "textPreview": "First 2000 characters of the new text…",
  "changeCount": 17
}

From there it's ordinary n8n: post to Slack, update a sheet, open a ticket.

Why not just use a cloud browser API?

• Cost scaling: metered services bill every browser-minute; a 5-minute scrape across 200 runs a day compounds fast. A local browser costs whatever the hardware it runs on costs, and the Community Edition is free.
• Data locality: pages with customer data never leave your network; the browser runs next to your self-hosted n8n.
• Fewer moving parts: no separate container image to upgrade, no API-key rotation for the browser layer, no queueing when the vendor throttles concurrent sessions.

The full cost comparison against the metered options lives on the workflow automation page.