Open source-RPA-værktøjer, der er værd at overveje, og hvor de kan køre

Flere af værktøjerne på en typisk liste over udvalgte open source-RPA-værktøjer kan ikke køre på en Linux-server uden grafisk miljø. De automatiserer skrivebordsgrænseflader og er afhængige af en grafisk session, mens en sådan server ikke har nogen skrivebordssession at styre. Denne ene egenskab deler kategorien i to og afgør, hvor din bot kan køre.

Kommercielle RPA-licenser er årsagen til de fleste søgninger efter de bedste open source-RPA-værktøjer. Jeg kontrollerede oplysningerne om licenser, aktivitet og pakker nedenfor igen den 5. oktober 2026, og hver påstand om status linker til den registrering, den stammer fra.

Vigtige pointer

• Begynd med sessionskravet, ikke funktionslisten. Oculix, OpenRPA og taskt er primært GUI-baserede og kræver en grafisk session til lokalt skrivebordsarbejde. Det gør RPA Framework ikke til arbejde med browser, filer og data. For TagUI og UI.Vision afhænger det af, hvilken tilstand du bruger.
• RPA Framework udgav versioner i februar, marts, maj, juni, august og oktober 2026, den mest regelmæssige udgivelseshistorik, der er verificeret her.
• TagUI bruger Apache-2.0 og modtager stadig bidrag, men AI Singapore har indstillet vedligeholdelse og support. Dets Python-wrapper er ikke blevet udgivet i en ny version siden juli 2023.
• Automagica og OpenBots hører ikke hjemme på en aktuel liste over udvalgte værktøjer. Automagica ophørte med at være AGPL3, da Netcall overtog virksomheden i oktober 2020, og OpenBots har ikke noget vedligeholdt offentligt repository for et RPA-produkt.
• Hvis de systemer, du forbinder, allerede stiller API'er eller webhooks til rådighed, skal du bruge workflowautomatisering, ikke RPA. En anden kategori, andre værktøjer, langt kortere udviklingstid.

Hvad denne artikel ikke dækker

Tre beslægtede spørgsmål ligger uden for artiklens rammer, hvert af sin egen grund.

• Kommercielle platforme med gratis niveauer. UiPath Community Edition og Power Automates gratis abonnement er en anden beslutning end den, vi behandler her.
• Installation og konfiguration. Intet nedenfor er en opsætningsvejledning, og ingen af værktøjerne får en kommandolinjeinstruktion her.
• AI-agenter, der betjener computere. Ét værktøj på listen leveres med en integration til en sådan agent, og den får en sætning, ikke en sammenligning.

Open source-RPA-værktøjerne, der stadig vedligeholdes

De seks projekter nedenfor opfylder kriteriet her: reelt open source-RPA-software med offentlig aktivitet siden midten af 2025. Gratis RPA-værktøjer, som ikke længere vedligeholdes, er stadig gratis, så den kolonne, der fortjener mest opmærksomhed nedenfor, er den med datoer, ikke den med licenser. De andre kolonner besvarer, hvad hvert værktøj automatiserer, og hvad det kræver af maskinen under det.

rpaframework er en samling biblioteker, ikke en applikation. Du skriver Python eller Robot Framework og importerer de dele, du har brug for. Det giver en stejlere start end at optage en makro, men en langt lettere vedligeholdelse. Dets repository beskriver det som optimeret til Control Room, det kommercielle orkestreringsprodukt, som Robocorp byggede omkring det. Et medlem af Sema4.ai-teamet i en r/rpa-tråd beskriver Robocorp som nu en del af Sema4.ai og trækker grænsen tydeligt op. Biblioteket bruger Apache-2.0, platformen gør ikke. Ejerskabet ændrede sig, grænsen gjorde ikke. Det underliggende Robot Framework bruger også Apache-2.0 og er ikke et separat værktøj at tage med på listen.

UI.Visions browserudvidelse er open source-kernen. Skrivebordsautomatisering er en separat download, en lokal app kaldet XModules, som giver udvidelsen billed- og tekstgenkendelse, så den kan klikke på ting uden for browseren. Licensen er dobbelt (AGPLv3 eller en kommerciel aftale). Hvis du ændrer open source-kernen og ikke vil overholde AGPLv3's betingelser om deling af kildekode, er den kommercielle licens alternativet.

