n8n in October 2026: Browser Use for everyone, admin node rules, a durable scheduler, and personal credentials in team projects
Four n8n releases in October (2.43 to 2.46): Browser Use for all users, admin rules for which nodes people may add and run, a durable scheduler by default, and personal credentials in team projects. What each one changes for teams running n8n as shared infrastructure.
October was a busy month for n8n. Four weekly releases (2.43 to 2.46) landed before the 3.0 beta arrived on the 27th, and each one changes something an operator will notice. This note covers the four that matter for UK teams running n8n in production.
1. Browser Use opens to all users (2.43, 6 October)
The headline. n8n's Browser Use capability, which lets a workflow drive a real browser through an AI agent (open a portal, fill a form, read a table, click through a flow with no API), moved from limited access to everyone. It is still flagged beta, but it is on the standard track.
Why it matters: a large share of the work SMEs want automated lives in web portals that will never ship an API. Supplier sites, council and government portals, legacy ERP front ends, insurer dashboards. Until now the answer was "use a browser agent product and bolt it onto n8n". Now the agent step sits inside the same workflow as the retries, the approval gate and the audit trail.
What to be careful about: a browser agent is a probabilistic step inside a deterministic graph. Put it behind an IF node that checks the result, log the screenshot or extracted data, and keep the human approval for anything that submits, pays or sends. We go deeper on this in Agents that click: the governance gap.
2. Admin rules for which nodes users can add, publish and run (2.44, 13 October)
Admins can now set rules controlling which nodes people may add to a workflow, publish, and execute. This is the governance feature mid-sized teams have been asking for since n8n became the default automation layer for departments outside IT.
Practical uses:
- Block the Execute Command and SSH nodes for everyone except platform owners
- Allow HTTP Request nodes only in projects owned by engineering
- Let marketing publish workflows that touch HubSpot but not the finance system
- Restrict Browser Use to a named group while it is still beta
2.44 also added Google Vertex AI credentials, useful if your data residency story runs through Google Cloud.
3. Durable scheduler on by default (2.45, 20 October)
Schedule Trigger nodes now use the durable scheduler by default. In plain terms: if the instance restarts, redeploys or crashes at 09:00, the 09:00 run is not silently lost. For anyone running daily reconciliations, nightly syncs or "every Monday at 8" digests, this closes a gap that used to be covered by a human noticing nothing arrived.
Check your monitoring anyway. Durable means the run is queued and recovered; it does not mean the downstream API was up when it ran.
4. Personal credentials inside team projects (2.46, 27 October)
Users can now use their personal credentials in team projects. Before this, a shared project meant shared credentials, which pushed teams into one of two bad habits: a shared service account with too much access, or copying personal tokens into a project credential nobody rotates.
Now a workflow in a team project can run as the person who owns the connection. Pair it with the node rules above and you get a much cleaner answer to "who did this automation act as?".
2.46 also expanded Agent and AI model support and shipped migration tooling ahead of 3.0.
What changed for buyers
| Need | Before October | After October |
|---|---|---|
| Automate a portal with no API | External browser-agent product plus webhook | Browser Use step inside the workflow (beta) |
| Stop a junior adding a shell node | Policy document and hope | Admin node rules |
| Guarantee a scheduled run survives a restart | Manual checks or external cron | Durable scheduler by default |
| Act as a named person in a shared project | Shared service credentials | Personal credentials in team projects |
Who should care
- Operations leads who own the automation estate and get the blame when a Monday run goes missing
- IT and security who were told "it's just n8n" and now have a way to say which nodes are allowed
- Agencies and consultancies running client instances, where personal credentials in team projects simplify handover
- Anyone considering a browser-agent product as a separate purchase. Try the n8n step first and see whether the separate licence is still justified
A note on 3.0
All four releases above are 2.x. The 3.0 beta that followed on 27 October removes legacy nodes, drops npm installs and changes defaults. If you are upgrading through October's releases on your way to 3.0, read the upgrade checklist first.
Bottom line
October's n8n releases are less about new nodes and more about running n8n as shared infrastructure: who can add what, what survives a restart, and whose credentials a workflow uses. Browser Use is the headline, but node rules and personal credentials in team projects are the ones that let a UK business hand n8n to more than one department without a security review every week.
Related reading
- n8n 3.0 beta: what breaks, and what to do before December
- n8n Assistant: workflows you can edit
- AI browser agents vs workflow automation: what to buy first
- Agents that click: the governance gap
- n8n on the marketplace
Sources: n8n release notes · n8n 1.x and 2.x release notes · Browser Use integration · n8n 3.0 beta
Erhan Timur, Founder, Digital by Default
Enjoyed this article?
Subscribe to our Weekly AI Digest for more insights, trending tools, and expert picks delivered to your inbox.