n8n 1.123.61 - Sparse Notes and Rollout Checks

n8n [email protected] was published on June 24, 2026. The main operator signal is that the public GitHub release page does not list fixes, migrations, or changed workflow behavior beyond the new tag and compare target. Treat it as a narrow patch announcement that still needs a controlled rollout, because n8n often sits in the path of data movement, API calls, and scheduled jobs.

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

This release is marked as a stable release, not a prerelease. That matters for automation estates that separate beta or release candidate builds from normal patch updates. There is no alpha, beta, or release candidate flag in the metadata for [email protected].

The release notes themselves are thin. They include the release header for 1.123.61, the publish date, a compare target from [email protected] to [email protected], and review badge markup. They do not name workflow engine fixes, node changes, queue behavior, database migrations, security fixes, credential changes, or API changes.

That absence is the useful signal. For data engineering teams, a sparse release note should not be read as proof that nothing changed. It means the public announcement does not give enough detail to classify the blast radius from the notes alone. The right response is smaller rollout scope, better local verification, and a quick check of the exact release artifact before moving production workflows.

n8n is often used as glue between SaaS APIs, databases, webhooks, queues, and scheduled workflow runs. Even when a patch release does not document a node level change, the operational surface is still large enough to deserve a focused smoke test.

Start with scheduled workflows. Confirm that cron based and interval based triggers still fire at the expected time, especially if workers and the main process are split. Then test webhook workflows with real request shapes, not only synthetic health checks. If the deployment uses queue mode, verify that jobs leave the queue and complete with the expected execution status.

Credential backed calls deserve their own check. Run at least one workflow that uses external API credentials, one that reads from a database, and one that writes to a downstream system. The release notes do not claim changes in those areas, but those are the paths where a small runtime regression becomes a data incident.

The notes for [email protected] do not mention breaking changes or manual migration steps. There is no documented schema migration, config key rename, credential format change, or action required for existing workflows.

That does not remove the need for normal state checks. Back up the database before upgrading any shared instance. Capture the current image digest or package version. Keep a known rollback target for [email protected] if that is the version currently running. The release header explicitly compares from [email protected], so that is the natural baseline for this patch.

For larger installations, run the update first against a copy of representative workflows. Include workflows with HTTP Request nodes, database nodes, branching logic, retries, and error workflows. The point is not to invent hidden changes. The point is to compensate for notes that do not describe the changed surface.

The most important fact about [email protected] is not a named feature. It is the lack of named change detail in the public release text. That makes this a release where operators should lean on local evidence rather than announcement content.

Use the GitHub release page as the source of truth for the tag and artifacts. Then use the normal deployment pipeline to answer the questions the notes do not answer: do workflows start, do queued jobs drain, do credentials resolve, do executions finish, and do downstream systems receive the expected records.

This is also a case where release automation is visible in the notes. The body contains generated review markup and badge links, but no human written summary of fixes. That is fine for traceability, but it is weak as operator documentation.