dendrobundle vs Bundlewatch

Bundlewatch is a well-maintained open-source CLI tool that checks your built asset sizes against configured thresholds and posts a pass/fail status to GitHub pull requests. It is the right choice if you want a simple, auditable, self-hosted gate with no SaaS dependency. dendrobundle is a hosted service that goes further: it records every snapshot, renders an interactive module treemap, sends email regression alerts, and gives you a rolling history chart across commits and branches.

dendrobundle vs Bundlewatch, feature by feature

featuredendrobundleBundlewatch
Build-fail budgets (block PR on size threshold)Yes — per-project budgets that fail CIYes — core feature; thresholds per file pattern
Per-commit history and trend chartsYes — every push recorded; history per branchUnverified — service stores data, history scope undocumented (verify)
Interactive module-level treemapYes — drill from total into individual modulesNo
PR comment with size diffNo (in development)Yes — GitHub status check; PR comment via a separate action
Email regression alertsYes (Developer tier)No
Weekly/monthly digest emailsYes (Developer tier)No
README SVG size badgeYesNo
Accepts existing stats files without a pluginYes — webpack/esbuild/rollup-visualizer/source-map-explorerYes — operates on built file paths
Self-host optionNoYes — run your own instance
Open sourceNoYes (MIT)
Free tierYes — 3 projects, 10 rolling snapshots, no cardYes — tool and hosted service are free

Competitor details are researched but change over time — verify against Bundlewatch’s current docs.

Bundlewatch vs dendrobundle — FAQ

Should I use Bundlewatch or dendrobundle?
If you want a fully self-hosted, auditable OSS tool that simply gates PRs on file size — with no need for history charts, treemap drill-down, or email notifications — Bundlewatch is a solid, zero-cost choice. If you want to track how your bundle evolved across dozens of commits, get emailed when a specific chunk grows past its budget, or hand a non-engineer a visual treemap, dendrobundle does that without you building the infrastructure.
Can I migrate from Bundlewatch to dendrobundle?
Yes. The webpack stats, esbuild metafile, or other bundler artifact you already produce is the input dendrobundle reads. Replace the Bundlewatch CI step with a single curl to the push endpoint, or drop in the GitHub Action. Historical Bundlewatch data cannot be imported, so you start fresh from the point of migration.
When is Bundlewatch the better choice?
Bundlewatch is the better choice when your team requires an open-source, self-hostable tool with no external data dependency, when you are building a library with strict package size constraints, or when your organisation's data policy prohibits sending build artifacts to a third-party SaaS.

Start tracking for free — the Community plan covers 3 projects at no cost, no credit card required.

create a free account