n8n has an unusual public signal: 1,339 GitHub commits in 30 days, 30 GitHub releases in 90 days, and 0 release events in ToolVitals’ latest 30-day window. That is not a contradiction. It describes a project with substantial engineering activity whose visible release cadence paused during the measured month. The stronger thesis is that n8n is moving from a visual automation product toward an operational platform for AI workflows, but the available evidence supports that conclusion more clearly as a maintenance and control story than as proof of product quality.

n8n is building a code-and-canvas operating model

The official n8n site describes the product as workflow automation for technical teams. Its positioning combines AI capabilities with business process automation and puts equal weight on visual building and code. The site specifically highlights JavaScript and Python inside workflows, step-level reruns, replayed or mocked data, logs, and native evaluation for AI workflows.

The GitHub repository makes the positioning more explicit. It calls n8n a fair-code platform for building and deploying AI agents and workflows. The repository describes workflows that use an organization’s own data, models, and tools, with logic, tool use, human approvals, and observability. It also emphasizes model flexibility, self-hosting, role-based access, audit trails, JavaScript, Python, and npm packages.

That combination matters. A visual workflow builder is useful for making process logic visible. Code support matters when a workflow needs custom data handling, an unusual API, a specialized retry policy, or logic that does not fit a prebuilt node. n8n’s stated product boundary is therefore wider than simple task automation. It is trying to give engineers a place to assemble and operate multi-step AI systems without forcing every part of the system into either a canvas or a codebase.

The integration story needs careful treatment. The supplied product description says n8n has 400+ integrations, while the current GitHub excerpt says 1500+ integrations and 9,000+ workflow templates. Those figures may reflect different counting methods or different snapshots, but ToolVitals does not independently measure either number. Treat integration breadth as a claim to test against the connectors your team actually needs, not as a settled benchmark.

The official site also frames n8n around security, control, and visibility. It lists on-premises deployment, SSO SAML, LDAP, encrypted secret stores, version control, RBAC permissions, audit logs, SIEM log streaming, workflow history, alerts, usage dashboards, Git-based control, isolated environments, workflow diffs, human review, guardrails, and evaluations. Those are the features that make the product relevant to engineering and security teams, not just people assembling simple automations.

Fair-code is a procurement decision, not a footnote

n8n is fair-code, not OSI-approved. ToolVitals marks its openness class as fair_code and identifies the license as the Sustainable Use License. The repository describes n8n as fair-code distributed under the Sustainable Use License and the n8n Enterprise License. It also describes the project as source available, self-hostable, and extensible.

That distinction changes how a team should evaluate the product. Source visibility and self-hosting can help with deployment control, inspection, and integration work. They do not make n8n an OSI-approved OSS project. Teams with a formal OSI-approved licensing requirement should treat the license classification as a gate, not as a detail to resolve after implementation.

This is also why the word fair-code should remain in any technical assessment. Calling n8n generic open source would erase a constraint that may matter to legal, security, and platform engineering teams. The right question is not whether the repository is visible. The right question is whether the project’s license model fits the intended deployment and use case.

The metrics show scale, participation, and a release pause

ToolVitals records 208,008 GitHub stars for n8n. The official site presents a rounded 207.9k-star figure, but the ToolVitals metric is the source of truth for this analysis. That level of public attention places n8n well beyond the scale of a small experimental automation project.

The repository recorded 1,339 commits in the last 30 days and 80 active contributors. Those figures support a claim of sustained engineering participation. They do not establish that the changes are user-visible, that they improve reliability, or that the project’s architecture is easy to maintain.

ToolVitals gives n8n a health score of 99, a shipping score of 99, and an overall ToolVitals score of 99. Its hot score is 207.8, and the data confidence value is 90. These are strong public-project signals, but they are index values. They are not an uptime guarantee, a security certification, a support commitment, or a measure of workflow correctness.

The most interesting number is the release split. ToolVitals counts 30 GitHub releases in 90 days but 0 release events in the latest 30 days. The supplied event snapshot places several releases on August 20 and August 21, 2026, which fits the two different measurement windows. A busy repository can therefore coexist with a quiet release month.

That pause has two possible interpretations. It may mean the project was doing internal work, consolidating changes, or waiting for a coordinated release. It may also mean that visible delivery slowed while commit activity remained high. ToolVitals can identify the pattern, but it cannot determine which explanation is correct.

Stars and commit counts also have limits. Stars indicate public interest, not active production use. Commit counts can include refactors, generated changes, merges, maintenance work, and changes that never reach the version used by a particular customer. Active contributors show participation, not necessarily effective review, operational maturity, or support quality.

The release evidence points toward control-plane work

The supplied release excerpts show n8n working on runtime behavior, credentials, authentication, isolation, observability, and AI assistant limits. That is a more operational direction than a sequence of headline features.

The n8n 2.36.4 release includes fixes for normalizing environment values before schema-based parsing and validating chat and MCP trigger authentication modes for end-user credentials. It also wraps a trigger close function in an expression isolate at creation time. These changes target configuration interpretation, authentication boundaries, and execution cleanup.

The 2.36.5 release raises the AI Assistant model verification token limit. The same type of fix appears in 2.35.7. That is not evidence of a new agent capability. It is evidence that the team is adjusting limits around an existing AI-assisted workflow.

