Migration guides

Moving from another visual-regression or snapshot tool? Dungbeetle is the actively-maintained, self-hostable home for teams that already chose open tooling — several of the OSS incumbents are now archived, sunsetting, or drifting.

These guides map each tool's concepts onto Dungbeetle and walk you through a clean switch.

Coming from	Status today	Guide
Lost Pixel	Sunsetting — repo archived Apr 2026 (team joined Figma); SaaS winding down	Migrate from Lost Pixel
Wraith (BBC)	Archived / read-only since Jan 2026; PhantomJS-era engine	Migrate from Wraith
BackstopJS	Drifting — no npm release in ~12 months (maintenance "inactive")	Migrate from BackstopJS
Loki	Alive but pre-1.0, single-maintainer, Storybook-only	Migrate from Loki

Why teams switch

All four tools above share the same two gaps — the same two things Dungbeetle was built to fix:

• Pixel-only diffs are flaky. They re-render the whole page to a PNG and compare bytes, so a font hint, an anti-alias edge, or a 1px reflow trips a failure. Dungbeetle's primary snapshot is a structured tree (DOM / accessibility / terminal / performance) diffed node-by-node — a real text or attribute change reads as "$42.00" → "$58.00", not a wall of red pixels. Pixel screenshots are still available as a tolerant fallback when you want them.
• No central review. Their baselines are PNGs committed to git and approved from a local CLI; there's no shared, audited place to review changes across repos. Dungbeetle's cloud server adds hosted baselines, a review / approve / promote UI, an append-only audit trail, and flakiness analytics — self-hostable, or managed. (Lost Pixel had this, but only in the SaaS that's shutting down.)

Plus the obvious: Dungbeetle is maintained, uses a modern Playwright/Chromium capture path (no PhantomJS), and the managed cloud is flat and unmetered — no per-screenshot bill. See Pricing.

The shape of every migration

The steps are the same regardless of which tool you're leaving:

1. Install Dungbeetle and scaffold a config — see Installation.

   npm install -g dungbeetle
   dungbeetle init

2. Translate your config — each guide maps your tool's fields (URLs, viewports, thresholds, ignored regions) to dungbeetle.config.json.
3. Re-baseline. Capture fresh baselines with dungbeetle update and commit them.

   dungbeetle update     # writes baselines under dungbeetle.snapshots/
   dungbeetle test       # compare against them

4. Wire CI — swap your old test step for dungbeetle ci.
5. (Optional) Go hosted — push runs and baselines to a Dungbeetle cloud server for central review and analytics.

Why re-baseline instead of importing old references?

Your existing baselines are PNG images. Dungbeetle's primary baseline is a structured snapshot, not a pixel buffer — so there's nothing to import 1:1; a fresh dungbeetle update is both required and the better starting point (you get structural diffs from day one). For screenshot-only parity you can enable Dungbeetle's screenshot fallback.

Not listed?

The same pattern works for any URL- or component-screenshot tool (reg-suit, Playwright's built-in snapshots, Percy/Chromatic exports). Start with Quick start and the configuration reference, or open an issue and tell us what you're coming from.