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

Wyobraź sobie, że standaryzujesz swoje CI na jednym z trzech narzędzi wizualnego testowania regresji o otwartym kodzie, które wszyscy umieszczają na krótkiej liście (BackstopJS, Argos, Lost Pixel), i tydzień po rozpoczęciu analizy odkrywasz, że dwa z trzech nie są tym, na co wyglądały z zewnątrz. Argos ma świetny kod na GitHubie, ale jego opiekun wprost mówi, że self-hosting nie jest ani wspierany, ani udokumentowany. Lost Pixel został zarchiwizowany 22 kwietnia 2026 roku, gdy zespół dołączył do Figmy, i nie zapewnił żadnej ścieżki migracji zespołom, które już go używały.

To pozostawia dokładnie jedno z trzech, które dziś naprawdę można hostować samodzielnie i które jest utrzymywane. Co jest dziwne do powiedzenia o kategorii z tak pozornie dużym wyborem, ale tak właśnie wygląda ten krajobraz. Narzędzia, które ludzie traktują jak trzy równorzędne, w praktyce to jedna działająca opcja self-hosted, jedno mocne narzędzie żyjące na cudzych serwerach i jedno, z którego powinieneś migrować.

To spojrzenie z priorytetem na self-hosting na te samodzielnie hostowane narzędzia wizualnego testowania regresji, które przetrwają zderzenie z rzeczywistością: które pasuje do jakiego ograniczenia i co zrobić, jeśli jesteś teraz na Lost Pixel.

Krótka wersja

• BackstopJS to samodzielnie hostowalna, utrzymywana, licencjonowana na MIT opcja bez kosztów. Puppeteer domyślnie ze wsparciem Playwright, porównywanie pikseli przez Resemble.js i interfejs przeglądu HTML (z zastrzeżeniami co do renderowania w Dockerze, które trzeba zaplanować).
• Argos to mocniejsze narzędzie pod względem przepływu pracy (przegląd PR i porównywanie migawek ARIA od końca 2025 roku), ale w praktyce to zarządzany SaaS. Opiekun nie zapewnia ani wsparcia, ani dokumentacji do samodzielnego uruchomienia.
• Lost Pixel został zarchiwizowany w kwietniu 2026 roku. Nie wdrażaj go do nowej pracy, a jeśli go używasz, zaplanuj migrację już teraz.

Werdykt w jednej linii: dla w pełni samodzielnie hostowanego potoku CI BackstopJS to praktyczny wybór. Jeśli chcesz najlepszy przepływ przeglądu i możesz zaakceptować zależność od SaaS, Argos to lepsze narzędzie.

(Czego to nie obejmuje: testowania wizualnego opartego na Cypress, specyficznych dla Storybooka przepływów komponentów i zmierzonych ręcznie liczb wydajności. To porównanie zbudowane jest na faktach ze źródeł pierwotnych, a nie na stanowisku testowym, które sam uruchomiłem.)

Krajobraz samodzielnie hostowanego wizualnego testowania regresji się zmienił

Dwa konkretne wydarzenia w ostatnim roku przekształciły tę krótką listę, i oba łatwo przeoczyć, jeśli pracujesz na podstawie listy artykułowej napisanej przed nimi.

Pierwsze: w dyskusji na GitHubie we wrześniu 2025 rokuopiekun Argos oświadczył, że Argos nie zapewnia ani wsparcia, ani dokumentacji do uruchamiania go poza zarządzaną usługą. Kod jest licencjonowany na MIT i leży otwarcie, więc „możesz go hostować samodzielnie” jest technicznie prawdą, ale nie ma wspieranej ścieżki, rozróżnienie, które staje się ogromnie ważne, gdy to ty jesteś osobą na dyżurze do niego.

Drugie: repozytorium Lost Pixel zostało zarchiwizowane 22 kwietnia 2026 roku, tylko do odczytu, gdy zespół ogłosił, że dołącza do Figmy. Zamknięciu nie towarzyszył żaden przewodnik migracji. Narzędzie, które do niedawna było legalną darmową samodzielnie hostowaną alternatywą dla Percy i Chromatic, jest teraz zależnością bez opiekuna.

