The n8n project has published the release notes for version 2.43.0, a changelog entry that collects a large number of individual commit-level items rather than announcing one headline feature. Each line pairs a short description with a pull-request number, and the list spans the AI agent tooling, the workflow editor, node integrations and the core execution engine.
For freelancers and developers who self-host n8n or build client automations on it, the version number matters less than which entries touch workflows already in production. The notes are not grouped by upgrade risk or by impact, so the list has to be read item by item, and the supplied text contains no release date, no migration guidance and no statement of breaking changes.
The agent side of the product accounts for a substantial cluster. The notes list an opt-in budget guardrail for agent runs, persistence of agent budget spend in the database, usage and budget settings for agents in the editor, and an instance-level setting for Agents. Read together, these describe a system where agent execution can be constrained by spend and configured centrally, but the changelog does not state default values, pricing, enforcement behaviour or whether the features are generally available or gated.
Related agent entries include a guardrail runner added to the agent loop, a tool to mark an agent session as failed, escalation of background sub-agent approvals to parent chats, and deduplication of agent message deliveries. There is also a fix for Agent session pagination on SQLite, a change to apply removed fields when the Agent Builder patches agent configuration, and a limit on MCP Agent model discovery results.
The execution engine received structural changes as well. One entry describes adding engine suspension at node boundaries for resumable executions, and another covers stopping engine v2 executions from the control plane. A separate item limits background task continuation to the latest stop group. These are described only at the level of the change title, so the notes do not explain the resumption semantics, the storage involved or which node types are affected.
Shutdown and concurrency behaviour forms another group. The notes mention capping pending task request timeouts to the shutdown deadline, keeping jobs a worker enqueued out of its shutdown drain, stopping waiting on enqueued jobs in worker shutdown, keeping floating entitlements attached when a multi-main instance shuts down, and passing a graceful-shutdown timeout to runners in the runners image. A further entry passes a shutdown margin to the JavaScript runner in the runners image.
Credential and permission handling appears repeatedly. Entries cover waiting for credential deletion to finish, keeping concurrent credential tests from sharing one node type registry, using a new client ID and secret for OAuth2 client credentials, letting global members grant variable scopes to API keys, and applying policy checks to CLI import and execute commands. The editor side adds a change that stops Execute and Publish when a credential is not yours to use, and another that shows whose credential a node uses and lets others switch from it.
The editor changelog is the longest section. It includes keyboard controls for the n8n Assistant panel, reordering AI Assistant tabs by dragging, closing AI Assistant tabs while keeping open tabs per thread, opening any project resource as an AI Assistant tab, and releasing Browser Use to all users. Several entries are layout or interaction corrections, such as aligning input heights on the project settings page, extending the workflow review divider to full height, and scaling up node icons that declare a size smaller than their slot.
Node-level changes are scattered through the list. The Azure OpenAI Chat Model node gains support for Responses-only deployments and a deployment dropdown. The Supabase node adds OAuth credentials reused for MCP. The Split Out node supports dot notation in destination fields. The Execute Workflow node returns declared sub-workflow outputs. The Google Calendar Trigger node handles all-day event boundaries. The Databricks Trigger node caps pipeline event pages at 250, described in the notes as the limit Databricks enforces.
Some entries describe behaviour that could change existing automations. Blocking publishing of workflows with unconnected required node inputs is one example, as is hiding node types that the instance does not load and hiding generated AI tools listed in NODES_EXCLUDE. The changelog does not say whether these are opt-in, default-on or configurable, which is the kind of detail that determines whether an upgrade is routine or disruptive.
The notes also include a short performance section with a single item, about loading project relations without joining every role scope. That is the only entry filed under performance improvements in the supplied text, so the release cannot be characterised as performance-focused on this evidence.
For a freelancer maintaining client automations, the credential and permission entries are likely the most immediately relevant, because they affect who can run and publish workflows, and the shutdown-related fixes matter for reliability during restarts and multi-main deployments. The agent budget and guardrail entries matter mainly to those already using the agent features, and the notes do not establish availability tiers or pricing for them.
It is worth being explicit about what this evidence does not contain. There is no release date in the supplied text, no upgrade or migration instructions, no statement of breaking changes, and no indication of which changes are enabled by default. The version number 2.43.0 is the only version identifier present, and the notes do not include reproduction steps, affected configurations or known regressions.
The changelog is therefore a pointer to the relevant pull requests rather than a description of verified behaviour in any particular deployment. Anyone planning to upgrade should treat each line as a commit summary and check the linked pull request before assuming how it behaves in their own environment.
A reasonable editorial reading is that this is a maintenance and feature-accumulation release rather than a single-announcement event. The breadth of the list, covering agent infrastructure, editor polish, node integrations and core runtime, suggests incremental work across the codebase. That interpretation is based on the shape of the changelog, not on any statement from the project about release strategy.
For this audience, the practical takeaway is to scan the credential, permission and shutdown entries first if you run shared or multi-user instances, and to check the node-specific entries if your workflows depend on Azure OpenAI, Supabase, Databricks, Google Calendar or the Execute Workflow and Split Out nodes. Everything else can be reviewed at leisure, since the notes give no signal that any single item is urgent.