Herramientas RPA de código abierto que merece la pena considerar y dónde ejecutarlas

Varias herramientas de una selección habitual de RPA de código abierto no pueden ejecutarse en un servidor Linux sin entorno gráfico. Automatizan interfaces de escritorio y dependen de una sesión gráfica, mientras que un servidor sin escritorio no tiene ninguna sesión que controlar. Esa sola característica divide la categoría en dos y determina dónde puede funcionar el bot.

Las licencias comerciales de RPA motivan la mayoría de las búsquedas de las mejores herramientas RPA de código abierto. Volví a comprobar las licencias, la actividad y los registros de paquetes que aparecen abajo el 5 de octubre de 2026, y cada afirmación sobre su estado enlaza al registro que la respalda.

Conclusiones clave

• Empieza por los requisitos de sesión, no por la lista de funciones. Oculix, OpenRPA y taskt se centran en interfaces gráficas y necesitan una sesión gráfica para trabajar en el escritorio local. RPA Framework no la necesita para navegador, archivos y datos. En TagUI y UI.Vision depende del modo que uses.
• RPA Framework publicó versiones en febrero, marzo, mayo, junio, agosto y octubre de 2026: el historial de publicaciones más constante verificado aquí.
• TagUI tiene licencia Apache-2.0 y sigue aceptando contribuciones, pero AI Singapore dejó de mantenerlo y ofrecer soporte. Su envoltorio de Python no ha publicado ninguna versión desde julio de 2023.
• Automagica y OpenBots no deberían estar en una selección actual. Automagica dejó de estar bajo AGPL3 cuando Netcall adquirió la empresa en octubre de 2020, y OpenBots no tiene un repositorio público mantenido para un producto RPA.
• Si los sistemas que conectas ya ofrecen API o webhooks, necesitas automatización de flujos de trabajo, no RPA. Otra categoría, otras herramientas y un desarrollo mucho más corto.

Lo que este artículo no cubre

Tres preguntas relacionadas quedan fuera del alcance, cada una por una razón distinta.

• Plataformas comerciales con planes gratuitos. UiPath Community Edition y el plan gratuito de Power Automate corresponden a una decisión distinta de la tratada aquí.
• Instalación y configuración. Nada de lo que sigue es una guía de instalación, y ninguna herramienta incluye comandos para ejecutar.
• Agentes de IA que utilizan ordenadores. Una herramienta de la lista ofrece una integración de este tipo, y le dedicamos una frase, no una comparación.

Las herramientas RPA de código abierto que siguen recibiendo mantenimiento

Los seis proyectos siguientes cumplen el criterio empleado: software RPA realmente de código abierto con actividad pública desde mediados de 2025. Las herramientas RPA gratuitas que dejaron de mantenerse siguen siendo gratuitas, así que la columna que más merece atención es la de fechas, no la de licencias. Las demás indican qué automatiza cada herramienta y qué exige a la máquina donde funciona.

rpaframework es una colección de bibliotecas, no una aplicación. Escribes Python o Robot Framework e importas las partes necesarias. El comienzo es más exigente que grabar una macro, pero el mantenimiento resulta mucho más sencillo. Su repositorio lo describe como optimizado para Control Room, el producto comercial de orquestación que Robocorp construyó a su alrededor. Un miembro de Sema4.ai en un hilo de r/rpa explica que Robocorp ahora forma parte de Sema4.ai y deja clara la separación. La biblioteca es Apache-2.0; la plataforma no. Cambió la propiedad, pero no esa separación. El Robot Framework subyacente también es Apache-2.0 y no es otra opción independiente que añadir a la lista.

La extensión de navegador de UI.Vision es el núcleo de código abierto. La automatización del escritorio se descarga aparte: una aplicación local llamada XModules aporta reconocimiento de imágenes y texto para hacer clic fuera del navegador. Tiene licencia dual (AGPLv3 o un acuerdo comercial). Si modificas el núcleo de código abierto y no quieres cumplir las condiciones de AGPLv3 sobre compartir el código fuente, la alternativa es la licencia comercial.

taskt es la entrada difícil de encajar. Su rama de desarrollo recibió un commit en julio de 2025, pero su última versión etiquetada, v3.5.0.0, se publicó en mayo de 2020. Commits y versiones son señales diferentes; pasar tanto tiempo sin una nueva compilación versionada no significa que la existente haya dejado de funcionar.

SikuliX merece una aclaración porque su nombre ha pasado a representar la línea heredada. El repositorio original se archivó en marzo de 2026, y el espejo de oculix-org dirige a los usuarios actuales hacia Oculix, la continuación activa con licencia MIT. Por eso Oculix es el proyecto que conviene considerar hoy; SikuliX1 sirve como contexto de procedencia y compatibilidad, no como la opción mantenida.

Dos nombres siguen apareciendo en selecciones donde no deberían estar. El README de Automagica anuncia que Netcall adquirió la empresa el 13 de octubre de 2020 y que el robot ya no está disponible bajo AGPL3. La organización pública de GitHub de OpenBots contiene un repositorio de sitios estáticos y una biblioteca de emulación de terminal, pero ningún núcleo RPA.

