n8n 2.28.3 - Community Package Startup Fix

n8n [email protected] was published on June 29, 2026, as a focused core bug fix for startup failures caused by partially installed community packages. For teams running n8n as part of data movement or web processing workflows, the main change is process boot resilience when extension state is incomplete. This is a stable release, not a prerelease.

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

The release notes list one bug fix in core: n8n no longer fails startup when community packages are left in a partially installed state. The tracked item is issue #33032, and the cited code change is commit adfc7c7. That is the meaningful item in this tag; the remaining material in the notes is release automation markup.

Partially installed packages are not rare in workflow systems with persistent volumes. A package install can be interrupted by a pod restart, a disk quota issue, an image rollout, or a failed write to the package directory. Before this fix, that bad local state could block the whole process at boot.

That matters because n8n nodes often sit between webhook intake, browser automation, SaaS APIs, queues, and warehouses. A startup crash turns a local package problem into a scheduler or worker outage. The fix narrows the failure mode: the instance should be able to start instead of treating an incomplete community package as fatal.

The useful reading is not that community packages are now magically healthy. The release notes do not say that package installation itself was changed, and they do not describe a migration. The practical win is at the boundary between extension state and process availability.

For data engineering teams, that boundary is important. n8n is often deployed as a workflow layer around extract jobs, webhooks, enrichment tasks, and control plane calls. If a community node install leaves partial files, it should not have the same blast radius as a bad database migration or a broken queue.

After applying [email protected], operators should still inspect package directories, persistent volumes, and startup logs after any failed install. The release reduces one boot failure path. It does not remove the need to pin community nodes, review package sources, or keep extension changes separate from routine runtime rollouts.

This is a patch release with a narrow surface. It is not marked as a prerelease in release.json, and the notes do not list breaking changes, schema migrations, API changes, or workflow behavior changes. The GitHub release page is the source of truth for this tag.

The best rollout test is boring: start one instance with the same persistent package volume state used by production, then watch for package discovery warnings and worker readiness. If the deployment uses separate main, webhook, and worker processes, test the process types that load community packages. The notes name core, so assume the startup path matters across the runtime, not just a single queue consumer.

The release does not provide a detailed package repair procedure. If an instance had already failed during a community package install, keep the old state available until the new binary has started cleanly and the package list can be inspected from the running service. Treat this as a runtime availability fix, not as evidence that every damaged package is safe to execute.