Ferramentas RPA de código aberto que vale a pena considerar e onde executá-las

Várias ferramentas de uma seleção típica de RPA de código aberto não podem funcionar em um servidor Linux sem ambiente gráfico. Elas automatizam interfaces de desktop e dependem de uma sessão gráfica, enquanto um servidor sem desktop não possui uma sessão para controlar. Essa característica divide a categoria em duas e determina onde o bot pode funcionar.

O licenciamento comercial de RPA motiva a maioria das buscas pelas melhores ferramentas RPA de código aberto. Verifiquei novamente os registros de licença, atividade e pacotes abaixo em 5 de outubro de 2026, e cada afirmação sobre o estado aponta para o registro que a fundamenta.

Pontos-chave

• Comece pelos requisitos de sessão, não pela lista de recursos. Oculix, OpenRPA e taskt priorizam interfaces gráficas e precisam de uma sessão gráfica para atividades no desktop local. RPA Framework não precisa dela para navegador, arquivos e dados. Em TagUI e UI.Vision, isso depende do modo usado.
• RPA Framework publicou versões em fevereiro, março, maio, junho, agosto e outubro de 2026: o histórico de lançamentos mais consistente verificado aqui.
• TagUI usa Apache-2.0 e ainda aceita contribuições, mas AI Singapore encerrou sua manutenção e suporte. Seu wrapper Python não teve novos lançamentos desde julho de 2023.
• Automagica e OpenBots não devem fazer parte de uma seleção atual. Automagica deixou de usar AGPL3 quando Netcall adquiriu a empresa em outubro de 2020, e OpenBots não tem um repositório público mantido para um produto RPA.
• Se os sistemas que você conecta já oferecem APIs ou webhooks, precisa de automação de fluxos de trabalho, não RPA. Outra categoria, outras ferramentas e um desenvolvimento muito mais curto.

O Que Este Artigo Não Aborda

Três questões próximas ficam fora do escopo, cada uma por um motivo diferente.

• Plataformas comerciais com planos gratuitos. UiPath Community Edition e o plano gratuito de Power Automate são uma decisão separada daquela tratada aqui.
• Instalação e configuração. Nada abaixo é um guia de instalação, e nenhuma ferramenta vem acompanhada de comandos para executar.
• Agentes de IA que usam computadores. Uma ferramenta da lista oferece uma integração desse tipo, tratada em uma frase, não em uma comparação.

As ferramentas RPA de código aberto que continuam recebendo manutenção

Os seis projetos abaixo atendem ao critério adotado: software RPA realmente de código aberto com atividade pública desde meados de 2025. Ferramentas RPA gratuitas que deixaram de ser mantidas continuam gratuitas; por isso, a coluna mais importante é a de datas, não a de licenças. As outras mostram o que cada ferramenta automatiza e o que exige da máquina onde funciona.

rpaframework é uma coleção de bibliotecas, não um aplicativo. Você escreve Python ou Robot Framework e importa os componentes necessários. O início é mais trabalhoso que gravar uma macro, mas a manutenção é muito mais simples. O repositório o descreve como otimizado para Control Room, o produto comercial de orquestração criado por Robocorp ao seu redor. Um integrante de Sema4.ai em uma discussão no r/rpa descreve Robocorp como parte de Sema4.ai e deixa clara a separação. A biblioteca é Apache-2.0, a plataforma não. A propriedade mudou, essa separação não. O Robot Framework subjacente também é Apache-2.0 e não é outra ferramenta independente para incluir na seleção.

A extensão de navegador de UI.Vision é o núcleo de código aberto. A automação de desktop exige um download separado: um aplicativo local chamado XModules fornece reconhecimento de imagens e texto para clicar fora do navegador. A licença é dupla (AGPLv3 ou um acordo comercial). Se você modificar o núcleo aberto e não quiser cumprir as condições de AGPLv3 sobre compartilhamento do código-fonte, a alternativa é a licença comercial.

taskt é a opção difícil de classificar. Seu ramo de desenvolvimento recebeu um commit em julho de 2025, mas a última versão com tag, v3.5.0.0, foi publicada em maio de 2020. Commits e lançamentos são sinais distintos, e passar tanto tempo sem uma compilação versionada não significa que a existente deixou de funcionar.

SikuliX merece uma observação própria porque o nome passou a representar a linha legada. Seu upstream original foi arquivado em março de 2026, e o espelho oculix-org direciona usuários atuais para Oculix, a continuação ativa sob MIT. Portanto, Oculix é o projeto a considerar hoje; SikuliX1 oferece contexto de origem e compatibilidade, não uma opção mantida.

Dois nomes continuam aparecendo em seleções, mas não deveriam. O README de Automagica informa que Netcall adquiriu a empresa em 13 de outubro de 2020 e que o robô não está mais disponível sob AGPL3. A organização pública no GitHub de OpenBots contém um repositório de sites estáticos e uma biblioteca de emulação de terminal, mas nenhum núcleo RPA.

