Imagina estandarizar tu CI en una de las tres herramientas de código abierto para pruebas de regresión visual que todo el mundo preselecciona (BackstopJS, Argos, Lost Pixel) y descubrir, una semana después de empezar la prueba, que dos de las tres no son lo que parecían desde fuera. Argos tiene un código excelente en GitHub, pero su responsable dice claramente que el autoalojamiento no está soportado ni documentado. Lost Pixel se archivó el 22 de abril de 2026, cuando el equipo se unió a Figma, y no ofreció ninguna vía de migración para los equipos que ya lo usaban.
Eso deja exactamente una de las tres que es realmente autoalojable y se mantiene hoy en día. Lo cual es extraño de decir sobre una categoría con tanta variedad aparente, pero es donde está el panorama en realidad. Las herramientas que la gente trata como tres iguales son, en la práctica, una opción autoalojada que funciona, una herramienta potente que vive en los servidores de otro, y una de la que deberías estar migrando.
Este es un análisis con enfoque en el autoalojamiento sobre las herramientas de pruebas de regresión visual autoalojadas que sobreviven al contacto con la realidad: cuál encaja con qué restricción, y qué hacer si usas Lost Pixel ahora mismo.
La versión corta
- BackstopJS es la opción autoalojable, mantenida, con licencia MIT y coste cero. Puppeteer por defecto con soporte para Playwright, comparación de píxeles mediante Resemble.js y una interfaz de revisión en HTML (con salvedades de renderizado en Docker que debes planificar).
- Argos es la herramienta más fuerte en flujo de trabajo (revisión de PR y comparación de instantáneas ARIA desde finales de 2025), pero en la práctica es un SaaS gestionado. El responsable no ofrece soporte ni documentación para ejecutarla por tu cuenta.
- Lost Pixel se archivó en abril de 2026. No la adoptes para trabajo nuevo y, si la usas, planifica ya tu migración.
El veredicto en una línea: para una canalización de CI totalmente autoalojada, BackstopJS es la opción práctica. Si quieres el mejor flujo de revisión y puedes aceptar una dependencia SaaS, Argos es la mejor herramienta.
(Lo que esto no cubre: pruebas visuales basadas en Cypress, flujos de trabajo específicos de componentes en Storybook y cifras de rendimiento medidas a mano. Esta comparación está construida a partir de datos de fuentes primarias, no de un banco de pruebas que yo mismo haya ejecutado.)
El panorama del testing de regresión visual autoalojado ha cambiado
Dos hechos concretos del último año han remodelado esta lista, y ambos son fáciles de pasar por alto si trabajas a partir de un artículo escrito antes de que ocurrieran.
El primero: en una discusión en GitHub de septiembre de 2025, un responsable de Argos afirmó que Argos no ofrece soporte ni documentación para ejecutarlo fuera del servicio gestionado. El código tiene licencia MIT y está a la vista, así que "puedes autoalojarlo" es técnicamente cierto, pero no hay una vía soportada, una distinción que importa enormemente en cuanto eres la persona de guardia para ello.
El segundo: el repositorio de Lost Pixel se archivó el 22 de abril de 2026, en modo de solo lectura, cuando el equipo anunció que se unía a Figma. Ninguna guía de migración acompañó al cierre. Una herramienta que era, hasta hace poco, una alternativa gratuita y autoalojada legítima a Percy y Chromatic es ahora una dependencia sin responsable.
Ambos cambios apuntan en la misma dirección. La razón por la que los equipos acaban aquí en primer lugar, precios de SaaS que crecen con navegadores por ventanas gráficas por páginas, o una norma de cumplimiento que prohíbe subir capturas de una interfaz sin publicar a un tercero, no ha desaparecido. Lo que ha cambiado es que el menú autoalojado es más corto de lo que parece.
Conclusión clave de la sección: solo una de las tres herramientas que la gente preselecciona es realmente autoalojable y se mantiene de forma activa hoy en día.
BackstopJS: la opción realmente autoalojable
La instalación es npm install -g backstopjs (o una instalación local en el proyecto), y ese único hecho explica en gran parte por qué BackstopJS gana en el eje del autoalojamiento: no hay ningún servicio que aplicar ingeniería inversa, ni backend gestionado del que dependa en secreto. Se ejecuta como un paquete de npm o un contenedor de Docker en una infraestructura que controlas, bajo licencia MIT, con coste de licencia cero. El README indica que la línea actual (6.3.x) es compatible con Node 20.
Por dentro impulsa Puppeteer por defecto (Chrome headless) y también admite Playwright en chromium, firefox y webkit. La comparación se basa en píxeles mediante Resemble.js, con un valor configurable misMatchThreshold que controla cuánta desviación de píxeles cuenta como fallo. Las aprobaciones se hacen mediante un informe HTML con una interfaz en el navegador para aceptar los cambios.
Las limitaciones son donde se toma una decisión estratégica. BackstopJS no tiene un flujo integrado de bloqueo de PR: te dirá que existe una diferencia, pero conectar eso a una puerta de "este PR no puede fusionarse" queda de tu parte. Su configuración vive en JSON, un escenario cada vez, y con unos cientos de casos de prueba ese JSON se convierte en una superficie de mantenimiento en sí misma. El desarrollo es de ritmo lento más que rápido: el proyecto no está archivado, el paquete está actualmente en la versión 6.3.25, y el repositorio muestra unas 7.200 estrellas en GitHub y 516 incidencias abiertas. Así que trata BackstopJS como algo maduro y utilizable, no como una plataforma de pruebas visuales de evolución rápida.
El riesgo operativo más agudo es el renderizado en Docker. Dos incidencias, capturas en blanco o cortadas en Docker (#1156) y resultados inconsistentes tras la actualización de Docker a la v5.3.0 (#1303), llevan años abiertas sin resolverse. Docker es además justo lo que quieres para CI, porque normaliza el renderizado entre máquinas. Así que la herramienta que te da más control también te entrega una clase conocida y sin corregir de inestabilidad justo en la configuración en la que la ejecutarás. Es un riesgo planificable, no un impedimento, pero debe estar sobre la mesa antes de que te comprometas.
Consejo: la trampa de las líneas base entre sistemas operativos. Si tus desarrolladores capturan las líneas base en macOS y tus ejecutores de CI son Linux, tus pruebas fallarán solo por diferencias en el suavizado de las fuentes, antes de que exista ninguna regresión real. Como ha documentadoun profesional, el renderizado de las fuentes difiere entre la imagen de Linux usada en los servicios de CI y una máquina local con macOS, lo suficiente para hacer fallar una prueba visual por sí solo. La solución es generar y comparar las líneas base en un mismo entorno (ejecuta BackstopJS dentro de la misma imagen de Docker en local que usas en CI), para que las imágenes de referencia y de comparación provengan de un renderizado idéntico.
Argos: el mejor flujo de trabajo, pero SaaS en la práctica
Argos acierta con la experiencia de revisión de una forma en que BackstopJS no lo hace, y esa es la razón por la que está en esta lista pese a la salvedad del autoalojamiento. Se integra con Playwright, Cypress, Storybook, WebdriverIO y Puppeteer, y se conecta con GitHub Actions, GitLab CI, Bitbucket y Azure DevOps. El flujo de revisión de PR es una función de producto de primera clase, y no ha dejado de avanzar. Entradas recientes del registro de cambios añaden revisiones colaborativas con comentarios fijados (junio de 2026) y la omisión automática de cambios inestables.
Su diferenciador técnico más interesante es la comparación. Además de la comparación determinista de píxeles, Argos añadió la comparación de instantáneas ARIA para su SDK de Playwright el 4 de noviembre de 2025. La comparación de instantáneas ARIA compara el árbol de accesibilidad (roles, etiquetas y estructura) junto a la captura de píxeles, lo que detecta una clase de regresiones semánticas y de accesibilidad que una comparación de píxeles pura puede pasar por alto (un botón que sigue viéndose idéntico pero que ha perdido su etiqueta accesible, por ejemplo). Para los equipos con compromisos de accesibilidad, es una capacidad real que las herramientas de solo píxeles no ofrecen.
Luego está la restricción. El código es MIT, pero el producto es el servicio gestionado, y el responsable ha sido explícito en que el autoalojamiento no está documentado ni soportado. Puedes ponerlo en marcha desde el código fuente. Simplemente lo haces sabiendo que cualquier cambio ascendente puede romper tu despliegue y nadie está obligado a ayudar. Hay una incertidumbre relacionada que conviene señalar en lugar de afirmar: los informes de la comunidad sugieren que la integración con GitLab Self-Managed requiere un plan Enterprise (lo trato como una señal de la comunidad, no como una especificación confirmada, así que verifícalo con tu propia configuración antes de que impulse una decisión).
Esto produce una brecha incómoda. Un equipo con requisitos estrictos de privacidad (justo el equipo más motivado para autoalojar) que también quiere la experiencia de revisión de Argos no tiene una buena vía. Pueden usar el servicio gestionado y aceptar la dependencia de un tercero, o autoalojar sin soporte, o elegir otra herramienta. No hay una cuarta puerta limpia, y es más honesto reconocerlo que fingir que la licencia de código abierto la cierra.
Conclusión clave de la sección: Argos es la herramienta más fuerte. Autoalojarla no está soportado y es operativamente frágil.
Lost Pixel: archivado, y qué hacer si lo usas
El propio aviso del repositorio de Lost Pixel resume toda la historia en una línea: el repositorio fue archivado por su propietario el 22 de abril de 2026 y ahora es de solo lectura. El equipo se unió a Figma, la última versión fue la v3.22.0 en noviembre de 2024, y no se publicó ninguna guía de migración.
Hasta el archivado, Lost Pixel era una elección razonable (renderizado basado en Docker, soporte para Playwright y Storybook además de Ladle e Histoire, y pruebas visuales tanto de página completa como a nivel de componente). Nada de eso cambió técnicamente el 22 de abril. Lo que cambió es que ahora no tiene responsable, ni parches de seguridad, ni hoja de ruta, lo que para una dependencia de CI es descalificante para trabajo nuevo por bien que funcione la versión actual.
Si lo usas hoy, la migración se divide según cómo lo estuvieras usando. Si dependías de sus pruebas a nivel de componente, especialmente flujos de trabajo con Storybook o Ladle, tu reemplazo más cercano es el servicio gestionado de Argos o las pruebas de captura de pantalla nativas de Playwright. BackstopJS puede capturar selectores o URL de Storybook, pero no te da el mismo flujo de componentes integrado que ofrecía Lost Pixel, así que tendrías que modelar tú mismo esos estados de componente. Si lo usabas para regresión visual de página completa, BackstopJS es el sucesor autoalojado directo. En cualquier caso, el movimiento no es urgente en el sentido de "tus compilaciones se romperán mañana", pero corre el reloj: una herramienta de pruebas sin mantenimiento se degrada en silencio a medida que las versiones de tu navegador, sistema operativo y framework se alejan de aquellas con las que se compiló por última vez.
Comparación de un vistazo
Aquí tienes la misma información en paralelo, para que puedas repasar los ejes que importan en una decisión de CI antes de trasladarlos a tus propias restricciones.
| Eje | BackstopJS | Argos | Lost Pixel |
|---|---|---|---|
| Licencia | MIT | Código MIT, producto SaaS gestionado | MIT |
| Realidad del autoalojamiento | Totalmente autoalojable por diseño | Posible pero sin soporte ni documentación | Fue autoalojable, ahora archivado |
| Estado de mantenimiento | Mantenido, de ritmo lento y maduro | Activo (servicio gestionado) | Archivado el 22 de abril de 2026 |
| Enfoque de comparación | Comparación de píxeles (Resemble.js) | Comparación de píxeles más comparación de instantáneas ARIA | Comparación de píxeles (sin mantenimiento) |
| Soporte de frameworks y motores | Puppeteer (por defecto), Playwright | Playwright, Cypress, Storybook, WebdriverIO, Puppeteer | Playwright, Storybook, Ladle, Histoire (en el momento del archivado) |
| Flujo de revisión | Informe HTML, aprobación manual, sin puerta de PR | Revisión de PR, comentarios colaborativos, bloqueo de PR | No aplicable (archivado) |
| Coste | Gratis | Precios SaaS (por instantánea) | Gratis pero sin mantenimiento |
Cómo elegir (marco de decisión)
Parte de tu restricción más dura, no de una lista de funciones. La restricción elimina por ti la mayor parte del menú.
- Totalmente autoalojado, presupuesto cero, y puedes aceptar pruebas solo de página completa con revisión manual: BackstopJS. Es la única opción que cumple a la vez autoalojado, mantenido y gratis, y las contrapartidas (sin puerta de PR, configuración en JSON, inestabilidad en Docker) son cantidades conocidas en torno a las que puedes diseñar.
- Quieres la mejor experiencia de revisión, bloqueo de PR y comparación ARIA, y puedes aceptar una dependencia SaaS: el servicio gestionado de Argos. Esta es la vía hacia las fortalezas de Argos sin el riesgo del autoalojamiento sin soporte. Si una norma de cumplimiento prohíbe subir capturas a un tercero, esta puerta está cerrada y vuelves a BackstopJS.
- Suite de pruebas pequeña o con Playwright primero: plantéate no añadir ninguna herramienta dedicada. Playwright incluye
toHaveScreenshot()de forma nativa, y para suites por debajo de unas 100 pruebas puede ser todo lo que necesites. Una guía de un profesional sitúa el punto de inflexión en el que una herramienta dedicada empieza a merecer la pena en torno a esa escala (trátalo como una observación del sector, no como una cifra oficial de Playwright). La sobrecarga de gestionar los archivos de línea base en git crece más allá de ese punto, que es donde una herramienta dedicada se paga sola. - Actualmente en Lost Pixel: migra ya, según la división de la sección anterior. No tomes "todavía funciona" como razón para quedarte.
Una advertencia que precede a todas estas herramientas y las sobrevive: el equipo de Sparkbox, que escribía hace años, eligió una opción alojada precisamente porque lograr que los ingenieros usaran de verdad las pruebas era más difícil que la configuración. Una herramienta autoalojada con una interfaz de revisión más débil puede ganar en coste y perder en adopción (si tu equipo ignora un informe ruidoso de BackstopJS, su coste de licencia cero no te ha aportado nada). Ten en cuenta la experiencia de revisión en la decisión, no solo el precio.
Conclusión clave de la sección: la restricción elige la herramienta. Autoalojado y gratis apunta a BackstopJS, mejor flujo de trabajo con SaaS aceptable apunta a Argos, y pequeño y con Playwright primero puede que no apunte a ninguna herramienta.
Dimensionar el ejecutor de CI para Chromium headless
Las tres herramientas impulsan Chromium headless, y es la huella de memoria de Chromium (no la CPU) lo que fija el tamaño de tu ejecutor, porque cada worker de navegador concurrente quiere sus propios pocos gigabytes de RAM. Si dimensionas la máquina por debajo, tus pruebas visuales no fallan de forma limpia. Mueren por OOM a mitad de ejecución y se reportan como ruido de infraestructura inestable, que es el peor tipo de fallo para depurar.
Como guía aproximada, dimensionada por paralelismo y no como cifras rígidas (el uso real depende de la complejidad de la página y de cuántos workers ejecutes en paralelo):
- Equipo pequeño o pruebas en serie: unos 2 vCPU / 4 GB RAM gestionan un único worker de Chromium headless con la sobrecarga del demonio de CI.
- Uso de CI en equipo: unos 4 vCPU / 8 GB RAM admiten aproximadamente de 2 a 4 workers de navegador en paralelo, que es donde se sitúan la mayoría de los equipos.
- Alto rendimiento o suites grandes: unos 8 vCPU / 16 GB RAM para un alto paralelismo, o cuando la ejecución de regresión visual comparte ejecutor con otro trabajo de CI.
El almacenamiento es la partida silenciosa. Los artefactos de capturas y las líneas base históricas se acumulan ejecución tras ejecución, así que planifica ese crecimiento: reserva un margen generoso de almacenamiento si guardas las líneas base en local, o envía las líneas base y los artefactos a almacenamiento de objetos para que el disco del ejecutor no sea la restricción.
Un VPS es el anfitrión natural para un ejecutor de CI autoalojado que haga esto, porque quieres una RAM predecible y dedicada para los workers de Chromium, y una máquina en casa solo tiene sentido si el hardware ya está ahí. Si además estás montando el resto de la infraestructura de CI, las piezas en torno a la herramienta de pruebas visuales son despliegues en un clic en el marketplace de Cloudzy: Gitea, GitLab, Jenkins y Forgejo para la forja de CI, y Docker para la consistencia de renderizado que necesitan las herramientas. La propia herramienta de regresión visual se instala encima mediante npm o Docker, así que despliega un Linux VPS dimensionado según los rangos anteriores y ejecútalo ahí. Si estás montando CI basado en Docker, las guías de Cloudzy sobre alternativas autoalojadas a GitLab y listar contenedores de Docker cubren la configuración adyacente.
Preguntas frecuentes
¿Es Argos autoalojable?
Técnicamente sí (el código tiene licencia MIT), pero el responsable declaró en septiembre de 2025 que Argos no ofrece soporte ni documentación para ejecutarlo fuera del servicio gestionado. Trata el autoalojamiento como algo sin soporte y operativamente frágil: puede romperse con cualquier cambio ascendente sin que ningún responsable esté obligado a ayudar. Para la mayoría de los equipos, el servicio gestionado es la forma práctica de obtener los beneficios de Argos.
¿Qué pasó con Lost Pixel?
Lost Pixel se archivó el 22 de abril de 2026, cuando el equipo se unió a Figma y cerró el producto. El repositorio es de solo lectura, la última versión fue la v3.22.0 en noviembre de 2024, y no se proporcionó ninguna guía de migración. No lo adoptes para trabajo nuevo. Si lo usas, planifica una migración a BackstopJS (pruebas de página completa) o a Argos y las nativas de Playwright (pruebas de componentes).
¿Qué es la comparación de instantáneas ARIA?
La comparación de instantáneas ARIA compara el árbol de accesibilidad (roles, etiquetas y estructura) junto a la captura de píxeles, y detecta regresiones semánticas y de accesibilidad que una comparación de píxeles por sí sola puede pasar por alto, como un botón visualmente idéntico que ha perdido su etiqueta accesible. Argos añadió la función el 4 de noviembre de 2025.
¿Cuánta RAM necesita Chromium headless en CI?
Un único worker en serie suele funcionar con unos 2 a 4 GB, y los workers concurrentes escalan la RAM de forma más o menos lineal a partir de ahí. El uso real depende de la complejidad de la página y de cuántas instancias de navegador ejecutes en paralelo, así que trata estas cifras como guías y no como valores rígidos, y deja margen para evitar ejecuciones muertas por OOM.
¿BackstopJS es compatible con Playwright?
Sí. Puppeteer es el motor por defecto (Chrome headless), y BackstopJS también admite Playwright en chromium, firefox y webkit. El motor se selecciona en tu configuración.
