Immagina di standardizzare la tua CI su uno dei tre strumenti open source di test di regressione visiva che tutti mettono in lista (BackstopJS, Argos, Lost Pixel) e di scoprire, una settimana dopo l'inizio della prova, che due dei tre non sono ciò che sembravano da fuori. Argos ha un codice eccellente su GitHub, ma il suo responsabile dice chiaramente che il self-hosting non è né supportato né documentato. Lost Pixel è stato archiviato il 22 aprile 2026, quando il team è entrato in Figma, e non ha offerto alcun percorso di migrazione ai team che già lo usavano.
Resta quindi esattamente uno dei tre che sia davvero self-hostabile e mantenuto oggi. Il che è strano da dire di una categoria con così tanta scelta apparente, ma è la situazione reale del panorama. Gli strumenti che le persone trattano come tre pari sono, in pratica, un'opzione self-hosted che funziona, uno strumento forte che vive sui server di qualcun altro, e uno da cui dovresti migrare.
Questa è una lettura orientata al self-hosting sugli strumenti di test di regressione visiva self-hosted che sopravvivono al contatto con la realtà: quale si adatta a quale vincolo, e cosa fare se usi Lost Pixel proprio adesso.
La versione breve
- BackstopJS è l'opzione self-hostabile, mantenuta, con licenza MIT e a costo zero. Puppeteer di default con supporto per Playwright, confronto a livello di pixel tramite Resemble.js e un'interfaccia di revisione in HTML (con le riserve sul rendering in Docker che devi pianificare).
- Argos è lo strumento più forte sul flusso di lavoro (revisione delle PR e confronto di snapshot ARIA dalla fine del 2025), ma in pratica è un SaaS gestito. Il responsabile non offre supporto né documentazione per eseguirlo per conto proprio.
- Lost Pixel è stato archiviato ad aprile 2026. Non adottarlo per lavoro nuovo e, se lo usi, pianifica subito la migrazione.
Il verdetto in una riga: per una pipeline di CI completamente self-hosted, BackstopJS è la scelta pratica. Se vuoi il miglior flusso di revisione e puoi accettare una dipendenza SaaS, Argos è lo strumento migliore.
(Ciò che questo confronto non copre: test visivi basati su Cypress, flussi di lavoro specifici per componenti in Storybook e numeri di prestazioni misurati a mano. Questo confronto è costruito su fatti da fonti primarie, non su un banco di prova che ho eseguito io stesso.)
Il panorama dei test di regressione visiva self-hosted è cambiato
Due fatti specifici dell'ultimo anno hanno rimodellato questa lista, ed entrambi sono facili da perdere se lavori a partire da un articolo scritto prima che accadessero.
Il primo: in una discussione su GitHub di settembre 2025, un responsabile di Argos ha dichiarato che Argos non offre supporto né documentazione per eseguirlo al di fuori del servizio gestito. Il codice è sotto licenza MIT ed è alla luce del sole, quindi "puoi fare il self-hosting" è tecnicamente vero, ma non esiste un percorso supportato, una distinzione che conta enormemente nel momento in cui sei tu la persona reperibile per gestirlo.
Il secondo: il repository di Lost Pixel è stato archiviato il 22 aprile 2026, in sola lettura, quando il team ha annunciato che sarebbe entrato in Figma. Nessuna guida alla migrazione ha accompagnato la chiusura. Uno strumento che era, fino a poco fa, un'alternativa gratuita e self-hosted legittima a Percy e Chromatic è ora una dipendenza senza responsabile.
Entrambi i cambiamenti puntano nella stessa direzione. Il motivo per cui i team finiscono qui in primo luogo, prezzi SaaS che crescono con browser per viewport per pagine, oppure una regola di conformità che vieta di caricare screenshot di un'interfaccia non ancora pubblicata a terze parti, non è scomparso. Ciò che è cambiato è che il menù self-hosted è più corto di quanto sembri.
Punto chiave della sezione: solo uno dei tre strumenti che le persone mettono in lista è davvero self-hostabile e mantenuto attivamente oggi.
BackstopJS: l'opzione davvero self-hostabile
L'installazione è npm install -g backstopjs (o un'installazione locale nel progetto), e questo singolo fatto spiega gran parte del perché BackstopJS vince sull'asse del self-hosting: non c'è alcun servizio da decodificare, nessun backend gestito da cui dipenda in segreto. Gira come pacchetto npm o container Docker su un'infrastruttura che controlli, sotto licenza MIT, a costo di licenza zero. Il README indica che la linea attuale (6.3.x) supporta Node 20.
Sotto il cofano pilota Puppeteer di default (Chrome headless) e supporta anche Playwright su chromium, firefox e webkit. Il confronto è basato sui pixel tramite Resemble.js, con un valore configurabile misMatchThreshold che controlla quanta deviazione di pixel conta come errore. Le approvazioni avvengono tramite un report HTML con un'interfaccia nel browser per accettare le modifiche.
I limiti sono il punto in cui si prende una decisione strategica. BackstopJS non ha un flusso integrato di blocco delle PR: ti dirà che esiste una differenza, ma collegarla a un cancello di tipo "questa PR non può essere unita" spetta a te. La sua configurazione vive in JSON, uno scenario alla volta, e con qualche centinaio di casi di test quel JSON diventa una superficie di manutenzione a sé stante. Lo sviluppo è a ritmo lento più che rapido: il progetto non è archiviato, il pacchetto è attualmente alla versione 6.3.25, e il repository mostra circa 7.200 stelle su GitHub e 516 issue aperte. Quindi tratta BackstopJS come qualcosa di maturo e utilizzabile, non come una piattaforma di test visivi in rapida evoluzione.
Il rischio operativo più acuto è il rendering in Docker. Due issue, screenshot bianchi o tagliati in Docker (#1156) e i piani risultati incoerenti dopo l'aggiornamento di Docker alla v5.3.0 (#1303), sono aperte da anni senza soluzione. Docker è inoltre proprio ciò che vuoi per la CI, perché normalizza il rendering tra le macchine. Così lo strumento che ti dà più controllo ti consegna anche una classe nota e non risolta di instabilità proprio nella configurazione in cui lo eseguirai. È un rischio pianificabile, non un ostacolo insormontabile, ma deve essere sul tavolo prima che tu ti impegni.
Consiglio: la trappola delle baseline tra sistemi operativi. Se i tuoi sviluppatori catturano le baseline su macOS e i tuoi runner di CI sono Linux, i tuoi test falliranno solo per differenze nell'anti-aliasing dei font, prima ancora che esista una regressione reale. Come ha documentatoun professionista, il rendering dei font differisce tra l'immagine Linux usata nei servizi di CI e una macchina locale con macOS, abbastanza da far fallire un test visivo da solo. La soluzione è generare e confrontare le baseline in un unico ambiente (esegui BackstopJS dentro la stessa immagine Docker in locale che usi in CI), così che le immagini di riferimento e di confronto provengano da un rendering identico.
Argos: il miglior flusso di lavoro, ma SaaS in pratica
Argos azzecca l'esperienza di revisione in un modo in cui BackstopJS non riesce, ed è l'intero motivo per cui è in questa lista nonostante la riserva sul self-hosting. Si integra con Playwright, Cypress, Storybook, WebdriverIO e Puppeteer, e si collega a GitHub Actions, GitLab CI, Bitbucket e Azure DevOps. Il flusso di revisione delle PR è una funzione di prodotto di prima classe, e non ha smesso di avanzare. Voci recenti del changelog aggiungono revisioni collaborative con commenti fissati (giugno 2026) e l'esclusione automatica delle modifiche instabili.
Il suo differenziatore tecnico più interessante è il confronto. Oltre al confronto deterministico dei pixel, Argos ha aggiunto il confronto di snapshot ARIA per il suo SDK Playwright il 4 novembre 2025. Il confronto di snapshot ARIA confronta l'albero di accessibilità (ruoli, etichette e struttura) insieme allo screenshot dei pixel, cosa che intercetta una classe di regressioni semantiche e di accessibilità che un confronto di soli pixel può mancare (un pulsante che appare ancora identico ma ha perso la sua etichetta accessibile, per esempio). Per i team con impegni sull'accessibilità, è una capacità reale che gli strumenti a soli pixel non offrono.
Poi c'è il vincolo. Il codice è MIT, ma il prodotto è il servizio gestito, e il responsabile è stato esplicito nel dire che il self-hosting non è documentato né supportato. Puoi metterlo in piedi dal codice sorgente. Semplicemente lo fai sapendo che qualsiasi modifica a monte può rompere il tuo deployment e nessuno è obbligato ad aiutarti. C'è un'incertezza correlata che conviene segnalare invece di affermare: le segnalazioni della community suggeriscono che l'integrazione con GitLab Self-Managed richieda un piano Enterprise (la tratto come un segnale della community, non come una specifica confermata, quindi verificala con la tua configurazione prima che guidi una decisione).
Questo produce un divario scomodo. Un team con requisiti di privacy rigorosi (proprio il team più motivato a fare self-hosting) che vuole anche l'esperienza di revisione di Argos non ha una buona strada. Possono usare il servizio gestito e accettare la dipendenza da terze parti, oppure fare self-hosting senza supporto, oppure scegliere un altro strumento. Non c'è una quarta porta pulita, ed è più onesto dirlo che fingere che la licenza open source la chiuda.
Punto chiave della sezione: Argos è lo strumento più forte. Fare self-hosting non è supportato ed è operativamente fragile.
Lost Pixel: archiviato, e cosa fare se lo usi
Lo stesso avviso del repository di Lost Pixel riassume tutta la storia in una riga: il repository è stato archiviato dal proprietario il 22 aprile 2026 ed è ora in sola lettura. Il team è entrato in Figma, l'ultima release è stata la v3.22.0 a novembre 2024, e non è stata pubblicata alcuna guida alla migrazione.
Fino all'archiviazione, Lost Pixel era una scelta ragionevole (rendering basato su Docker, supporto per Playwright e Storybook più Ladle e Histoire, e test visivi sia a pagina intera sia a livello di componente). Nulla di questo è cambiato tecnicamente il 22 aprile. Ciò che è cambiato è che ora non ha responsabile, né patch di sicurezza, né roadmap, il che per una dipendenza di CI è squalificante per lavoro nuovo per quanto bene funzioni la versione attuale.
Se lo usi oggi, la migrazione si divide in base a come lo stavi usando. Se dipendevi dai suoi test a livello di componente, in particolare i flussi con Storybook o Ladle, il sostituto più vicino è il servizio gestito di Argos oppure i test di screenshot nativi di Playwright. BackstopJS può catturare selettori o URL di Storybook, ma non ti dà lo stesso flusso di componenti integrato che offriva Lost Pixel, quindi dovresti modellare tu stesso quegli stati dei componenti. Se lo usavi per la regressione visiva a pagina intera, BackstopJS è il successore self-hosted diretto. In ogni caso, lo spostamento non è urgente nel senso di "le tue build si romperanno domani", ma il tempo corre: uno strumento di test non mantenuto marcisce in silenzio man mano che le versioni del tuo browser, del sistema operativo e del framework si allontanano da quelle con cui è stato compilato l'ultima volta.
Confronto in sintesi
Ecco le stesse informazioni affiancate, così puoi scorrere gli assi che contano per una decisione di CI prima di mapparli sui tuoi vincoli.
| Asse | BackstopJS | Argos | Lost Pixel |
|---|---|---|---|
| Licenza | MIT | Codice MIT, prodotto SaaS gestito | MIT |
| Realtà del self-hosting | Completamente self-hostabile per progettazione | Possibile ma senza supporto né documentazione | Era self-hostabile, ora archiviato |
| Stato di manutenzione | Mantenuto, a ritmo lento e maturo | Attivo (servizio gestito) | Archiviato il 22 aprile 2026 |
| Approccio al confronto | Confronto di pixel (Resemble.js) | Confronto di pixel più confronto di snapshot ARIA | Confronto di pixel (non mantenuto) |
| Supporto di framework e motori | Puppeteer (default), Playwright | Playwright, Cypress, Storybook, WebdriverIO, Puppeteer | Playwright, Storybook, Ladle, Histoire (al momento dell'archiviazione) |
| Flusso di revisione | Report HTML, approvazione manuale, nessun cancello sulle PR | Revisione delle PR, commenti collaborativi, blocco delle PR | Non applicabile (archiviato) |
| Costo | Gratuito | Prezzi SaaS (a snapshot) | Gratis ma non mantenuto |
Come scegliere (schema decisionale)
Parti dal tuo vincolo più duro, non da un elenco di funzionalità. Il vincolo elimina per te gran parte del menù.
- Completamente self-hosted, budget zero, e puoi accettare test solo a pagina intera con revisione manuale: BackstopJS. È l'unica opzione che soddisfa self-hosted, mantenuto e gratis allo stesso tempo, e i compromessi (nessun cancello sulle PR, configurazione in JSON, instabilità in Docker) sono quantità note attorno a cui puoi progettare.
- Vuoi la migliore esperienza di revisione, il blocco delle PR e il confronto ARIA, e puoi accettare una dipendenza SaaS: il servizio gestito di Argos. Questa è la via verso i punti di forza di Argos senza il rischio del self-hosting non supportato. Se una regola di conformità vieta il caricamento di screenshot a terze parti, questa porta è chiusa e torni a BackstopJS.
- Suite di test piccola o incentrata su Playwright: valuta di non aggiungere alcuno strumento dedicato. Playwright include
toHaveScreenshot()in modo nativo, e per suite sotto le 100 prove circa può essere tutto ciò che ti serve. Una guida di un professionista colloca il punto di svolta in cui uno strumento dedicato inizia a valere la pena attorno a quella scala (trattalo come un'osservazione del settore, non come un dato ufficiale di Playwright). Il sovraccarico di gestire i file di baseline in git cresce oltre quel punto, ed è lì che uno strumento dedicato si ripaga. - Attualmente su Lost Pixel: migra subito, secondo la suddivisione della sezione precedente. Non prendere "funziona ancora" come motivo per restare.
Un avvertimento che precede tutti questi strumenti e sopravvive loro: il team di Sparkbox, che scriveva anni fa, ha scelto un'opzione ospitata proprio perché convincere gli ingegneri a usare davvero i test era più difficile della configurazione. Uno strumento self-hosted con un'interfaccia di revisione più debole può vincere sul costo e perdere sull'adozione (se il tuo team ignora un report rumoroso di BackstopJS, il suo costo di licenza zero non ti ha portato nulla). Considera l'esperienza di revisione nella decisione, non solo il prezzo.
Punto chiave della sezione: il vincolo sceglie lo strumento. Self-hosted e gratis punta a BackstopJS, miglior flusso di lavoro con SaaS accettabile punta ad Argos, e piccolo e incentrato su Playwright potrebbe non puntare ad alcuno strumento.
Dimensionare il runner di CI per Chromium headless
Tutti e tre gli strumenti pilotano Chromium headless, ed è l'impronta di memoria di Chromium (non la CPU) a fissare la dimensione del tuo runner, perché ogni worker di browser concorrente vuole i suoi pochi gigabyte di RAM. Se dimensioni la macchina troppo piccola, i tuoi test visivi non falliscono in modo pulito. Vengono uccisi da OOM a metà esecuzione e riportati come rumore di infrastruttura instabile, che è il peggior tipo di errore da diagnosticare.
Come guida approssimativa, dimensionata per parallelismo e non come numeri rigidi (l'uso reale dipende dalla complessità della pagina e da quanti worker esegui in parallelo):
- Piccolo team o test in serie: circa 2 vCPU / 4 GB RAM gestiscono un singolo worker Chromium headless con il sovraccarico del demone di CI.
- Uso di CI in team: circa 4 vCPU / 8 GB RAM supportano all'incirca da 2 a 4 worker di browser in parallelo, che è dove si colloca la maggior parte dei team.
- Alto throughput o suite grandi: circa 8 vCPU / 16 GB RAM per un alto parallelismo, o quando l'esecuzione di regressione visiva condivide un runner con altro lavoro di CI.
L'archiviazione è la voce silenziosa. Gli artefatti degli screenshot e le baseline storiche si accumulano esecuzione dopo esecuzione, quindi pianifica quella crescita: prevedi un margine generoso di archiviazione se conservi le baseline in locale, oppure invia le baseline e gli artefatti a uno storage a oggetti così che il disco del runner non sia il collo di bottiglia.
Un VPS è l'host naturale per un runner di CI self-hosted che fa questo, perché vuoi una RAM prevedibile e dedicata per i worker di Chromium, e una macchina casalinga ha senso solo se l'hardware è già lì. Se stai anche allestendo il resto dello stack di CI, i pezzi attorno allo strumento di test visivo sono deployment con un clic nel marketplace di Cloudzy: Gitea, GitLab, Jenkins e Forgejo per la forge di CI, e Docker per la coerenza di rendering di cui gli strumenti hanno bisogno. Lo strumento di regressione visiva stesso si installa sopra tramite npm o Docker, quindi crea un Linux VPS dimensionato secondo gli intervalli sopra ed eseguilo lì. Se stai mettendo in piedi una CI basata su Docker, le guide di Cloudzy su alternative self-hosted a GitLab e i piani elencare i container Docker coprono la configurazione adiacente.
Domande frequenti
Argos è self-hostabile?
Tecnicamente sì (il codice è sotto licenza MIT), ma il responsabile ha dichiarato a settembre 2025 che Argos non offre supporto né documentazione per eseguirlo al di fuori del servizio gestito. Tratta il self-hosting come qualcosa di non supportato e operativamente fragile: può rompersi a ogni modifica a monte senza che alcun responsabile sia obbligato ad aiutare. Per la maggior parte dei team, il servizio gestito è il modo pratico di ottenere i vantaggi di Argos.
Cosa è successo a Lost Pixel?
Lost Pixel è stato archiviato il 22 aprile 2026, quando il team è entrato in Figma e ha chiuso il prodotto. Il repository è in sola lettura, l'ultima release è stata la v3.22.0 a novembre 2024, e non è stata fornita alcuna guida alla migrazione. Non adottarlo per lavoro nuovo. Se lo usi, pianifica una migrazione a BackstopJS (test a pagina intera) oppure ad Argos e ai test nativi di Playwright (test dei componenti).
Cos'è il confronto di snapshot ARIA?
Il confronto di snapshot ARIA confronta l'albero di accessibilità (ruoli, etichette e struttura) insieme allo screenshot dei pixel, e intercetta regressioni semantiche e di accessibilità che un confronto di soli pixel può mancare, come un pulsante visivamente identico che ha perso la sua etichetta accessibile. Argos ha aggiunto la funzione il 4 novembre 2025.
Quanta RAM serve a Chromium headless in CI?
Un singolo worker in serie di solito gira con circa 2 a 4 GB, e i worker concorrenti scalano la RAM in modo grosso modo lineare da lì. L'uso reale dipende dalla complessità della pagina e da quante istanze di browser esegui in parallelo, quindi tratta questi numeri come guide e non come valori rigidi, e lascia margine per evitare esecuzioni uccise da OOM.
BackstopJS supporta Playwright?
Sì. Puppeteer è il motore di default (Chrome headless), e BackstopJS supporta anche Playwright su chromium, firefox e webkit. Il motore si seleziona nella tua configurazione.