Obie zmiany wskazują w tym samym kierunku. Powód, dla którego zespoły w ogóle tu trafiają, cennik SaaS rosnący jak przeglądarki razy okna widokowe razy strony, albo reguła zgodności zakazująca przesyłania zrzutów ekranu niewydanego interfejsu do strony trzeciej, nie zniknął. Zmieniło się to, że menu self-hosted jest krótsze, niż wygląda.

Kluczowy wniosek z sekcji: Tylko jedno z trzech narzędzi, które ludzie umieszczają na krótkiej liście, jest dziś naprawdę samodzielnie hostowalne i aktywnie utrzymywane.

BackstopJS: naprawdę samodzielnie hostowalna opcja

Instalacja to npm install -g backstopjs (albo lokalna instalacja projektowa), i ten jeden fakt wyjaśnia większość tego, dlaczego BackstopJS wygrywa na osi self-hostingu: nie ma usługi do odtworzenia wstecznego, nie ma zarządzanego backendu, od którego potajemnie zależy. Działa jako pakiet npm lub kontener Docker na infrastrukturze, którą kontrolujesz, na licencji MIT, przy zerowym koszcie licencji. README zaznacza, że bieżąca linia (6.3.x) wspiera Node 20.

Pod maską domyślnie steruje Puppeteer (headless Chrome), a także wspiera Playwright w chromium, firefox i webkit. Porównywanie jest oparte na pikselach przez Resemble.js, z konfigurowalną wartością misMatchThreshold która steruje tym, jakie odchylenie pikseli liczy się jako porażka. Zatwierdzenia odbywają się przez raport HTML z interfejsem w przeglądarce do akceptowania zmian.

Ograniczenia to miejsce, gdzie zapada strategiczna decyzja. BackstopJS nie ma wbudowanego przepływu blokowania PR: powie ci, że różnica istnieje, ale wpięcie tego w bramkę „ten PR nie może zostać scalony” należy do ciebie. Jego konfiguracja żyje w JSON, po jednym scenariuszu naraz, i przy kilkuset przypadkach testowych ten JSON sam staje się powierzchnią utrzymania. Rozwój jest raczej powolny niż szybki: projekt nie jest zarchiwizowany, pakiet obecnie jest na wersji 6.3.25, a repozytorium pokazuje około 7200 gwiazdek na GitHubie i 516 otwartych zgłoszeń. Traktuj więc BackstopJS jako dojrzały i użyteczny, a nie jako szybko rozwijającą się platformę testowania wizualnego.