Dependência de interface gráfica ou headless: a divisão que decide o servidor

Uma ferramenta RPA de código aberto precisa de uma sessão de desktop quando o fluxo depende de automação de interfaces de desktop. Automação de APIs, arquivos e dados pode funcionar sem interface gráfica, assim como a do navegador quando ele roda em modo headless. Ferramentas de reconhecimento de imagens precisam também de pixels para examinar. Contudo, automação de desktop pode depender de uma sessão gráfica mesmo quando identifica controles por seletores em vez de imagens.

Uma sessão de desktop é o ambiente gráfico disponível após o login: tela, gerenciador de janelas e ponteiro do mouse com coordenadas. Headless significa o contrário: uma máquina funcionando sem tela conectada. A maioria dos servidores Linux alugados chega assim por padrão.

A divisão decorre das dependências da automação. Oculix, como SikuliX antes dele, usa visão computacional para localizar um botão comparando uma imagem armazenada com os pixels atuais da tela. Portanto, precisa de uma superfície gráfica para examinar. Um navegador controlado por uma API de automação pode funcionar sem tela de desktop. Automação de desktop baseada em seletores é diferente: identifica controles em vez de pixels, mas ainda pode depender de um ambiente gráfico. Para RPA de código aberto em um servidor, a pergunta prática é se o fluxo exige uma sessão gráfica.

TagUI e UI.Vision pertencem aos dois lados, dependendo do modo utilizado. A documentação de referência de TagUI diz que a opção -headless executa um fluxo com um navegador Chrome invisível e não funciona para automação visual. UI.Vision trabalha no navegador por meio de uma extensão e no desktop via XModules, que reconhece imagens na tela e, portanto, precisa de uma tela onde reconhecê-las.

Uma tela virtual resolve parte da diferença. Xvfb é uma forma comum de fornecer a uma máquina Linux headless uma tela na memória, onde programas gráficos desenham sem que ninguém esteja olhando. Isso permite automação visual em um servidor sem monitor. Não fará uma ferramenta exclusiva de Windows funcionar no Linux e acrescenta outra camada que precisa continuar funcionando às três da manhã.

Uma licença e uma data de commit dizem se a ferramenta ainda existirá no próximo ano. Os requisitos de sessão dizem se você consegue sequer executá-la.

Onde cada uma funciona

Um bot que atua na tela precisa de uma sessão gráfica que possa controlar: desktop real, sessão remota ou tela virtual. Um bot headless não precisa. Ambas as coisas parecem triviais até o bot ter que iniciar às 3 da manhã sem ninguém no teclado.

A RPA auto-hospedada tem um requisito operacional que permanece qualquer que seja a ferramenta: a máquina deve estar no estado correto quando a tarefa agendada começa. No Windows esse estado é específico, e Microsoft o documenta para seu próprio produto. A orientação para fluxos de desktop não assistidos de Power Automate diz que o produto cria uma sessão de desktop remoto na máquina de destino, que não é possível usar a sessão de console para execuções não assistidas e que um dispositivo Windows 10 ou Windows 11 não pode executar um fluxo se houver uma sessão de usuário, mesmo bloqueada. No Windows Server, uma sessão bloqueada aberta com o mesmo usuário da conexão retorna um erro.

É a implementação de um fornecedor, não uma lei do Windows, mas é um mapa útil de falhas, pois todo bot visual precisa resolver o mesmo problema. Algo deve controlar uma sessão interativa, e seu próprio desktop com login ativo costuma atrapalhar. No Linux o problema equivalente é menor, mas existe: uma tarefa que continua depois de fechar sua sessão SSH precisa de um agendador e um gerenciador de serviços, não de um terminal deixado aberto.

Windows Server trata sessões de forma diferente das edições desktop. A função RD Session Host executa desktops baseados em sessões em uma única máquina para aproveitar várias sessões, permitindo que a sessão do bot e a sua coexistam. Se você usar RD Session Host para esse funcionamento, cada usuário ou dispositivo conectado precisa de uma RDS CAL. É um custo a considerar desde o início, não um detalhe para descobrir depois.

O dimensionamento é modesto. Não reservaria mais que 1 vCPU e 2 GB de RAM para um bot que percorre um formulário clicando e grava um arquivo. Para algo que controle um navegador completo, reservaria 2 vCPU e pelo menos 4 GB, principalmente com várias abas: Chrome é a parte cara da carga, não a ferramenta de automação que o controla.

Uma máquina antiga em um armário atende a esses requisitos. Deve permanecer ligada e com login ativo, e não ser o notebook que você fecha à noite. Um servidor alugado elimina essa categoria de problema: funciona independentemente do notebook e não disputa a sessão de desktop em que você trabalha.

Se alugar a máquina for melhor que manter uma, a divisão corresponde bem a dois produtos. Um Windows VPS com imagem Desktop ou Server dá ao bot visual um ambiente Windows dedicado, enquanto um Linux VPS cobre o lado headless. Ambos funcionam mesmo com seu notebook fechado.

