Self-Hosted Visual Regression Testing: BackstopJS vs. Argos (and What Happened to Lost Pixel)

Forestil dig, at du standardiserer din CI på et af de tre open source-værktøjer til visuel regressionstestning, som alle sætter på deres shortliste (BackstopJS, Argos, Lost Pixel), og en uge inde i undersøgelsen opdager, at to af de tre ikke er, hvad de så ud til udefra. Argos har fremragende kode på GitHub, men vedligeholderen siger ligeud, at self-hosting hverken er understøttet eller dokumenteret. Lost Pixel blev arkiveret den 22. april 2026, da holdet gik til Figma, og leverede ingen migreringssti til de teams, der allerede brugte det.

Det efterlader præcis et af de tre, som reelt er self-hostbart og vedligeholdt i dag. Hvilket er en mærkelig ting at sige om en kategori med så meget tilsyneladende valg, men sådan ser landskabet faktisk ud. De værktøjer, folk behandler som tre ligeværdige, er i praksis en fungerende self-hosted mulighed, et stærkt værktøj, der lever på andres servere, og et, du bør være ved at migrere væk fra.

Dette er en self-hosting-først læsning af de self-hosted værktøjer til visuel regressionstestning, der overlever mødet med virkeligheden: hvilket passer til hvilken begrænsning, og hvad du skal gøre, hvis du er på Lost Pixel lige nu.

Den korte version

• BackstopJS er den self-hostbare, vedligeholdte, MIT-licenserede mulighed uden omkostninger. Puppeteer som standard med Playwright-understøttelse, pixel-diffing via Resemble.js og et HTML-review-UI (med forbehold ved Docker-rendering, som du skal planlægge efter).
• Argos er det stærkere værktøj på workflow (PR-review og ARIA-snapshot-diffing siden slutningen af 2025), men det er i praksis en administreret SaaS. Vedligeholderen tilbyder hverken support eller dokumentation til at køre det selv.
• Lost Pixel blev arkiveret i april 2026. Tag det ikke i brug til nyt arbejde, og hvis du er på det, så planlæg din migrering nu.

Dommen på én linje: til en fuldt self-hosted CI-pipeline er BackstopJS det praktiske valg. Vil du have det bedste review-workflow og kan acceptere en SaaS-afhængighed, er Argos det bedre værktøj.

(Hvad dette ikke dækker: Cypress-baseret visuel testning, Storybook-specifikke komponent-workflows og selvmålte ydelsestal. Denne sammenligning er bygget på fakta fra primærkilder, ikke på en testopstilling, jeg selv har kørt.)

Landskabet for self-hosted visuel regressionstestning har ændret sig

To konkrete begivenheder i det seneste år har omformet denne shortliste, og begge er lette at overse, hvis du arbejder ud fra en liste skrevet, før de skete.

Den første: i en GitHub-diskussion fra september 2025erklærede en Argos-vedligeholder, at Argos ikke tilbyder support eller dokumentation til at køre det uden for den administrerede tjeneste. Koden er MIT-licenseret og ligger åbent, så "du kan self-hoste det" er teknisk sandt, men der er ingen understøttet sti, en skelnen, der bliver enormt vigtig, så snart du er den, der har vagten for det.

Den anden: Lost Pixel-repositoriet blev arkiveret den 22. april 2026, skrivebeskyttet, da holdet meddelte, at det gik til Figma. Ingen migreringsvejledning fulgte med lukningen. Et værktøj, der indtil for nylig var et legitimt gratis self-hosted alternativ til Percy og Chromatic, er nu en afhængighed uden vedligeholder.

Begge ændringer peger i samme retning. Grunden til, at teams ender her i første omgang, SaaS-priser, der vokser med browsere gange viewports gange sider, eller en compliance-regel mod at uploade skærmbilleder af ikke-udgivet UI til en tredjepart, er ikke forsvundet. Det, der har ændret sig, er, at det self-hosted menukort er kortere, end det ser ud.

Afsnittets hovedpointe: Kun et af de tre værktøjer, folk sætter på shortlisten, er i dag reelt self-hostbart og aktivt vedligeholdt.

BackstopJS: den reelt self-hostbare mulighed

Installationen er npm install -g backstopjs (eller en lokal projektinstallation), og det ene faktum forklarer det meste af, hvorfor BackstopJS vinder på self-hosting-aksen: der er ingen tjeneste at reverse-engineere, ingen administreret backend, som den i hemmelighed afhænger af. Den kører som en npm-pakke eller en Docker-container på infrastruktur, du selv styrer, under MIT-licens, uden licensomkostninger. README noterer, at den nuværende linje (6.3.x) understøtter Node 20.

