incident.io
Nexus does the diagnosis; the rest is on-call plumbing
A side-by-side editorial comparison of Obsidian and werf — release velocity, themes, recent moves, and the top alternatives to consider.
| Feature | Obsidian | werf |
|---|---|---|
| Sector | Infra & APIs | Infra & APIs |
| Velocity score | 5.0 | 5.0 |
| Sparks · 30d | 0 | 0 |
| Top themes | cli, local-first, desktop-client, release-rollups | multi-channel-releases, buildah, concurrency-fixes, kubernetes-deploy |
| Last editorial update | 14d ago | 3h ago |
| Website | — | Visit → |
Obsidian's feed has gone quiet: version pointers up top, the bundled CLI the last real move.
The four most recent entries are pointers, not release notes — each says only that the build includes everything up to Obsidian Desktop v1.13.1 through v1.13.4, with no description of what actually changed. The last substantive work visible in this window is from March, when the installer started bundling a dedicated CLI binary instead of invoking the Electron executable, cutting terminal round-trip time and adding shell autocompletion for Obsidian commands. Everything published since is content-free rollup text.
Four channels, one fix stream — werf's releases are mostly concurrency repairs.
werf publishes the same work across alpha, beta, ea, and stable channels plus a 3.x dev line, so a single fix surfaces three or four times under different version numbers. The substance in this window is almost entirely build-engine concurrency: parallel recovery failures, races in Dockerfile builds, concurrent stderr access, serialized base image pulls, retries when a cached image id goes missing. New function is thin — a case-insensitive-condition-tracking feature gate, a build time summary in debug mode, and a registry-side cleanup report.
The four most recent entries are pointers, not release notes — each says only that the build includes everything up to Obsidian Desktop v1.13.1 through v1.13.4, with no description of what actually changed. The last substantive work visible in this window is from March, when the installer started bundling a dedicated CLI binary instead of invoking the Electron executable, cutting terminal round-trip time and adding shell autocompletion for Obsidian commands. Everything published since is content-free rollup text.
Treat the CLI work as the signal and the rollups as noise: a first-class terminal entry point is what lets external tools and scripts drive a vault, which is the difference between a local-first notes app and a substrate other software can build on. The follow-up entries — a macOS path check and a hidden socket dotfile — show the CLI being hardened for real cross-platform use rather than shipped and abandoned. Meanwhile this feed itself has stopped carrying detail, deferring to the desktop release notes it points at.
The visible thread is CLI and TUI ergonomics, so continued work on that surface is the safest read; nothing in these entries supports a confident call beyond it. What is genuinely unclear is whether this feed resumes describing releases or stays a pointer to the desktop changelog.
werf publishes the same work across alpha, beta, ea, and stable channels plus a 3.x dev line, so a single fix surfaces three or four times under different version numbers. The substance in this window is almost entirely build-engine concurrency: parallel recovery failures, races in Dockerfile builds, concurrent stderr access, serialized base image pulls, retries when a cached image id goes missing. New function is thin — a case-insensitive-condition-tracking feature gate, a build time summary in debug mode, and a registry-side cleanup report.
The 3.x dev line is accumulating what 2.x is stabilizing, and the one genuinely new thing in it is a deno binary embedded into werf releases behind a build tag. That is the only entry pointing anywhere beyond maintenance, and it is gated, so its intent is not yet stated. Otherwise the pattern is a mature build tool hardening buildah paths under parallelism, which is where self-hosted CI hits it hardest.
The embedded deno work is the thread to watch — if it stays behind its build tag it is an experiment, and if 3.x ships it on by default it implies a scripting surface for deployment.
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 Obsidian or werf.
Nexus does the diagnosis; the rest is on-call plumbing
1.38.4 is a security release in all but name, closing ACL gaps across the API.
PAM and PKI now take up most of the lines in Infisical's release notes.
Biome's patch train keeps adding rules — and is quietly growing a Markdown linter.
DNSControl is rewriting its record internals in public, one release candidate at a time
Fission's release feed carries only RC tags, and none of them say what shipped
See all Obsidian 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. Obsidian 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. Obsidian 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 Obsidian alternatives in Infra & APIs are ranked by recent ship velocity. Browse the "Obsidian alternatives" section above for the current picks, or visit /alternatives/obsidian 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.