taskt er den vanskelige post. Dets udviklingsgren modtog et commit i juli 2025, og dets seneste taggede udgivelse, v3.5.0.0, kom i maj 2020. Commits og udgivelser er forskellige signaler, og så lang tid uden et versioneret build betyder ikke, at det eksisterende build er holdt op med at fungere.

SikuliX kræver sin egen fodnote, fordi navnet i praksis er blevet den ældre produktlinje. Dets oprindelige repository blev arkiveret i marts 2026, og oculix-org-spejlet henviser nuværende brugere til Oculix, den aktive videreførelse med MIT-licens. Derfor er Oculix det projekt, der bør indgå på listen nu; SikuliX1 er nyttigt som baggrund for ophav og kompatibilitet snarere end som den vedligeholdte post.

To poster bliver ved med at dukke op på listerne, men burde ikke være der. Automagicas egen README meddeler, at Netcall overtog virksomheden den 13. oktober 2020, og at robotten ikke længere er tilgængelig under AGPL3, mens OpenBots' offentlige GitHub-organisation indeholder et repository til et statisk website og et terminalemuleringsbibliotek, men ingen RPA-kerne.

GUI-afhængig eller headless: opdelingen, der afgør dit servervalg

Et open source-RPA-værktøj kræver en skrivebordssession, når workflowet afhænger af automatisering af skrivebordets brugergrænseflade. API-, fil- og dataautomatisering kan køre headless, og det kan browserautomatisering også, når browseren kører i headless-tilstand. Billedgenkendelsesværktøjer kræver desuden pixels at undersøge, men skrivebordsautomatisering kan stadig være afhængig af en grafisk session, selv når den identificerer kontrolelementer gennem selektorer frem for billeder.

En skrivebordssession er det grafiske miljø, en bruger får efter at have logget ind: en skærm, et vindueshåndteringsprogram og en musemarkør med koordinater. Headless betyder det modsatte, en maskine, der kører uden tilsluttet skærm. De fleste Linux-servere, du lejer, leveres som standard headless.

Opdelingen følger af, hvad automatiseringen afhænger af. Oculix bruger, ligesom SikuliX før det, computersyn til at finde en knap ved at matche et gemt billede med de pixels, der aktuelt vises på skærmen, så det kræver en grafisk overflade at undersøge. En browser, der styres gennem et automatiserings-API, kan køre headless uden en skrivebordsskærm. Selektorbaseret skrivebordsautomatisering er noget tredje: den kan identificere kontrolelementer frem for pixels, men kan stadig være afhængig af et grafisk skrivebordsmiljø. For open source-RPA på en server er det praktiske spørgsmål, om workflowet kræver en grafisk session.

TagUI og UI.Vision befinder sig på begge sider, og hvilken side afhænger af den tilstand, du bruger. TagUI's egen referencedokumentation siger, at indstillingen -headless kører et flow med en usynlig Chrome-browser og ikke fungerer til visuel automatisering. UI.Visions browserarbejde kører inde i en udvidelse, mens dets skrivebordsarbejde kører gennem XModules, som genkender billeder på skærmen og derfor har brug for en skærm at genkende dem på.

En virtuel skærm lukker en del af hullet. Xvfb er en standardmetode til at give en headless Linux-maskine en skærm i hukommelsen, som grafiske programmer kan tegne på, uden at nogen ser med. Det gør skærmstyret automatisering mulig på en server uden monitor. Det får ikke et værktøj, der kun understøtter Windows, til at køre på Linux, og det tilføjer endnu et lag, som skal blive ved med at fungere klokken tre om natten.

En licens og en commitdato fortæller dig, om et værktøj stadig vil være der næste år. Sessionskravet fortæller dig, om du overhovedet kan køre det.

Hvor hvert værktøj kører

En skærmstyret bot kræver en grafisk session, som den kan kontrollere, hvad enten det er et rigtigt skrivebord, en fjernsession eller en virtuel skærm. En headless bot gør ikke. Begge dele lyder trivielt, indtil botten skal starte klokken 3 om natten, og ingen sidder ved tastaturet.