Under motorhjelmen driver den Puppeteer som standard (headless Chrome) og understøtter også Playwright på tværs af chromium, firefox og webkit. Diffing er pixelbaseret via Resemble.js, med en konfigurerbar værdi misMatchThreshold der styrer, hvor meget pixelafvigelse der tæller som en fejl. Godkendelser sker via en HTML-rapport med et in-browser-UI til at acceptere ændringerne.

Begrænsningerne er der, hvor en strategisk beslutning træffes. BackstopJS har intet indbygget PR-blokerende workflow: det fortæller dig, at en diff findes, men at koble det til en "denne PR må ikke merges"-port er op til dig. Konfigurationen lever i JSON, ét scenarie ad gangen, og ved et par hundrede testtilfælde bliver den JSON selv en vedligeholdelsesflade. Udviklingen er langsom snarere end hurtig: projektet er ikke arkiveret, pakken ligger i øjeblikket på version 6.3.25, og repositoriet viser cirka 7.200 GitHub-stjerner og 516 åbne issues. Behandl derfor BackstopJS som modent og brugbart, ikke som en hurtigt udviklende platform til visuel testning.

Den skarpeste driftsrisiko er Docker-rendering. To issues, hvide eller afskårne skærmbilleder i Docker (#1156) og inkonsistente resultater efter Docker-opgraderingen til v5.3.0 (#1303), har stået åbne i årevis uden løsning. Docker er samtidig præcis det, du vil have til CI, fordi det normaliserer rendering på tværs af maskiner. Så det værktøj, der giver dig mest kontrol, giver dig også en kendt, uløst klasse af ustabilitet i netop den opsætning, du kommer til at køre det i. Det er en risiko, der kan planlægges efter, ikke en dealbreaker, men den bør på bordet, før du binder dig.

Pro-tip: fælden med baselines på tværs af styresystemer. Hvis dine udviklere tager baselines på macOS og dine CI-runnere er Linux, vil dine tests fejle alene på grund af forskelle i font-anti-aliasing, før der overhovedet findes en reel regression. Som en fagperson har dokumenteret, adskiller font-rendering sig mellem det Linux-image, CI-tjenester bruger, og en lokal macOS-maskine, nok til at få en visuel test til at fejle af sig selv. Løsningen er at generere og sammenligne baselines i ét miljø (kør BackstopJS lokalt i det samme Docker-image, som du bruger i CI), så reference- og sammenligningsbillederne kommer fra identisk rendering.

Argos: det bedste workflow, men i praksis SaaS

Argos rammer review-oplevelsen på en måde, som BackstopJS ikke gør, og det er hele grunden til, at det er på denne liste trods self-hosting-forbeholdet. Det integrerer med Playwright, Cypress, Storybook, WebdriverIO og Puppeteer og kobler til GitHub Actions, GitLab CI, Bitbucket og Azure DevOps. PR-review-workflowet er en førsteklasses produktflade, og det er blevet ved med at bevæge sig. Nylige changelog-poster tilføjer kollaborative reviews med fastgjorte kommentarer (juni 2026) og automatisk ignorering af ustabile ændringer.

Dens mest interessante tekniske differentiator er diffing. Oven på deterministisk pixel-diffing tilføjede Argos ARIA-snapshot-diffing til sit Playwright-SDK den 4. november 2025. ARIA-snapshot-diffing sammenligner tilgængelighedstræet (roller, labels og struktur) sammen med pixel-skærmbilledet, hvilket fanger en klasse af semantiske og tilgængeligheds-regressioner, som et rent pixel-diff kan overse (en knap, der stadig ser identisk ud, men har mistet sit tilgængelige label, for eksempel). For teams med tilgængelighedsforpligtelser er det en reel evne, som de rene pixel-værktøjer ikke tilbyder.

Så kommer begrænsningen. Koden er MIT, men produktet er den administrerede tjeneste, og vedligeholderen har været tydelig om, at self-hosting er udokumenteret og ikke understøttet. Du kan stille det op fra kildekoden. Du gør det bare i bevidsthed om, at enhver opstrøms ændring kan bryde dit deployment, og ingen er forpligtet til at hjælpe. Der er en beslægtet usikkerhed, som er værd at fremhæve snarere end at påstå: rapporter fra fællesskabet antyder, at integration med GitLab Self-Managed forventer en Enterprise-plan (jeg behandler det som et fællesskabssignal, ikke en bekræftet specifikation, så verificér det mod din egen opsætning, før det driver en beslutning).

Det skaber et ubehageligt hul. Et team med strenge privatlivskrav (netop det team, der er mest motiveret til at self-hoste), som også vil have Argos' review-oplevelse, har ingen god vej. De kan bruge den administrerede tjeneste og acceptere tredjepartsafhængigheden, eller self-hoste uden support, eller vælge et andet værktøj. Der er ingen ren fjerde dør, og det er mere ærligt at sige det end at lade som om, open source-licensen lukker den.

Afsnittets hovedpointe: Argos er det stærkere værktøj. At self-hoste det er ikke understøttet og driftsmæssigt skrøbeligt.

Lost Pixel: arkiveret, og hvad du skal gøre, hvis du er på det

Selve banneret på Lost Pixel-repositoriet er hele historien på én linje: repositoriet blev arkiveret af ejeren den 22. april 2026 og er nu skrivebeskyttet. Holdet gik til Figma, den seneste udgivelse var v3.22.0 i november 2024, og der blev ikke offentliggjort nogen migreringsvejledning.

Indtil arkiveringen var Lost Pixel et fornuftigt valg (Docker-baseret rendering, understøttelse af Playwright og Storybook plus Ladle og Histoire, og både helsides- og komponentniveau visuel testning). Intet af det ændrede sig teknisk den 22. april. Det, der ændrede sig, er, at det nu ingen vedligeholder, ingen sikkerhedsrettelser og ingen roadmap har, hvilket for en CI-afhængighed er diskvalificerende for nyt arbejde, uanset hvor godt den nuværende version kører.

Hvis du er på det i dag, deler migreringen sig efter, hvordan du brugte det. Hvis du lænede dig op ad dets komponentniveau-testning, især Storybook- eller Ladle-workflows, er din nærmeste erstatning den administrerede Argos-tjeneste eller Playwrights indbyggede skærmbillede-testning. BackstopJS kan fange selektorer eller Storybook-URL'er, men giver dig ikke det samme indbyggede komponent-workflow som Lost Pixel, så du ville skulle modellere de komponenttilstande selv. Hvis du brugte det til helsides visuel regression, er BackstopJS den direkte self-hosted efterfølger. Uanset hvad er flytningen ikke akut i "dine builds bryder i morgen"-forstand, men uret tikker: et ikke-vedligeholdt testværktøj rådner stille, mens versionerne af din browser, dit styresystem og dit framework driver væk fra dem, det sidst blev bygget mod.

Sammenligning ved et hurtigt blik

Her er de samme oplysninger side om side, så du kan skimme de akser, der tæller for en CI-beslutning, før du lægger dem over på dine egne begrænsninger.

Sådan vælger du (beslutningsramme)

Tag udgangspunkt i din hårdeste begrænsning, ikke i en funktionsliste. Begrænsningen fjerner det meste af menukortet for dig.

• Fuldt self-hosted, nul budget, og du kan acceptere kun helsides-testning med manuel review: BackstopJS. Det er den eneste mulighed, der opfylder self-hosted, vedligeholdt og gratis på samme tid, og afvejningerne (ingen PR-port, JSON-konfiguration, Docker-ustabilitet) er kendte størrelser, du kan designe omkring.
• Du vil have den bedste review-oplevelse, PR-gating og ARIA-diffing, og du kan acceptere en SaaS-afhængighed: den administrerede Argos-tjeneste. Dette er vejen til Argos' styrker uden risikoen ved ikke-understøttet self-hosting. Hvis en compliance-regel forbyder upload af skærmbilleder til tredjepart, er denne dør lukket, og du er tilbage ved BackstopJS.
• Lille testsuite eller Playwright-first: overvej slet ikke at tilføje et dedikeret værktøj. Playwright leveres med toHaveScreenshot() indbygget, og for suiter under cirka 100 tests er det måske alt, hvad du behøver. En vejledning fra en fagperson placerer vendepunktet, hvor et dedikeret værktøj begynder at tjene sig ind, omkring den skala (behandl det som en branchobservation, ikke et officielt Playwright-tal). Administrationsbyrden ved baseline-filer i git vokser ud over det punkt, og det er der, et dedikeret værktøj betaler sig.
• Aktuelt på Lost Pixel: migrér nu, ifølge opdelingen i det forrige afsnit. Tag ikke "det virker stadig" som en grund til at blive.

Et forbehold, der ligger forud for alle disse værktøjer og overlever dem: Sparkbox-holdet, der skrev for år tilbage, valgte bevidst en hostet mulighed, netop fordi det var sværere at få ingeniører til faktisk at bruge testene end selve opsætningen. Et self-hosted værktøj med et svagere review-UI kan vinde på pris og tabe på udbredelse (hvis dit team ignorerer en støjende BackstopJS-rapport, har dets nul-licensomkostning ikke givet dig noget). Vej review-oplevelsen ind i beslutningen, ikke kun prisen.

Afsnittets hovedpointe: Begrænsningen vælger værktøjet. Self-hosted og gratis peger på BackstopJS, bedste workflow med acceptabel SaaS peger på Argos, og lille og Playwright-first peger måske på slet intet værktøj.

Dimensionering af CI-runneren til headless Chromium

Alle tre værktøjer driver headless Chromium, og det er hukommelsesaftrykket fra Chromium (ikke CPU'en), der sætter størrelsen på din runner, fordi hver samtidig browser-worker vil have sine egne par gigabyte RAM. Dimensionerer du maskinen for lille, fejler dine visuelle tests ikke rent. De bliver OOM-dræbt midt i kørslen og rapporteret som ustabil infrastrukturstøj, den værste slags fejl at debugge.

Som en omtrentlig rettesnor, dimensioneret efter parallelisme snarere end som hårde tal (det faktiske forbrug afhænger af sidekompleksitet og af, hvor mange workers du kører parallelt):

• Lille team eller serielle tests: omkring 2 vCPU / 4 GB RAM klarer en enkelt headless-Chromium-worker med CI-daemon-overhead.
• CI-brug i team: omkring 4 vCPU / 8 GB RAM understøtter cirka 2 til 4 parallelle browser-workers, hvor de fleste teams lander.
• Høj gennemstrømning eller store suiter: omkring 8 vCPU / 16 GB RAM til høj parallelisme, eller når den visuelle regressionskørsel deler en runner med andet CI-arbejde.

Lagring er den stille post. Skærmbillede-artefakter og historiske baselines hober sig op kørsel efter kørsel, så planlæg efter den vækst: afsæt rigelig lagerplads, hvis du gemmer baselines lokalt, eller skub baselines og artefakter til objektlagring, så runnerens disk ikke er flaskehalsen.

En VPS er den naturlige vært for en self-hosted CI-runner, der gør dette, fordi du vil have forudsigelig, dedikeret RAM til Chromium-workerne, og en homelab-maskine giver kun mening, hvis hardwaren allerede står der. Hvis du også sætter den omgivende CI-stak op, er delene omkring det visuelle testværktøj et-klik-deployments i Cloudzy-marketplace: Gitea, GitLab, Jenkins og Forgejo til CI-forgen, og Docker til den rendering-konsistens, værktøjerne har brug for. Selve det visuelle regressionsværktøj installeres ovenpå via npm eller Docker, så sæt en Linux VPS op, dimensioneret efter intervallerne ovenfor, og kør det der. Hvis du kobler Docker-baseret CI sammen, dækker Cloudzy-vejledningerne om self-hostede GitLab-alternativer og opremsning af Docker-containere den tilstødende opsætning.

Ofte stillede spørgsmål

Er Argos self-hostbart?

Teknisk ja (koden er MIT-licenseret), men vedligeholderen erklærede i september 2025, at Argos ikke tilbyder support eller dokumentation til at køre det uden for den administrerede tjeneste. Behandl self-hosting som ikke understøttet og driftsmæssigt skrøbeligt: det kan bryde ved enhver opstrøms ændring, uden at nogen vedligeholder er forpligtet til at hjælpe. For de fleste teams er den administrerede tjeneste den praktiske måde at få fordelene ved Argos.

Hvad skete der med Lost Pixel?

Lost Pixel blev arkiveret den 22. april 2026, da holdet gik til Figma og lukkede produktet. Repositoriet er skrivebeskyttet, den seneste udgivelse var v3.22.0 i november 2024, og der blev ikke leveret nogen migreringsvejledning. Tag det ikke i brug til nyt arbejde. Hvis du bruger det, så planlæg en migrering til BackstopJS (helsides-testning) eller til Argos og Playwright-native (komponenttestning).

Hvad er ARIA-snapshot-diffing?

ARIA-snapshot-diffing sammenligner tilgængelighedstræet (roller, labels og struktur) sammen med pixel-skærmbilledet og fanger semantiske og tilgængeligheds-regressioner, som et pixel-diff alene kan overse, såsom en visuelt identisk knap, der har mistet sit tilgængelige label. Argos tilføjede funktionen den 4. november 2025.

Hvor meget RAM kræver headless Chromium i CI?

En enkelt seriel worker kører typisk på omkring 2 til 4 GB, og samtidige workers skalerer RAM nogenlunde lineært derfra. Det faktiske forbrug afhænger af sidekompleksitet og af, hvor mange browser-instanser du kører parallelt, så behandl disse tal som rettesnore snarere end hårde tal, og lad plads for at undgå OOM-dræbte testkørsler.

Understøtter BackstopJS Playwright?

Ja. Puppeteer er standardmotoren (headless Chrome), og BackstopJS understøtter også Playwright på tværs af chromium, firefox og webkit. Motoren vælger du i din konfiguration.