BLOG
n8n’s 2.43 release notes describe a Browser Use capability in the n8n Assistant. This helps a person build or inspect an automation through the browser, but it does not mean every workflow has unlimited browser control or that a customer-facing process is ready for production. Check the current version and account feature flags before following a dated October 2026 announcement.
What changed in n8n 2.43?
The release notes are the primary record of the feature-level change. n8n warns that release-note entries may ship behind flags or gradually across Cloud and self-hosted installations. Therefore, check the version on your instance and whether the Assistant feature is actually visible to the intended user. A feature described in documentation is not proof it is enabled in every workspace.
Browser Use in the Assistant concerns building or testing with help from an interactive browser context. A finished workflow still needs explicit nodes, credentials, triggers, and monitoring. Do not confuse an Assistant action in an editor with an unattended automation that is authorized to operate on any website.
Who can use the Assistant?
The Assistant documentation and self-hosted setup guide explain deployment requirements. Availability can differ by platform, account, region, and rollout. Confirm the permission level of the person using it. An editor who can connect production credentials should not test a browser-assisted change on a customer account without an approved scope.
Record the current n8n version before changing anything. If a new version is needed, review its complete release and migration notes. Updating production solely for a feature demo can introduce unrelated changes. Use a test instance or a controlled window for any upgrade.
| Stage | Evidence to check |
|---|---|
| Availability | Version, flag, deployment, and user role |
| Build | Reviewed nodes, credentials, and trigger |
| Test | Expected, missing, duplicate, and failed inputs |
| Operate | Owner, alert, logs, cost, and rollback path |
Assistant cost and workflow cost differ
The Assistant may have a distinct credit or provider-key arrangement from the workflow it helps create. A workflow can later use its own API model, n8n executions, and connected services. Check the current account terms before estimating a monthly cost. Do not infer that a free or included Assistant action makes the resulting CRM automation free to run.
For a pilot, count how many runs occur, whether retries create additional model calls, and what the destination service charges. Include staff time for review and support. A scenario that works once in the editor may have a very different bill and error rate under real form traffic.
Example: a website request enters a CRM
A small business wants a website form to create or update a lead. The Assistant can help draft the workflow: webhook, validation, lookup, route, CRM action, and notification. The builder then reviews the nodes and credentials. Every submission receives an external ID so a retry can find an existing record before creating another.
Use test contacts and a staging CRM. Test a new lead, an existing lead, missing email, duplicate webhook delivery, and an unavailable CRM. Confirm the actual destination record, not just a green execution bubble. If the write fails after the CRM accepted it, a blind replay may duplicate the lead. Read the CRM state before trying again.
What four tests reveal problems?
First, check the normal path from form submission to saved record. Second, send incomplete data and verify the workflow asks for review rather than inventing a field. Third, send the same request twice and confirm a single lead. Fourth, force a destination error and verify the alert reaches the owner with enough context to recover. Repeat after a version or credential change.
Is this unlimited browser automation?
No. The documented feature should be understood within the Assistant’s supported context, roles, and limits. It is not a universal permission to browse customer accounts or bypass a site’s authentication. Use service APIs for stable integrations when available and treat any browser interaction as a scoped, reviewed step.
Should production upgrade immediately?
Review what the browser step actually changed
If the Assistant edits a workflow, inspect the saved difference before testing it. A node may have a plausible name while pointing to the wrong credential or environment. Check expression references, webhook URLs, branch conditions, and the data sent to each destination. Save a version or export that can be restored. Run the new version with test records and compare actual outputs in the destination system. The speed of creation is only useful when the resulting workflow remains understandable to the person who will maintain it.
For browser-assisted work on a third-party site, confirm the site’s terms and the authorized account. A UI step can break when labels or layout change and may expose more data than a purpose-built API call. When a stable service API exists, consider it for the production workflow. If browser interaction is necessary, monitor it, limit its scope, and define a fallback when the page changes or asks for reauthentication. Do not store passwords in a prompt or an article.
After enabling a new workflow, check its first real executions. Verify that alerts reach the owner and that incomplete records are not treated as successful. Review the logs without copying sensitive customer data into support tickets. The team should know how to pause the flow and handle requests manually if the destination service fails. This operational plan matters more than whether the initial workflow was assembled by an assistant, a template, or a person.
Only if the full release and migration review supports it. A team can first verify its current version and features, test a limited workflow, and decide whether Browser Use solves a real building problem. The durable value comes from a correct, observable automation, not from how quickly the initial nodes were placed.