Selvhostet RPA har ét driftskrav, som gælder uanset værktøjsvalg: maskinen skal være i den rette tilstand, når den planlagte kørsel starter. På Windows er denne tilstand specifik, og Microsoft dokumenterer den præcist for sit eget produkt. Microsofts vejledning til Power Automates uovervågede skrivebordsflows siger, at produktet opretter en fjernskrivebordssession på målmaskinen for at køre flowet, at tilslutning til maskinens konsolsession ikke er tilgængelig for uovervågede kørsler, og at en Windows 10- eller Windows 11-enhed ikke kan køre et sådant flow, hvis der findes en brugersession, selv en låst session. På Windows Server giver en låst session, der er åben under samme bruger som forbindelsen, i stedet en fejl.

Det er én leverandørs implementering, ikke en Windows-lov, og det er et nyttigt kort over fejlsituationer, fordi enhver skærmstyret bot skal løse det samme problem. Noget skal have kontrollen over en interaktiv session, og dit eget indloggede skrivebord er som regel det, der står i vejen. På Linux er det tilsvarende problem mindre, men ikke fraværende: en opgave, der fortsætter, efter din SSH-session lukkes, kræver en scheduler og en servicemanager, ikke en terminal, du har efterladt åben.

Windows Server håndterer sessioner anderledes end skrivebordsudgaverne. Rollen RD Session Host kører sessionsbaserede skriveborde på én maskine for effektiv drift af flere sessioner, så en botsession og din egen session kan eksistere samtidig. Hvis du bruger RD Session Host til drift med flere sessioner, kræver hver tilsluttet bruger eller enhed en RDS CAL. Det er en omkostning, der bør regnes med tidligt, ikke en detalje, der skal opdages sent.

Dimensioneringen er beskeden. Jeg ville ikke tildele mere end 1 vCPU og 2 GB RAM til en bot, der klikker sig gennem en formular og skriver en fil. Alt, der styrer en fuld browser, ville jeg give 2 vCPU og 4 GB eller mere, især med flere faner, fordi Chrome er den ressourcekrævende del af den arbejdsbelastning frem for automatiseringsværktøjet ovenpå.

En gammel maskine i et skab opfylder det krav. Den skal forblive tændt og logget ind og må ikke være den bærbare computer, du lukker om natten. En lejet server fjerner den type problem, fordi den kan være tændt uafhængigt af din bærbare og ikke konkurrerer med den skrivebordssession, du arbejder i.

Hvis leje af maskinen er bedre end at vedligeholde en selv, svarer opdelingen rimelig tydeligt til to produkter. En Windows VPS med et Desktop- eller Server-image giver en skærmstyret bot et dedikeret Windows-miljø, og en Linux VPS dækker den headless side. Begge kører, uanset om din bærbare er åben.

Hvilket skal du vælge

Hvis opgaven foregår i en browser eller i filer, og du kan skrive Python, er RPA Framework valget, og resten af dette afsnit handler om særtilfælde. Svaret ændrer sig i det øjeblik, opgaven berører en skrivebordsapplikation uden API, for så har du brug for et værktøj, der kan arbejde med et grafisk skrivebord, og listen bliver kortere og ældre.

Vælg RPA Framework til browser-, fil- og dataarbejde på en Linux-server. Det kører headless, kan installeres på en maskine uden skærm uden ekstra mekanismer og udgav en ny version så sent som i oktober 2026. Prisen er, at du skriver Python eller Robot Framework i stedet for at optage en makro. Det koster dig på første dag og betaler sig, hver gang målapplikationen ændrer sig.

Til en ældre Windows-applikation uden API, hvor du vil have visuel automatisering frem for at skrive en hel kodebase til automatisering, skal du vælge UI.Vision med det tilhørende forbehold. Det modtager commits i år, hvilket ikke gælder alle de skrivebordskompatible muligheder her, og AGPLv3-delen af dets dobbelte licens medfører forpligtelser til at dele kildekode, hvis du ændrer og distribuerer open source-softwaren. taskt er andetvalget her. Dets udviklingsgren er aktiv, dets seneste taggede udgivelse kom i maj 2020, og forskellen mellem et projekt, der modtager commits, og et projekt, der udgiver versioner, er det, du skal afveje.