The 2.36.3 release avoids restarting task runners that are only slow, initializes the expression engine only for commands that evaluate expressions, releases a test-webhook isolate after teardown completes, and restores an editor type selector style. The 1.123.75 release includes related work on environment parsing, expression-engine initialization, test-webhook teardown, and trigger cleanup.

The 2.35.6 release resolves end-user credentials when loading node parameters. The beta release lists connection reuse in the log-streaming webhook destination and turning off expression spans by default. The stable release also lists expression spans being disabled by default.

Taken together, these excerpts suggest a project tightening the machinery around workflow execution. Credential resolution, trigger shutdown, task-runner behavior, expression processing, log streaming, and authentication all sit close to the control plane. AI work is present, but the supplied evidence shows it being handled through verification limits and execution controls rather than only through new user-facing features.

The release pages are not a complete changelog. Several supplied GitHub excerpts report an error while loading the page, even though they expose selected change entries. That limits how much can be inferred about the full scope, regressions, compatibility effects, or release rationale. The evidence supports a direction, not a full roadmap.

What ToolVitals cannot tell you

ToolVitals sees public repository activity, GitHub stars, commits, releases, active contributors, license signals, and related project evidence. It does not see whether a workflow runs correctly for your data, whether an integration handles edge cases, or whether a self-hosted deployment remains stable under your workload.

The metrics do not measure code quality. A high commit count can accompany good engineering, rushed changes, generated code, or a large monorepo with many independently changing packages. A 99 shipping score does not tell a buyer how often upgrades require migration work or how much testing is needed before production rollout.

The data also does not measure user satisfaction, revenue, support responsiveness, total operating cost, or production adoption. It cannot establish that the advertised AI workflows are accurate, that human approvals are usable, or that observability features provide the level of evidence an incident-response team needs.

The integration-count discrepancy is a concrete example of the boundary. The payload says 400+ integrations, while the repository excerpt says 1500+. Neither figure is a ToolVitals measurement. A skeptical buyer should select the exact systems that matter, build representative workflows, test authentication and error paths, and record what works without relying on a headline count.

The same caution applies to the release pause. Zero release events in 30 days does not mean the project is inactive, because the repository also shows 1,339 commits in that period. It does not mean the project is stable, either. The metric only establishes that public release activity was absent in the measured window.

The related-tools data puts n8n above the other listed automation projects on several public signals. nodetool has 571 GitHub stars, a hot score of 177.2, and a shipping score of 98. gh-aw has 5,413 stars, a hot score of 175.8, and a shipping score of 98. n8n has 208,008 stars, a hot score of 207.8, and a shipping score of 99.

Those numbers show a much larger public footprint and a one-point advantage on the ToolVitals shipping index. They do not establish that n8n is a better fit for a particular workflow. The related-tools list does not provide feature-by-feature compatibility, deployment benchmarks, or user outcomes.

The licensing distinction is also material. ToolVitals classifies nodetool as OSI-approved OSS under AGPL-3.0 and gh-aw as OSI-approved OSS under MIT. n8n is classified as fair-code under the Sustainable Use License. These tools are useful comparison points for teams weighing automation capability against licensing requirements, but the public metrics do not make them interchangeable products.

What a skeptical buyer should test

An engineering lead evaluating n8n should run a narrow production-shaped pilot, not a gallery of impressive demos. Test the required integrations, credential handoff, environment parsing, chat and MCP authentication, task-runner behavior, retries, logs, expression evaluation, AI provider switching, human approval steps, and failure recovery. The release evidence shows attention in these areas, but it does not show that the buyer’s specific workflow succeeds.

The pilot should also include the deployment model the team actually intends to operate. If the requirement is self-hosting, test upgrades, backups, access control, audit records, secret handling, and isolation boundaries. If the requirement includes an OSI-approved license, stop at the license review and resolve that question before treating technical success as a procurement recommendation.

What the maintainers should make clearer

For maintainers, the public data is strong but not perfectly legible. A repository with 1,339 commits, 80 active contributors, and 30 releases in 90 days can look highly active, while a 0 release-event count in the latest 30 days can make the visible shipping story look quiet. Clearer release-channel explanations would help readers understand whether that pattern reflects consolidation, scheduled cadence, or a change in delivery practice.

The integration-count mismatch also deserves a single canonical explanation. If 400+ and 1500+ count different connector categories, say so directly. If one figure is outdated, replace it. The license message should remain equally precise: source available and self-hostable are useful properties, but the fair-code and Sustainable Use License classification should stay prominent wherever technical buyers assess the project.

Recommendation

If your team needs self-hostable workflow automation that combines a visual canvas with JavaScript or Python and has a serious AI workflow focus, n8n is a reasonable candidate for a controlled evaluation. Its 208,008 stars, 1,339 recent commits, 80 active contributors, and release evidence around authentication, isolation, credentials, task runners, and AI verification indicate a large project working on the hard parts of operation.

Do not choose it from the metrics alone. Make the Sustainable Use License a formal review item, verify the exact integrations you need, and test the failure and security paths that matter to production. If those checks pass and fair-code fits your governance requirements, n8n’s evidence supports adoption for teams that want code-level control without abandoning visual workflow design.

Sources