authentik
The first patch on 2026.8 is twenty-odd fixes and no new surface.
A side-by-side editorial comparison of Node-RED and werf — release velocity, themes, recent moves, and the top alternatives to consider.
Both lines patch on the same day, and the reverted JSONata upgrade finally sticks.
Node-RED shipped 5.0 in June 2026 after a long beta, raising the runtime floor to Node.js 22.9, and the work since has been stabilisation. This pair patches both lines within ninety minutes: 5.0.5 fixes group fill defaults and opacity, an uncaught exception in the json node on malformed input with a schema, tlsConfigDisableLocalFiles, and multiplayer event property validation; 4.1.14 takes the multiplayer fix, a themes locale lookup error, and the same dependency work. JSONata 2.2.2 lands on both lines, the version that was reverted in July after a behaviour regression.
The 3.x line finally ships function: authenticated secret writes and render patches.
werf publishes the same work across alpha, beta, ea and stable channels plus a 3.x dev line, so one fix surfaces three or four times under different version numbers. This pair is that pattern exactly: v3.3.0 carries two features — writing authenticated secret values from deploy, and renderPatches support — plus four fixes, and v2.77.2 carries the same four fixes and nothing else. The fixes are the usual build-engine territory: buildah imports failing on symlinked paths, a panic when a stapel base image disappears mid-commit, a cache repo pointing at itself, and host-cleanup misreporting what it pruned.
Node-RED shipped 5.0 in June 2026 after a long beta, raising the runtime floor to Node.js 22.9, and the work since has been stabilisation. This pair patches both lines within ninety minutes: 5.0.5 fixes group fill defaults and opacity, an uncaught exception in the json node on malformed input with a schema, tlsConfigDisableLocalFiles, and multiplayer event property validation; 4.1.14 takes the multiplayer fix, a themes locale lookup error, and the same dependency work. JSONata 2.2.2 lands on both lines, the version that was reverted in July after a behaviour regression.
The 4.1 line is not winding down. It has now received same-day parallel releases twice, and the fixes crossing over are correctness rather than security this time, which is a wider commitment than backporting sanitisation patches. The defects still cluster in the editor surfaces 5.0 rewrote — groups, multiplayer, tree lists — rather than in the runtime, which is the expected shape after a major that focused on the editor.
JSONata 2.2.2 going out on both lines after July's revert suggests the upstream regression is resolved, so the next patches likely return to editor defects rather than dependency churn. The release notes give no timeline.
werf publishes the same work across alpha, beta, ea and stable channels plus a 3.x dev line, so one fix surfaces three or four times under different version numbers. This pair is that pattern exactly: v3.3.0 carries two features — writing authenticated secret values from deploy, and renderPatches support — plus four fixes, and v2.77.2 carries the same four fixes and nothing else. The fixes are the usual build-engine territory: buildah imports failing on symlinked paths, a panic when a stapel base image disappears mid-commit, a cache repo pointing at itself, and host-cleanup misreporting what it pruned.
The division of labour between the lines is now explicit — 2.x takes only fixes, 3.x takes fixes plus everything new. This is the first window where the 3.x dev line carries user-facing deploy function rather than build internals and gated experiments, which moves it from a place to accumulate changes toward something with its own reason to exist. The build-engine hardening under parallelism continues underneath both.
renderPatches and authenticated secret writes are both deploy-side, so the next 3.x releases likely continue there rather than returning to buildah. Whether the embedded deno work behind its build tag connects to the render path is still not stated.
Other Infra & APIs products tracked by Sparkpulse, ranked by recent ship velocity. Each card links to a full editorial trajectory and lets you pivot into a head-to-head comparison with either Node-RED or werf.
The first patch on 2026.8 is twenty-odd fixes and no new surface.
Alert rate limits stop being per-source and start being per-tenant, by query.
The essay series keeps running ahead of the products it describes.
Folder-level RBAC lands, and approvals finally get a webhook to talk to.
Retool posts one-line changelog entries, and its agent work is the only visible thread
Resend ships an API endpoint most days, and has just added the checkbox enterprises ask for
See all Node-RED alternatives → · See all werf alternatives →
Latest ship moves from both products, interleaved chronologically. ⚡ = editorial spark.
They serve adjacent needs but don't currently overlap on shipped themes. Node-RED and werf are shipping at a similar cadence (velocity 5.0 vs 5.0, both within Sparkpulse's "active" band). See the at-a-glance table above for a side-by-side breakdown of velocity, recent sparks, and editorial themes.
Sparkpulse doesn't pick a winner — we score release velocity, not feature parity. Node-RED and werf are shipping at a similar cadence (velocity 5.0 vs 5.0, both within Sparkpulse's "active" band). For your specific use case, the alternatives sections above list other Infra & APIs products to evaluate alongside.
Top Node-RED alternatives in Infra & APIs are ranked by recent ship velocity. Browse the "Node-RED alternatives" section above for the current picks, or visit /alternatives/node-red for the full list with editorial commentary on each.
Top werf alternatives in Infra & APIs are ranked by recent ship velocity. Browse the "werf alternatives" section above for the current picks, or visit /alternatives/werf for the full list with editorial commentary on each.