Qual escolher

Se a tarefa acontece no navegador ou em arquivos e você sabe escrever Python, RPA Framework é a escolha; o restante desta seção trata de casos específicos. A resposta muda quando uma aplicação desktop sem API entra em cena: é preciso uma ferramenta capaz de interagir com um desktop gráfico, e a seleção fica menor e mais antiga.

Para navegador, arquivos e dados em um servidor Linux, escolha RPA Framework. Ele roda headless, não exige infraestrutura gráfica adicional e publicou uma versão em outubro de 2026. O preço é escrever Python ou Robot Framework em vez de gravar uma macro: custa no primeiro dia e compensa toda vez que a aplicação de destino muda.

Para uma aplicação Windows legada sem API, se você quer automação visual em vez de escrever toda uma base de código, escolha UI.Vision com a condição correspondente. Ele recebe commits este ano, diferentemente de algumas opções de desktop. A metade AGPLv3 de sua licença dupla exige compartilhamento do código-fonte se você modificar e distribuir o software aberto. taskt é a segunda opção: o ramo de desenvolvimento está vivo, mas a última versão com tag saiu em maio de 2020. É preciso avaliar essa diferença entre aceitar commits e publicar versões.

Para automação visual multiplataforma do que aparece na tela, escolha Oculix, a continuação ativa de SikuliX. Ainda prioriza imagens em vez de seletores, mas agora oferece um IDE e lançamentos ativos, não apenas primitivas de comparação de imagens. Use-o quando o alvo forem pixels, não um DOM ou uma árvore de acessibilidade, e trate o repositório arquivado SikuliX1 como a linha legada, não o produto mantido.

TagUI continua sendo recomendado por um motivo: sua linguagem lembra inglês comum e a curva de aprendizado é a mais suave das seis. O contraponto está no README: AI Singapore encerrou a manutenção e o suporte de TagUI, enquanto colaboradores de código aberto e a comunidade continuam o projeto. Não é abandono: ainda chegam correções ao ramo padrão e o repositório não está arquivado. Também não é impulso sustentado, e o wrapper Python rpa no PyPI está anos atrás do histórico de commits. Escolha TagUI para uma tarefa que pode congelar, não para uma plataforma que pretende ampliar durante três anos.

OpenRPA é mais difícil de avaliar. Tem recursos reais de orquestração sob MPL-2.0, mas seu último commit de código e sua versão com tag mais recente são ambos de junho de 2025, e a única atividade no repositório desde então são branches automatizados de atualização de dependências. Não é um abandono, já que nada está arquivado, mas também nada foi lançado. Avalie essa diferença conforme o tempo que os bots precisarão funcionar.

Quando uma ferramenta RPA dedicada é a resposta errada

O argumento mais forte contra tudo acima veio de alguém que faz esse trabalho. Em uma discussão no r/selfhosted iniciada por um operador tentando sair de um contrato comercial de RPA, uma resposta recomenda Python e um framework de automação como Selenium. Mais trabalho inicial, menos quebras depois e menor custo de propriedade que o software RPA usado pelo comentarista. Outro participante na mesma discussão concorda de forma independente.

O limite é a manutenção. Se a tarefa será executada durante anos, o volume é alto e você ou alguém da equipe consegue manter uma pequena base de código, escreva o código. Selenium e Playwright custam mais no primeiro dia e menos no quadringentésimo, porque um script escrito por você falha de maneiras que você consegue interpretar. Se a tarefa tem um horizonte de meses ou ninguém na equipe escreve código, o caminho mais curto da ferramenta RPA para um bot funcionando vale sua fragilidade.

A saída do gravador é o que envelhece pior. Um script gerado observando seus cliques depende do layout em que foi gravado. Uma página redesenhada ou um botão movido o quebra de uma forma que a mensagem de erro raramente explica. O ceticismo vai além: um comentarista de uma discussão no r/rpa sobre opções abertas chama RPA de scripting reembalado e vendido a gestores não técnicos. Para uma tarefa suficientemente restrita, a descrição não é injusta.

Também é importante perceber cedo um erro de categoria. Se os sistemas conectados oferecem APIs ou webhooks, você não precisa de RPA. A RPA controla a interface porque não há outro acesso; a automação de fluxos usa esse acesso diretamente, é mais rápida de construir e muito menos frágil. São outras ferramentas e outra curva de custos, e a licença de n8n e o custo de auto-hospedá-lo são a primeira questão a resolver. n8n, Node-RED, Apache Airflow, Kestra e Dagu são aplicações de um clique em nosso marketplace, caso queira iniciar uma hoje.

O site atual de UI.Vision anuncia uma integração com Anthropic Computer Use, portanto a categoria já incorpora agentes que controlam a tela raciocinando sobre ela em vez de comparar imagens armazenadas.

Perguntas frequentes