n8n 2.28.7 - npm Install Pinning

n8n 2.28.7 was published on July 6, 2026, as a patch release for n8n-io/n8n. The release has one operator relevant fix: langgraph and langgraph-checkpoint are pinned so npm installs do not fail because of dependency drift.

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

This is not a broad workflow engine release. The notes list a single core bug fix, tied to issue #33610 and commit 7fe5d56. n8n now pins langgraph and langgraph-checkpoint rather than leaving those packages exposed to a version selection path that could break npm installs.

For platform teams, that is mostly a build reliability change. It matters when n8n is installed from packages, rebuilt in CI, or baked into an internal image. A workflow automation service is only useful if the same source and package inputs keep producing the same install result.

The release notes do not claim a runtime change in workflow execution, credentials, queue behavior, or node logic. Treat this as dependency hygiene in the core package graph, not as a feature release.

n8n often sits between SaaS APIs, databases, queues, and scheduled jobs. In that position, npm install failures are not just local developer noise. They can block image rebuilds, slow emergency patching, and make a routine redeploy depend on whatever the package resolver sees at that moment.

The two named packages are langgraph and langgraph-checkpoint. The second package name is a clue about state handling in graph style AI workflow code, but the release notes only state the package pinning fix. The safe reading is narrow: this patch reduces one known install failure mode.

That is still useful for data engineering teams. A broken install path can hold up workers that ingest webhook events, enrich records, or call downstream systems. If n8n is part of a larger ELT path, install reproducibility is part of pipeline reliability.

There is no prerelease flag on n8n 2.28.7, so this is a normal release rather than an alpha, beta, or release candidate. The upgrade surface described in the notes is small. No migration step, config key, or breaking change is called out.

The main audience is anyone who saw npm install failures around these dependencies, or anyone who builds n8n in a controlled pipeline instead of only consuming a ready image. The change should also reduce noise in CI jobs that validate package installs before publishing internal artifacts.

Keep the scope tight during rollout. Validate the package install path first, then run the same smoke checks you already use for workflow activation, scheduled triggers, credential loading, and queue backed execution. The GitHub release page is short, which is useful here: there is little else to account for.

If your deployment already pins all transitive dependencies through a lock file or internal registry policy, this release still matters, but less dramatically. It moves the project metadata closer to what production operators usually want from dependency resolution: fewer surprises at install time.