Stell dir vor, du standardisierst deine CI auf eines der drei Open-Source-Tools für visuelle Regressionstests, die jeder in die engere Wahl nimmt (BackstopJS, Argos, Lost Pixel), und stellst eine Woche nach Beginn des Spikes fest, dass zwei der drei nicht das sind, wonach sie von außen aussahen. Argos hat exzellenten Code auf GitHub, aber sein Maintainer sagt klar, dass Self-Hosting weder unterstützt noch dokumentiert ist. Lost Pixel wurde am 22. April 2026 archiviert, als das Team zu Figma wechselte, und lieferte keinen Migrationspfad für die Teams, die es bereits nutzten.
Damit bleibt genau eines der drei, das heute wirklich self-hostbar und gepflegt ist. Was seltsam über eine Kategorie mit so viel scheinbarer Auswahl zu sagen ist, aber genau so sieht die Lage aus. Die Tools, die die Leute als drei Gleichwertige behandeln, sind in der Praxis eine funktionierende self-hosted Option, ein starkes Tool, das auf fremden Servern läuft, und eines, von dem du wegmigrieren solltest.
Dies ist eine self-hosting-orientierte Betrachtung der self-hosted Tools für visuelle Regressionstests, die den Kontakt mit der Realität überleben: welches zu welcher Einschränkung passt und was zu tun ist, wenn du gerade Lost Pixel nutzt.
Die Kurzfassung
- BackstopJS ist die self-hostbare, gepflegte, MIT-lizenzierte Option ohne Kosten. Puppeteer standardmäßig mit Playwright-Unterstützung, Pixel-Diffing über Resemble.js und eine HTML-Review-UI (mit Vorbehalten beim Docker-Rendering, die du einplanen musst).
- Argos ist das stärkere Tool beim Workflow (PR-Review und ARIA-Snapshot-Diffing seit Ende 2025), aber es ist in der Praxis ein verwaltetes SaaS. Der Maintainer bietet weder Support noch Dokumentation dafür, es selbst zu betreiben.
- Lost Pixel wurde im April 2026 archiviert. Setze es nicht für neue Arbeit ein, und wenn du es nutzt, plane jetzt deine Migration.
Das Fazit in einer Zeile: für eine vollständig self-hosted CI-Pipeline ist BackstopJS die praktische Wahl. Wenn du den besten Review-Workflow willst und eine SaaS-Abhängigkeit akzeptieren kannst, ist Argos das bessere Tool.
(Was dies nicht abdeckt: Cypress-basierte visuelle Tests, Storybook-spezifische Komponenten-Workflows und selbst gemessene Performance-Zahlen. Dieser Vergleich stützt sich auf Fakten aus Primärquellen, nicht auf einen Testaufbau, den ich selbst durchgeführt habe.)
Die Landschaft der self-hosted visuellen Regressionstests hat sich verändert
Zwei konkrete Ereignisse im letzten Jahr haben diese Auswahlliste umgeformt, und beide sind leicht zu übersehen, wenn du von einem Listicle ausgehst, das vor ihnen geschrieben wurde.
Das erste: in einer GitHub-Diskussion vom September 2025erklärte ein Argos-Maintainer, dass Argos weder Support noch Dokumentation dafür bietet, es außerhalb des verwalteten Dienstes zu betreiben. Der Code ist MIT-lizenziert und liegt offen, also stimmt "du kannst es selbst hosten" technisch, aber es gibt keinen unterstützten Weg, eine Unterscheidung, die enorm wichtig wird, sobald du derjenige mit Rufbereitschaft dafür bist.
Das zweite: das Lost-Pixel-Repository wurde archiviert am 22. April 2026, schreibgeschützt, als das Team ankündigte, dass es zu Figma wechselt. Keine Migrationsanleitung begleitete die Einstellung. Ein Tool, das bis vor Kurzem eine legitime kostenlose self-hosted Alternative zu Percy und Chromatic war, ist jetzt eine Abhängigkeit ohne Maintainer.
Beide Änderungen weisen in dieselbe Richtung. Der Grund, warum Teams überhaupt hier landen, SaaS-Preise, die mit Browsern mal Viewports mal Seiten wachsen, oder eine Compliance-Regel gegen das Hochladen von Screenshots unveröffentlichter UI zu einem Dritten, ist nicht verschwunden. Verändert hat sich, dass das self-hosted Menü kürzer ist, als es aussieht.
Kernaussage des Abschnitts: Nur eines der drei Tools, die die Leute in die engere Wahl nehmen, ist heute wirklich self-hostbar und wird aktiv gepflegt.
BackstopJS: die wirklich self-hostbare Option
Die Installation ist npm install -g backstopjs (oder eine lokale Projektinstallation), und dieser eine Fakt erklärt zum Großteil, warum BackstopJS auf der Self-Hosting-Achse gewinnt: es gibt keinen Dienst, den man zurückentwickeln müsste, kein verwaltetes Backend, von dem es heimlich abhängt. Es läuft als npm-Paket oder Docker-Container auf einer Infrastruktur, die du kontrollierst, unter MIT-Lizenz, ohne Lizenzkosten. Die README weist darauf hin, dass die aktuelle Linie (6.3.x) Node 20 unterstützt.
Unter der Haube steuert es standardmäßig Puppeteer (headless Chrome) und unterstützt auch Playwright über chromium, firefox und webkit. Das Diffing ist pixelbasiert über Resemble.js, mit einem konfigurierbaren Wert misMatchThreshold der steuert, wie viel Pixel-Abweichung als Fehler zählt. Freigaben erfolgen über einen HTML-Report mit einer In-Browser-UI zum Annehmen der Änderungen.
Die Grenzen sind der Punkt, an dem eine strategische Entscheidung getroffen wird. BackstopJS hat keinen eingebauten PR-Blocking-Workflow: es sagt dir, dass ein Diff existiert, aber das in ein "dieser PR darf nicht gemergt werden"-Gate zu verdrahten, liegt bei dir. Seine Konfiguration lebt in JSON, ein Szenario nach dem anderen, und bei ein paar hundert Testfällen wird dieses JSON selbst zu einer Wartungsfläche. Die Entwicklung ist eher langsam als schnell: das Projekt ist nicht archiviert, das Paket steht aktuell bei Version 6.3.25, und das Repository zeigt rund 7.200 GitHub-Sterne und 516 offene Issues. Behandle BackstopJS also als reif und nutzbar, nicht als sich schnell entwickelnde Plattform für visuelle Tests.
Das schärfste operative Risiko ist das Docker-Rendering. Zwei Issues, weiße oder abgeschnittene Screenshots in Docker (#1156) und inkonsistente Ergebnisse nach dem Docker-Upgrade auf v5.3.0 (#1303), sind seit Jahren ungelöst offen. Docker ist zugleich genau das, was du für die CI willst, weil es das Rendering über Maschinen hinweg normalisiert. So gibt dir das Tool, das dir die meiste Kontrolle gibt, auch eine bekannte, ungelöste Klasse von Instabilität genau in dem Setup, in dem du es ausführen wirst. Das ist ein planbares Risiko, kein K.-o.-Kriterium, aber es gehört auf den Tisch, bevor du dich festlegst.
Profi-Tipp: die betriebssystemübergreifende Baseline-Falle. Wenn deine Entwickler Baselines auf macOS erstellen und deine CI-Runner Linux sind, werden deine Tests allein durch Unterschiede im Font-Anti-Aliasing fehlschlagen, noch bevor eine echte Regression existiert. Wie ein Praktiker dokumentierthat, unterscheidet sich das Font-Rendering zwischen dem in CI-Diensten genutzten Linux-Image und einer lokalen macOS-Maschine genug, um einen visuellen Test von sich aus scheitern zu lassen. Die Lösung ist, Baselines in einer einzigen Umgebung zu erzeugen und zu vergleichen (führe BackstopJS lokal in demselben Docker-Image aus, das du in der CI nutzt), damit Referenz- und Vergleichsbilder aus identischem Rendering stammen.
Argos: der beste Workflow, aber in der Praxis SaaS
Argos trifft das Review-Erlebnis auf eine Weise, wie es BackstopJS nicht schafft, und das ist der ganze Grund, warum es trotz des Self-Hosting-Vorbehalts auf dieser Liste steht. Es integriert sich mit Playwright, Cypress, Storybook, WebdriverIO und Puppeteer und bindet sich an GitHub Actions, GitLab CI, Bitbucket und Azure DevOps an. Der PR-Review-Workflow ist eine erstklassige Produktfläche, und er hat sich weiterentwickelt. Aktuelle Changelog-Einträge ergänzen kollaborative Reviews mit angehefteten Kommentaren (Juni 2026) und das automatische Ignorieren instabiler Änderungen.
Sein interessantestes technisches Alleinstellungsmerkmal ist das Diffing. Zusätzlich zum deterministischen Pixel-Diffing fügte Argos ARIA-Snapshot-Diffing für sein Playwright-SDK am 4. November 2025 hinzu. ARIA-Snapshot-Diffing vergleicht den Accessibility-Baum (Rollen, Labels und Struktur) neben dem Pixel-Screenshot, was eine Klasse semantischer und Accessibility-Regressionen erfasst, die ein reines Pixel-Diff übersehen kann (etwa ein Button, der noch identisch aussieht, aber sein zugängliches Label verloren hat). Für Teams mit Accessibility-Verpflichtungen ist das eine echte Fähigkeit, die die reinen Pixel-Tools nicht bieten.
Dann kommt die Einschränkung. Der Code ist MIT, aber das Produkt ist der verwaltete Dienst, und der Maintainer war deutlich, dass Self-Hosting undokumentiert und nicht unterstützt ist. Du kannst es aus dem Quellcode aufsetzen. Du tust es nur im Wissen, dass jede stromaufwärtige Änderung dein Deployment brechen kann und niemand verpflichtet ist zu helfen. Es gibt eine verwandte Unsicherheit, die man eher benennen als behaupten sollte: Community-Berichte deuten darauf hin, dass die Integration mit GitLab Self-Managed einen Enterprise-Plan erwartet (ich behandle das als Community-Signal, nicht als bestätigte Spezifikation, also prüfe es an deinem eigenen Setup, bevor es eine Entscheidung treibt).
Das erzeugt eine unbequeme Lücke. Ein Team mit strengen Datenschutzanforderungen (genau das Team, das am meisten zum Self-Hosting motiviert ist), das auch das Argos-Review-Erlebnis will, hat keinen guten Weg. Es kann den verwalteten Dienst nutzen und die Drittanbieter-Abhängigkeit akzeptieren, oder ohne Support selbst hosten, oder ein anderes Tool wählen. Es gibt keine saubere vierte Tür, und es ist ehrlicher, das zu benennen, als so zu tun, als würde die Open-Source-Lizenz sie schließen.
Kernaussage des Abschnitts: Argos ist das stärkere Tool. Es selbst zu hosten ist nicht unterstützt und betrieblich fragil.
Lost Pixel: archiviert, und was zu tun ist, wenn du es nutzt
Das eigene Banner des Lost-Pixel-Repositorys ist die ganze Geschichte in einer Zeile: das Repository wurde am 22. April 2026 vom Eigentümer archiviert und ist jetzt schreibgeschützt. Das Team wechselte zu Figma, das letzte Release war v3.22.0 im November 2024, und es wurde keine Migrationsanleitung veröffentlicht.
Bis zur Archivierung war Lost Pixel eine vernünftige Wahl (Docker-basiertes Rendering, Unterstützung für Playwright und Storybook plus Ladle und Histoire, und sowohl ganzseitige als auch komponentenweise visuelle Tests). Nichts davon änderte sich am 22. April technisch. Was sich änderte, ist, dass es jetzt keinen Maintainer, keine Sicherheits-Patches und keine Roadmap hat, was für eine CI-Abhängigkeit disqualifizierend für neue Arbeit ist, egal wie gut die aktuelle Version läuft.
Wenn du es heute nutzt, teilt sich die Migration danach auf, wie du es genutzt hast. Wenn du dich auf seine komponentenweisen Tests verlassen hast, insbesondere Storybook- oder Ladle-Workflows, ist dein nächster Ersatz der verwaltete Argos-Dienst oder Playwrights native Screenshot-Tests. BackstopJS kann Selektoren oder Storybook-URLs erfassen, aber es gibt dir nicht denselben eingebauten Komponenten-Workflow wie Lost Pixel, du müsstest diese Komponentenzustände also selbst modellieren. Wenn du es für ganzseitige visuelle Regression genutzt hast, ist BackstopJS der direkte self-hosted Nachfolger. So oder so ist der Umzug nicht im Sinne von "deine Builds brechen morgen" dringend, aber die Uhr läuft: ein ungepflegtes Test-Tool verrottet still, während die Versionen deines Browsers, Betriebssystems und Frameworks von denen wegdriften, gegen die es zuletzt gebaut wurde.
Vergleich auf einen Blick
Hier dieselben Informationen nebeneinander, damit du die für eine CI-Entscheidung wichtigen Achsen überfliegen kannst, bevor du sie auf deine eigenen Einschränkungen überträgst.
| Achse | BackstopJS | Argos | Lost Pixel |
|---|---|---|---|
| Lizenz | MIT | MIT-Code, verwaltetes SaaS-Produkt | MIT |
| Self-Hosting-Realität | Vollständig self-hostbar per Design | Möglich, aber ohne Support und ohne Dokumentation | War self-hostbar, jetzt archiviert |
| Wartungsstatus | Gepflegt, langsam und ausgereift | Aktiv (verwalteter Dienst) | Archiviert am 22. April 2026 |
| Diffing-Ansatz | Pixel-Diff (Resemble.js) | Pixel-Diff plus ARIA-Snapshot-Diff | Pixel-Diff (ungepflegt) |
| Framework- und Engine-Unterstützung | Puppeteer (Standard), Playwright | Playwright, Cypress, Storybook, WebdriverIO, Puppeteer | Playwright, Storybook, Ladle, Histoire (zum Zeitpunkt der Archivierung) |
| Review-Workflow | HTML-Report, manuelle Freigabe, kein PR-Gate | PR-Review, kollaborative Kommentare, PR-Gating | Nicht zutreffend (archiviert) |
| Kosten | Kostenlos | SaaS-Preise (snapshot-basiert) | Kostenlos, aber ungepflegt |
Wie man wählt (Entscheidungsrahmen)
Gehe von deiner härtesten Einschränkung aus, nicht von einer Funktionsliste. Die Einschränkung streicht den Großteil des Menüs für dich.
- Vollständig self-hosted, null Budget, und du kannst Tests nur ganzseitig mit manueller Freigabe akzeptieren: BackstopJS. Es ist die einzige Option, die self-hosted, gepflegt und kostenlos zugleich erfüllt, und die Kompromisse (kein PR-Gate, JSON-Konfiguration, Docker-Instabilität) sind bekannte Größen, um die herum du planen kannst.
- Du willst das beste Review-Erlebnis, PR-Gating und ARIA-Diffing, und du kannst eine SaaS-Abhängigkeit akzeptieren: der verwaltete Argos-Dienst. Das ist der Weg zu den Stärken von Argos ohne das Risiko des nicht unterstützten Self-Hostings. Wenn eine Compliance-Regel das Hochladen von Screenshots zu Dritten verbietet, ist diese Tür zu und du bist zurück bei BackstopJS.
- Kleine Test-Suite oder Playwright-first: erwäge, gar kein dediziertes Tool hinzuzufügen. Playwright bringt
toHaveScreenshot()nativ mit, und für Suiten unter etwa 100 Tests könnte es alles sein, was du brauchst. Ein Praktiker-Leitfaden setzt den Wendepunkt, ab dem sich ein dediziertes Tool zu lohnen beginnt, ungefähr bei dieser Größenordnung an (behandle das als Branchenbeobachtung, nicht als offizielle Playwright-Zahl). Der Verwaltungsaufwand für Baseline-Dateien in git wächst über diesen Punkt hinaus, und genau da zahlt sich ein dediziertes Tool aus. - Aktuell auf Lost Pixel: migriere jetzt, gemäß der Aufteilung im vorherigen Abschnitt. Nimm "es funktioniert noch" nicht als Grund zu bleiben.
Ein Vorbehalt, der all diesen Tools vorausgeht und sie überlebt: das Sparkbox-Team, das vor Jahren schrieb, wählte bewusst eine gehostete Option, weil Ingenieure tatsächlich dazu zu bringen, die Tests zu nutzen, schwieriger war als das Setup. Ein self-hosted Tool mit einer schwächeren Review-UI kann bei den Kosten gewinnen und bei der Akzeptanz verlieren (wenn dein Team einen lauten BackstopJS-Report ignoriert, hat dir sein Nulltarif nichts gebracht). Berücksichtige das Review-Erlebnis in der Entscheidung, nicht nur den Preis.
Kernaussage des Abschnitts: Die Einschränkung wählt das Tool. Self-hosted und kostenlos weist auf BackstopJS, bester Workflow bei akzeptablem SaaS weist auf Argos, und klein und Playwright-first weist womöglich auf gar kein Tool.
Den CI-Runner für headless Chromium dimensionieren
Alle drei Tools steuern headless Chromium, und es ist der Speicherbedarf von Chromium (nicht die CPU), der die Größe deines Runners bestimmt, weil jeder gleichzeitige Browser-Worker seine eigenen paar Gigabyte RAM will. Dimensionierst du die Maschine zu klein, scheitern deine visuellen Tests nicht sauber. Sie werden mitten im Lauf per OOM abgeschossen und als instabiles Infrastruktur-Rauschen gemeldet, die schlimmste Art von Fehler beim Debuggen.
Als grober Leitfaden, nach Parallelität bemessen statt als harte Zahlen (die tatsächliche Nutzung hängt von der Seitenkomplexität und davon ab, wie viele Worker du parallel ausführst):
- Kleines Team oder serielle Tests: rund 2 vCPU / 4 GB RAM bewältigen einen einzelnen headless-Chromium-Worker samt CI-Daemon-Overhead.
- CI-Nutzung im Team: rund 4 vCPU / 8 GB RAM unterstützen etwa 2 bis 4 parallele Browser-Worker, wo die meisten Teams landen.
- Hoher Durchsatz oder große Suiten: rund 8 vCPU / 16 GB RAM für hohe Parallelität, oder wenn der Lauf der visuellen Regression sich einen Runner mit anderer CI-Arbeit teilt.
Der Speicher ist der stille Posten. Screenshot-Artefakte und historische Baselines sammeln sich Lauf für Lauf an, plane also für dieses Wachstum: veranschlage großzügigen Speicherpuffer, wenn du Baselines lokal hältst, oder schiebe Baselines und Artefakte in Objektspeicher, damit die Runner-Platte nicht zum Engpass wird.
Ein VPS ist der natürliche Host für einen self-hosted CI-Runner, der das tut, weil du vorhersehbaren, dedizierten RAM für die Chromium-Worker willst, und eine Homelab-Kiste nur dann sinnvoll ist, wenn die Hardware schon dasteht. Wenn du auch den umgebenden CI-Stack aufsetzt, sind die Teile rund um das Tool für visuelle Tests Ein-Klick-Deployments im Cloudzy-Marketplace: Gitea, GitLab, Jenkins und Forgejo für die CI-Forge, und Docker für die Rendering-Konsistenz, die die Tools brauchen. Das Tool für visuelle Regression selbst installiert sich obendrauf über npm oder Docker, richte also einen Linux VPS ein, dimensioniert nach den obigen Bereichen, und betreibe es dort. Wenn du Docker-basierte CI verdrahtest, decken die Cloudzy-Leitfäden zu self-hosted GitLab-Alternativen und Docker-Container auflisten das angrenzende Setup ab.
Häufig gestellte Fragen
Ist Argos self-hostbar?
Technisch ja (der Code ist MIT-lizenziert), aber der Maintainer erklärte im September 2025, dass Argos weder Support noch Dokumentation dafür bietet, es außerhalb des verwalteten Dienstes zu betreiben. Behandle Self-Hosting als nicht unterstützt und betrieblich fragil: es kann bei jeder stromaufwärtigen Änderung brechen, ohne dass ein Maintainer zur Hilfe verpflichtet ist. Für die meisten Teams ist der verwaltete Dienst der praktische Weg, die Vorteile von Argos zu bekommen.
Was ist mit Lost Pixel passiert?
Lost Pixel wurde am 22. April 2026 archiviert, als das Team zu Figma wechselte und das Produkt einstellte. Das Repository ist schreibgeschützt, das letzte Release war v3.22.0 im November 2024, und es wurde keine Migrationsanleitung bereitgestellt. Setze es nicht für neue Arbeit ein. Wenn du es nutzt, plane eine Migration zu BackstopJS (ganzseitige Tests) oder zu Argos und Playwright-nativ (Komponententests).
Was ist ARIA-Snapshot-Diffing?
ARIA-Snapshot-Diffing vergleicht den Accessibility-Baum (Rollen, Labels und Struktur) neben dem Pixel-Screenshot und erfasst semantische und Accessibility-Regressionen, die ein Pixel-Diff allein übersehen kann, etwa einen visuell identischen Button, der sein zugängliches Label verloren hat. Argos fügte die Funktion am 4. November 2025 hinzu.
Wie viel RAM braucht headless Chromium in der CI?
Ein einzelner serieller Worker läuft typischerweise mit etwa 2 bis 4 GB, und gleichzeitige Worker skalieren den RAM von da an ungefähr linear. Die tatsächliche Nutzung hängt von der Seitenkomplexität und davon ab, wie viele Browser-Instanzen du parallel ausführst, behandle diese Werte also als Leitlinien statt als harte Zahlen und lass Puffer, um per OOM abgeschossene Testläufe zu vermeiden.
Unterstützt BackstopJS Playwright?
Ja. Puppeteer ist die Standard-Engine (headless Chrome), und BackstopJS unterstützt auch Playwright über chromium, firefox und webkit. Die Engine wählst du in deiner Konfiguration.