Najostrzejsze ryzyko operacyjne to renderowanie w Dockerze. Dwa zgłoszenia, białe lub obcięte zrzuty ekranu w Dockerze (#1156) oraz niespójne wyniki po aktualizacji Dockera do v5.3.0 (#1303), pozostają otwarte od lat bez rozwiązania. Docker jest zarazem dokładnie tym, czego chcesz do CI, ponieważ normalizuje renderowanie między maszynami. Tak więc narzędzie, które daje ci najwięcej kontroli, wręcza ci też znaną, nienaprawioną klasę niestabilności dokładnie w tej konfiguracji, w której będziesz je uruchamiać. To ryzyko, które można zaplanować, a nie czynnik dyskwalifikujący, ale powinno leżeć na stole, zanim się zaangażujesz.

Porada: pułapka baselinów międzysystemowych. Jeśli twoi programiści robią baseline na macOS, a twoje runnery CI to Linux, twoje testy będą padać już przez same różnice w wygładzaniu czcionek, zanim jeszcze zaistnieje jakakolwiek prawdziwa regresja. Jak udokumentowałpewien praktyk, renderowanie czcionek różni się między obrazem Linux używanym w usługach CI a lokalną maszyną macOS, na tyle, by wizualny test padł sam z siebie. Rozwiązaniem jest generowanie i porównywanie baselinów w jednym środowisku (uruchamiaj BackstopJS lokalnie w tym samym obrazie Docker, którego używasz w CI), aby obrazy referencyjne i porównawcze pochodziły z identycznego renderowania.

Argos: najlepszy przepływ pracy, ale w praktyce SaaS

Argos trafia w doświadczenie przeglądu w sposób, w jaki BackstopJS-owi się nie udaje, i to cały powód, dla którego jest na tej liście mimo zastrzeżenia co do self-hostingu. Integruje się z Playwright, Cypress, Storybook, WebdriverIO i Puppeteer oraz podłącza się do GitHub Actions, GitLab CI, Bitbucket i Azure DevOps. Przepływ przeglądu PR to pierwszorzędna powierzchnia produktu, i wciąż się rozwijał. Świeże wpisy w dzienniku zmian dodają wspólne przeglądy z przypiętymi komentarzami (czerwiec 2026 roku) i automatyczne ignorowanie niestabilnych zmian.

Jego najciekawszym technicznym wyróżnikiem jest porównywanie. Na wierzchu deterministycznego porównywania pikseli Argos dodał porównywanie migawek ARIA dla swojego SDK Playwright 4 listopada 2025 roku. Porównywanie migawek ARIA zestawia drzewo dostępności (role, etykiety i strukturę) obok zrzutu pikseli, co wyłapuje klasę regresji semantycznych i dostępności, które czyste porównanie pikseli może przeoczyć (na przykład przycisk, który wciąż wygląda identycznie, ale stracił swoją dostępną etykietę). Dla zespołów ze zobowiązaniami wobec dostępności to prawdziwa możliwość, której narzędzia tylko-pikselowe nie oferują.

Potem ograniczenie. Kod to MIT, ale produktem jest zarządzana usługa, a opiekun jasno stwierdził, że self-hosting jest nieudokumentowany i niewspierany. Możesz postawić go ze źródeł. Robisz to tylko ze świadomością, że każda zmiana w górze strumienia może zepsuć twoje wdrożenie i nikt nie jest zobowiązany pomóc. Jest powiązana niepewność, którą warto zaznaczyć, a nie stwierdzać: doniesienia społeczności sugerują, że integracja z GitLab Self-Managed oczekuje planu Enterprise (traktuję to jako sygnał społeczności, a nie potwierdzoną specyfikację, więc zweryfikuj to na własnej konfiguracji, zanim to napędzi decyzję).

To rodzi niewygodną lukę. Zespół ze ścisłymi wymaganiami prywatności (dokładnie ten zespół, który jest najbardziej zmotywowany do self-hostingu), który chce też doświadczenia przeglądu Argos, nie ma dobrej ścieżki. Mogą użyć zarządzanej usługi i zaakceptować zależność od strony trzeciej, albo hostować samodzielnie bez wsparcia, albo wybrać inne narzędzie. Nie ma czystych czwartych drzwi, i uczciwiej to nazwać, niż udawać, że licencja open source je zamyka.

Kluczowy wniosek z sekcji: Argos to mocniejsze narzędzie. Hostowanie go samodzielnie nie jest wspierane i jest operacyjnie kruche.

Lost Pixel: zarchiwizowany, i co zrobić, jeśli jesteś na nim

Własny baner repozytorium Lost Pixel to cała historia w jednej linii: repozytorium zostało zarchiwizowane przez właściciela 22 kwietnia 2026 roku i jest teraz tylko do odczytu. Zespół dołączył do Figmy, ostatnie wydanie to v3.22.0 w listopadzie 2024 roku, i nie opublikowano żadnego przewodnika migracji.

Do archiwizacji Lost Pixel był rozsądnym wyborem (renderowanie oparte na Dockerze, wsparcie dla Playwright i Storybook plus Ladle i Histoire, oraz testowanie wizualne zarówno pełnostronicowe, jak i na poziomie komponentów). Nic z tego nie zmieniło się technicznie 22 kwietnia. Zmieniło się to, że teraz nie ma opiekuna, nie ma łatek bezpieczeństwa i nie ma mapy drogowej, co dla zależności CI jest dyskwalifikujące dla nowej pracy niezależnie od tego, jak dobrze działa bieżąca wersja.

Jeśli jesteś na nim dzisiaj, migracja dzieli się według tego, jak go używałeś. Jeśli polegałeś na jego testowaniu na poziomie komponentów, zwłaszcza na przepływach Storybook lub Ladle, twoim najbliższym zamiennikiem jest zarządzana usługa Argos albo natywne testowanie zrzutów ekranu w Playwright. BackstopJS potrafi przechwycić selektory lub adresy URL Storybooka, ale nie daje ci tego samego wbudowanego przepływu komponentów, co dawał Lost Pixel, więc musiałbyś sam modelować te stany komponentów. Jeśli używałeś go do pełnostronicowej regresji wizualnej, BackstopJS to bezpośredni samodzielnie hostowany następca. Tak czy inaczej, przejście nie jest pilne w sensie „twoje kompilacje zepsują się jutro”, ale zegar tyka: nieutrzymywane narzędzie testowe cicho gnije, w miarę jak wersje twojej przeglądarki, systemu operacyjnego i frameworka oddalają się od tych, pod które było ostatnio budowane.

Porównanie w skrócie

Oto ta sama informacja obok siebie, byś mógł przejrzeć osie ważne dla decyzji o CI, zanim nałożysz je na własne ograniczenia.

Jak wybierać (rama decyzyjna)

Wyjdź od swojego najtwardszego ograniczenia, a nie od listy funkcji. Ograniczenie wykreśla większość menu za ciebie.

• W pełni self-hosted, zerowy budżet, i możesz zaakceptować testowanie tylko pełnostronicowe z ręcznym przeglądem: BackstopJS. To jedyna opcja, która jednocześnie spełnia self-hosted, utrzymywany i darmowy, a kompromisy (bez bramki PR, konfiguracja w JSON, niestabilność Dockera) to znane wielkości, wokół których możesz projektować.
• Chcesz najlepszego doświadczenia przeglądu, bramkowania PR i porównywania ARIA, i możesz zaakceptować zależność od SaaS: zarządzana usługa Argos. To ścieżka do mocnych stron Argos bez ryzyka niewspieranego self-hostingu. Jeśli reguła zgodności zabrania przesyłania zrzutów ekranu do strony trzeciej, te drzwi są zamknięte, i wracasz do BackstopJS.
• Mały zestaw testów albo Playwright na pierwszym miejscu: rozważ, by w ogóle nie dodawać dedykowanego narzędzia. Playwright dostarcza toHaveScreenshot() natywnie, a dla zestawów poniżej mniej więcej 100 testów może to być wszystko, czego potrzebujesz. Pewien przewodnik praktyka umieszcza punkt przełomowy, w którym dedykowane narzędzie zaczyna się opłacać, mniej więcej na tej skali (traktuj to jako obserwację branżową, a nie oficjalną liczbę Playwright). Narzut zarządzania plikami baseline w git rośnie poza tym punktem, i to właśnie tam dedykowane narzędzie się zwraca.
• Obecnie na Lost Pixel: migruj teraz, zgodnie z podziałem z poprzedniej sekcji. Nie traktuj „wciąż działa” jako powodu, by zostać.

Zastrzeżenie, które poprzedza wszystkie te narzędzia i je przeżywa: zespół Sparkbox, piszący lata temu, wybrał opcję hostowaną właśnie dlatego, że nakłonienie inżynierów, by naprawdę używali testów, było trudniejsze niż sama konfiguracja. Samodzielnie hostowane narzędzie ze słabszym interfejsem przeglądu może wygrać na koszcie i przegrać na adopcji (jeśli twój zespół ignoruje hałaśliwy raport BackstopJS, jego zerowy koszt licencji nic ci nie dał). Uwzględnij doświadczenie przeglądu w decyzji, a nie tylko cenę.

Kluczowy wniosek z sekcji: Ograniczenie wybiera narzędzie. Self-hosted i darmowy wskazuje na BackstopJS, najlepszy przepływ pracy przy akceptowalnym SaaS wskazuje na Argos, a mały i Playwright na pierwszym miejscu może wskazywać w ogóle na żadne narzędzie.

Dobór rozmiaru runnera CI pod headless Chromium

Wszystkie trzy narzędzia sterują headless Chromium, i to ślad pamięciowy Chromium (a nie CPU) wyznacza rozmiar twojego runnera, ponieważ każdy równoległy worker przeglądarki chce swoich kilku gigabajtów RAM. Zaniż rozmiar maszyny, a twoje testy wizualne nie padają czysto. Zabija je OOM w połowie przebiegu i są raportowane jako niestabilny szum infrastruktury, najgorszy rodzaj awarii do debugowania.

Jako przybliżona wskazówka, wymiarowana według równoległości, a nie jako sztywne liczby (faktyczne użycie zależy od złożoności strony i od tego, ilu workerów uruchamiasz równolegle):

• Mały zespół albo testy szeregowe: około 2 vCPU / 4 GB RAM obsłuży jednego workera headless Chromium wraz z narzutem demona CI.
• Zespołowe użycie CI: około 4 vCPU / 8 GB RAM wspiera mniej więcej 2 do 4 równoległych workerów przeglądarki, gdzie ląduje większość zespołów.
• Wysoka przepustowość albo duże zestawy: około 8 vCPU / 16 GB RAM dla wysokiej równoległości, albo gdy przebieg regresji wizualnej dzieli runnera z inną pracą CI.

Pamięć masowa to cicha pozycja. Artefakty zrzutów ekranu i historyczne baseline'y kumulują się przebieg po przebiegu, więc planuj ten wzrost: załóż hojny zapas pamięci masowej, jeśli trzymasz baseline'y lokalnie, albo wypychaj baseline'y i artefakty do magazynu obiektowego, żeby dysk runnera nie był ograniczeniem.

VPS to naturalny host dla samodzielnie hostowanego runnera CI robiącego to, ponieważ chcesz przewidywalnego, dedykowanego RAM dla workerów Chromium, a maszyna homelab ma sens tylko wtedy, gdy sprzęt już stoi. Jeśli stawiasz też otaczający stos CI, elementy wokół narzędzia testowania wizualnego to wdrożenia jednym kliknięciem w marketplace Cloudzy: Gitea, GitLab, Jenkins i Forgejo dla forge CI oraz Docker dla spójności renderowania, której potrzebują narzędzia. Samo narzędzie regresji wizualnej instaluje się na wierzchu przez npm lub Docker, więc uruchom Linux VPS wymiarowany według zakresów powyżej i uruchamiaj go tam. Jeśli spinasz CI oparte na Dockerze, przewodniki Cloudzy o samodzielnie hostowanych alternatywach dla GitLab oraz listowaniu kontenerów Docker obejmują sąsiadującą konfigurację.

Często zadawane pytania

Czy Argos jest samodzielnie hostowalny?

Technicznie tak (kod jest licencjonowany na MIT), ale opiekun oświadczył we wrześniu 2025 roku, że Argos nie zapewnia ani wsparcia, ani dokumentacji do uruchamiania go poza zarządzaną usługą. Traktuj self-hosting jako niewspierany i operacyjnie kruchy: może się zepsuć przy każdej zmianie w górze strumienia, a żaden opiekun nie jest zobowiązany pomóc. Dla większości zespołów zarządzana usługa to praktyczny sposób na uzyskanie korzyści z Argos.

Co stało się z Lost Pixel?

Lost Pixel został zarchiwizowany 22 kwietnia 2026 roku, gdy zespół dołączył do Figmy i zamknął produkt. Repozytorium jest tylko do odczytu, ostatnie wydanie to v3.22.0 w listopadzie 2024 roku, i nie dostarczono żadnego przewodnika migracji. Nie wdrażaj go do nowej pracy. Jeśli go używasz, zaplanuj migrację do BackstopJS (testowanie pełnostronicowe) lub do Argos i Playwright-natywnego (testowanie komponentów).

Czym jest porównywanie migawek ARIA?

Porównywanie migawek ARIA zestawia drzewo dostępności (role, etykiety i strukturę) obok zrzutu pikseli i wyłapuje regresje semantyczne i dostępności, które porównanie pikseli samo w sobie może przeoczyć, jak wizualnie identyczny przycisk, który stracił swoją dostępną etykietę. Argos dodał tę funkcję 4 listopada 2025 roku.

Ile RAM potrzebuje headless Chromium w CI?

Pojedynczy worker szeregowy zwykle działa na około 2 do 4 GB, a workery równoległe skalują RAM stamtąd mniej więcej liniowo. Faktyczne użycie zależy od złożoności strony i od tego, ile instancji przeglądarki uruchamiasz równolegle, więc traktuj te wartości jako wskazówki, a nie sztywne liczby, i zostaw zapas, by uniknąć zabitych przez OOM przebiegów testów.

Czy BackstopJS wspiera Playwright?

Tak. Puppeteer to domyślny silnik (headless Chrome), a BackstopJS wspiera też Playwright w chromium, firefox i webkit. Silnik wybierasz w swojej konfiguracji.