Interfaz gráfica o ejecución sin pantalla: la diferencia que decide tu servidor

Una herramienta RPA de código abierto necesita una sesión de escritorio cuando el flujo automatiza interfaces gráficas de escritorio. La automatización de API, archivos y datos puede ejecutarse sin pantalla, al igual que la del navegador cuando se configura en modo headless. Las herramientas de reconocimiento de imágenes necesitan además píxeles que examinar. Aun así, la automatización del escritorio puede depender de una sesión gráfica aunque identifique controles mediante selectores en lugar de imágenes.

Una sesión de escritorio es el entorno gráfico que aparece tras iniciar sesión: pantalla, gestor de ventanas y puntero del ratón con coordenadas. Headless significa lo contrario: una máquina funcionando sin pantalla conectada. La mayoría de los servidores Linux alquilados llegan así por defecto.

La división depende de lo que necesita la automatización. Oculix, como antes SikuliX, usa visión artificial para localizar un botón comparando una imagen guardada con los píxeles actuales de la pantalla; por tanto, necesita una superficie gráfica que examinar. Un navegador controlado mediante una API de automatización puede funcionar sin escritorio gráfico. La automatización de escritorio mediante selectores es distinta: identifica controles en lugar de píxeles, pero puede seguir necesitando un entorno gráfico. Para RPA de código abierto en un servidor, la pregunta práctica es si el flujo necesita una sesión gráfica.

TagUI y UI.Vision pertenecen a ambos lados según el modo utilizado. La documentación de referencia de TagUI indica que su opción -headless ejecuta un flujo con un navegador Chrome invisible y no funciona para automatización visual. UI.Vision realiza las tareas del navegador dentro de una extensión, mientras que las del escritorio pasan por XModules, que reconoce imágenes en pantalla y, por tanto, necesita una pantalla donde reconocerlas.

Una pantalla virtual cubre parte de la diferencia. Xvfb es una forma habitual de ofrecer a una máquina Linux sin pantalla un dispositivo gráfico en memoria donde los programas dibujan sin que nadie mire. Permite automatizar acciones visuales en un servidor sin monitor. No hará funcionar en Linux una herramienta exclusiva de Windows, y añade otra capa que debe seguir funcionando a las tres de la mañana.

Una licencia y una fecha de commit te dicen si la herramienta seguirá existiendo el año que viene. Los requisitos de sesión te dicen si puedes ejecutarla siquiera.

Dónde se ejecuta cada herramienta

Un bot que actúa sobre la pantalla necesita una sesión gráfica que controlar, ya sea un escritorio real, una sesión remota o una pantalla virtual. Un bot headless no. Ambas cosas parecen triviales hasta que el bot debe arrancar a las 3 de la mañana sin nadie ante el teclado.

La RPA autoalojada tiene un requisito operativo que permanece independientemente de la herramienta: la máquina debe estar en el estado correcto cuando se activa la programación. En Windows ese estado es específico, y Microsoft lo documenta para su propio producto. Su guía de flujos de escritorio desatendidos de Power Automate indica que el producto crea una sesión de escritorio remoto en la máquina de destino, que no se admite la conexión a su sesión de consola para ejecuciones desatendidas y que un dispositivo Windows 10 o Windows 11 no puede ejecutar uno si existe una sesión de usuario, aunque esté bloqueada. En Windows Server, una sesión bloqueada abierta con el mismo usuario de la conexión devuelve un error.

Es la implementación de un proveedor, no una ley de Windows, pero ofrece un mapa útil de fallos porque todos los bots visuales deben resolver el mismo problema. Algo debe disponer de una sesión interactiva, y tu propio escritorio con la sesión iniciada suele estorbar. En Linux el problema equivalente es menor, pero existe: una tarea que continúa cuando cierras la sesión SSH necesita un planificador y un gestor de servicios, no un terminal que dejaste abierto.

Windows Server gestiona las sesiones de forma distinta a las ediciones de escritorio. Su función RD Session Host ejecuta escritorios basados en sesiones en una misma máquina para aprovechar varias sesiones, de modo que una sesión del bot y la tuya pueden coexistir. Si usas RD Session Host para ese funcionamiento, cada usuario o dispositivo conectado necesita una RDS CAL. Es un coste que debes contemplar al principio, no un detalle que descubrir al final.

Los recursos necesarios son modestos. No asignaría más de 1 vCPU y 2 GB de RAM a un bot que recorre un formulario haciendo clic y escribe un archivo. Para cualquier tarea que controle un navegador completo, reservaría 2 vCPU y 4 GB o más, especialmente con varias pestañas: Chrome es la parte costosa de la carga, no la herramienta de automatización que lo controla.

Un ordenador viejo en un armario cumple esos requisitos. Debe permanecer encendido y con la sesión iniciada, y no puede ser el portátil que cierras por la noche. Un servidor alquilado elimina esa clase de problemas: sigue funcionando independientemente del portátil y no compite con la sesión de escritorio donde trabajas.

