n8n 1.123.64 - Release Notes For Operators

n8n 1.123.64 was published on 2026 07 08 as a patch release for the n8n workflow automation project. The public notes do not list node fixes, API changes, queue behavior changes, or migration steps, so the useful signal for data engineers is release traceability rather than a named runtime change.

The full release notes and downloads are on the GitHub release page.

The n8n 1.123.64 note contains the version heading, the publish date, and a compare link from [email protected] to [email protected]. It does not include a curated list of workflow engine changes. It also does not call out database migrations, credential storage changes, queue changes, or node specific fixes.

That absence matters for teams that run n8n as part of an ELT or web processing path. A release can still contain code changes, but the public note does not tell an operator which execution paths moved. For scheduled jobs, webhook entry points, and long running workflow fleets, that means the release page is not enough by itself for risk scoring.

The release is not marked as a prerelease. That makes it a normal patch artifact, not a beta, alpha, or release candidate. It still deserves the same staging path as any automation runtime update, because n8n sits close to credentials, external APIs, retries, and data movement.

The release note links the GitHub compare range for [email protected] through [email protected]. That is the main technical artifact exposed by this release. When a release note has no change list, the compare view becomes the place to check touched packages, node code, migration files, and tests.

For platform teams, the basic review path is simple. Check whether workflow execution code changed. Check whether any node packages used in production changed. Check whether database migration paths changed. Check whether queue, worker, webhook, or credential code appears in the range. The release notes do not claim any of those changes, but the compare range is the only public route to verify the patch contents from the release metadata.

This is also where dependency movement matters. n8n installations often sit between SaaS APIs and internal stores. A small dependency change in HTTP handling, date parsing, authentication, or retry logic can be more relevant than a visible UI change. The release notes for 1.123.64 do not name such a change, so any dependency review needs to come from the linked compare view rather than from the prose on the GitHub release page.

The body of the release includes generated review links for stage review and cubic. Those links are useful process markers, but they are not a substitute for a release summary. They do not state which runtime behavior changed, which tests covered it, or whether existing workflows need operator action.

For a CMS or data workflow platform, that distinction is practical. Release automation can prove that a release passed a process. It does not tell a data engineer whether a Salesforce node, a date expression path, a webhook responder, or a queue worker changed. The notes for this release provide process context, not operational detail.

The safest reading is therefore narrow. n8n 1.123.64 is a normal patch release with minimal public description. It should be consumed by checking the release artifact, the compare range, and local workflow coverage before promotion.

The published notes do not mention breaking changes, manual migration steps, config keys, CLI flags, or schema changes. There is also no explicit warning for existing workflow exports, queue workers, or webhook deployments.

That does not prove that there is no risk. It only means the release notes do not ask for a specific operator action. For production users, the practical upgrade path is to run the same regression set used for any n8n patch: scheduled workflows, webhook workflows, credential backed nodes, retry paths, and any custom nodes or community nodes that sit in critical data paths.