Til visuel automatisering af hvad som helst på skærmen på tværs af platforme skal du vælge Oculix, den aktive videreførelse af SikuliX. Det er stadig primært billedbaseret frem for selektorbaseret, men projektet har nu et IDE og aktive udgivelser frem for blot at være en samling grundfunktioner til billedmatchning. Brug det, når målet er pixels frem for et DOM eller et tilgængelighedstræ, og betragt det arkiverede SikuliX1-repository som den ældre linje frem for det vedligeholdte produkt.

TagUI bliver ved med at blive anbefalet af en grund. Dets scriptsprog minder om almindeligt engelsk, og indlæringskurven er den laveste af de seks. Modvægten står i dets egen README, som siger, at AI Singapore har indstillet vedligeholdelsen og supporten af TagUI, mens projektet fortsætter gennem open source-bidragydere og fællesskabet. Det er ikke opgivelse. Bidragydere tilføjer stadig rettelser på standardgrenen, og repositoryet er ikke arkiveret. Det er heller ikke fremdrift, og Python-wrapperen rpa på PyPI er flere år bag commitloggen. Vælg TagUI til en opgave, du har råd til at fastlåse, ikke til en platform, du planlægger at udbygge i tre år.

OpenRPA er det sværere valg. Det har reelle orkestreringsfunktioner under MPL-2.0, men både dets seneste kode-commit og dets nyeste taggede udgivelse er fra juni 2025, og den eneste repository-aktivitet siden da er automatiske branches til opdatering af afhængigheder. Det er ikke opgivelse, da intet er arkiveret, men der er heller ikke udgivet noget. Afvej det gab i forhold til, hvor længe botterne skal blive ved med at køre.

Når et dedikeret RPA-værktøj er det forkerte svar

Det stærkeste argument imod alt ovenstående kom fra en, der arbejder med dette. I en r/selfhosted-tråd, startet af en operatør, der forsøgte at slippe ud af en kommerciel RPA-kontrakt, argumenterer et svar for Python plus et automatiseringsframework som Selenium i stedet. Mere arbejde at bygge, færre fejl, når det er bygget, og lavere løbende ejerskabsomkostninger end den RPA-software, kommentatoren havde brugt. En anden kommentator i samme tråd er uafhængigt enig.

Det afgørende kriterium er vedligeholdelse. Hvis opgaven skal køre i årevis, volumen er høj, og du eller nogen på dit team kan holde en lille kodebase i live, skal du skrive koden. Selenium og Playwright koster mere på dag ét og mindre på dag fire hundrede, fordi et script, du selv har skrevet, fejler på måder, du kan gennemskue. Hvis opgaven har en tidshorisont på måneder, eller ingen på teamet skriver kode, er RPA-værktøjets kortere vej til en fungerende bot skrøbeligheden værd.

Output fra optagelse af handlinger ældes dårligst. Et script, der genereres ved at se dig klikke, er bundet til det layout, det blev optaget i, så en omdesignet side eller en flyttet knap ødelægger det på en måde, som fejlmeddelelsen sjældent forklarer. Skepsis over for kategorien stikker visse steder dybere: en kommentator i en r/rpa-tråd om open source-muligheder kalder RPA ompakning af scripting solgt til ikke-tekniske ledere, og for en tilstrækkeligt afgrænset opgave er det ikke en urimelig beskrivelse.

Der er også en kategorifejl, som er værd at fange tidligt. Hvis de systemer, du forbinder, tilbyder API'er eller webhooks, har du slet ikke brug for RPA. RPA styrer en brugergrænseflade, fordi der ikke findes en anden vej ind, mens workflowautomatisering benytter indgangen direkte, hvilket er hurtigere at bygge og langt mindre skrøbeligt. Det er et andet værktøjssæt med sin egen omkostningskurve, og n8n's licens og omkostningerne ved selvhosting er det første, der skal afklares der. n8n, Node-RED, Apache Airflow, Kestra og Dagu er alle ét-kliks-apps på vores markedsplads, hvis du vil have en kørende i dag.

UI.Visions nuværende website reklamerer med en Anthropic Computer Use-integration, så kategorien optager allerede agenter, der styrer en skærm ved at ræsonnere om den frem for at matche gemte billeder.

Ofte stillede spørgsmål