Si prefieres alquilar la máquina a mantenerla, la división corresponde bastante bien a dos productos. Un Windows VPS con una imagen Desktop o Server ofrece al bot visual un entorno Windows dedicado, y un Linux VPS cubre el lado headless. Ambos funcionan aunque cierres el portátil.

Cuál elegir

Si la tarea se desarrolla en un navegador o en archivos y sabes escribir Python, RPA Framework es la elección y el resto de esta sección son casos particulares. La respuesta cambia cuando interviene una aplicación de escritorio sin API: necesitas una herramienta capaz de interactuar con un escritorio gráfico, y la lista de opciones se vuelve más corta y antigua.

Para navegador, archivos y datos en un servidor Linux, elige RPA Framework. Funciona sin pantalla, no requiere recursos gráficos adicionales y publicó una versión tan recientemente como octubre de 2026. El precio es escribir Python o Robot Framework en vez de grabar una macro: cuesta al principio y compensa cada vez que cambia la aplicación de destino.

Para una aplicación Windows heredada sin API, si buscas automatización visual en vez de escribir toda una base de código, elige UI.Vision con la condición correspondiente. Recibe commits este año, algo que no todas las opciones de escritorio pueden decir, y la mitad AGPLv3 de su licencia dual exige compartir el código fuente si modificas y distribuyes el software abierto. taskt es la segunda opción: su rama de desarrollo está viva, pero su última versión etiquetada salió en mayo de 2020. Debes valorar esa diferencia entre aceptar commits y publicar versiones.

Para automatizar visualmente lo que aparezca en pantalla en varias plataformas, elige Oculix, la continuación activa de SikuliX. Sigue priorizando imágenes sobre selectores, pero ahora cuenta con un IDE y versiones activas, no solo primitivas de comparación de imágenes. Úsalo cuando el objetivo sean píxeles en vez de un DOM o un árbol de accesibilidad, y considera el repositorio archivado SikuliX1 como la línea heredada, no el producto mantenido.

TagUI sigue recomendándose por una razón. Su lenguaje se parece al inglés corriente y su curva de aprendizaje es la más suave de las seis. La contrapartida está en su README: AI Singapore dejó de mantener y dar soporte a TagUI, mientras los colaboradores de código abierto y la comunidad continúan el proyecto. No es abandono: siguen llegando correcciones a la rama predeterminada y el repositorio no está archivado. Tampoco es impulso sostenido; el envoltorio Python rpa de PyPI lleva años de retraso respecto al registro de commits. Elige TagUI para una tarea que puedas congelar, no para una plataforma que pretendas ampliar durante tres años.

OpenRPA es más difícil de valorar. Tiene funciones reales de orquestación bajo MPL-2.0, pero su último commit de código y su versión etiquetada más reciente datan ambos de junio de 2025, y desde entonces la única actividad en el repositorio son ramas automatizadas de actualización de dependencias. No es un abandono, ya que no hay nada archivado, pero tampoco se ha publicado nada. Valora esa diferencia frente al tiempo que deberán funcionar los bots.

Cuándo una herramienta RPA dedicada es la respuesta equivocada

El argumento más sólido contra todo lo anterior lo aportó alguien que se dedica a este trabajo. En un hilo de r/selfhosted iniciado por un operador que quería salir de un contrato comercial de RPA, una respuesta recomienda Python y un framework de automatización como Selenium. Más esfuerzo de desarrollo, menos roturas después y menor coste de propiedad que el software RPA usado por ese comentarista. Otro participante del mismo hilo coincide de forma independiente.

El criterio es el mantenimiento. Si la tarea se ejecutará durante años, el volumen es alto y tú o alguien de tu equipo podéis mantener una pequeña base de código, escribe el código. Selenium y Playwright cuestan más el primer día y menos el día cuatrocientos, porque un script que has escrito falla de formas que puedes comprender. Si la tarea tiene un horizonte de meses o nadie en el equipo programa, la vía más corta de la herramienta RPA hacia un bot operativo merece la pena pese a su fragilidad.

La salida del grabador es lo que peor envejece. Un script generado observando tus clics depende del diseño contra el que se grabó. Una página rediseñada o un botón movido lo rompe de una forma que el mensaje de error rara vez explica. El escepticismo llega más lejos: un comentarista de un hilo de r/rpa sobre opciones de código abierto llama a la RPA scripting reempaquetado para venderlo a directivos no técnicos, y para una tarea suficientemente concreta no es una descripción injusta.

También conviene detectar pronto un error de categoría. Si los sistemas conectados exponen API o webhooks, no necesitas RPA. La RPA maneja una interfaz porque no existe otra entrada; la automatización de flujos usa directamente esa entrada, resulta más rápida de construir y mucho menos frágil. Son otras herramientas y otra estructura de costes; la licencia de n8n y el coste de autoalojarlo es lo primero que debes resolver. n8n, Node-RED, Apache Airflow, Kestra y Dagu están disponibles como aplicaciones de un clic en nuestro marketplace si quieres ejecutar una hoy.

El sitio actual de UI.Vision anuncia una integración con Anthropic Computer Use, por lo que la categoría ya está incorporando agentes que controlan una pantalla razonando sobre ella en lugar de comparar imágenes guardadas.

Preguntas frecuentes