Using Vibium for RPA (Robotic Process Automation)

Vibium is a code-first way to do RPA (Robotic Process Automation) for browser tasks: it opens a real Chrome browser, logs in, fills forms, downloads reports, extracts data, and moves information between web apps — all from a short Python or JavaScript script. Created by Jason Huggins, co-creator of Selenium and Appium, Vibium runs on the modern WebDriver BiDi protocol, ships as a single Go binary that auto-downloads Chrome for Testing, and is free (pip install vibium or npm install vibium). Unlike heavyweight RPA suites that license per bot and rely on brittle visual recorders, a Vibium "bot" is just code you version in Git and run on cron, a CI runner, or a small server. It auto-waits for elements so long workflows stay reliable, and its AI-native check() lets a bot verify outcomes in plain English. This guide shows how to design, build, schedule, and harden a web-RPA bot with Vibium.

What is RPA, and where does Vibium fit?

RPA (Robotic Process Automation) is software that mimics the clicks, typing, and reading a human does to complete a repetitive, rules-based task. Classic RPA platforms (UiPath, Automation Anywhere, Power Automate) record on-screen actions and replay them across desktop and web apps.

Vibium fits the web-automation slice of RPA. It drives a real browser through WebDriver BiDi, so any task that lives in a web app — a dashboard, an admin portal, an internal tool, a SaaS product — is fair game. It is not a desktop-automation tool; it will not click buttons in a native Windows application. For web work, though, that focus is an advantage: it is lighter, faster to script, and free.

The mental model is simple. A human logs in, reads a screen, types something, clicks a button, waits, and repeats. A Vibium bot does exactly that with go(), find(), type(), click(), and text() — plus auto-waiting so the "wait for the next screen" step is handled for you. If you are new to the API, start with What is Vibium? and Install Vibium.

How does a Vibium RPA bot work end to end?

A Vibium RPA bot follows the same five-stage pipeline every time: a trigger starts it, Vibium launches a browser, the bot navigates and reads a page, it acts (types, clicks, uploads), then it verifies and logs the outcome before moving on or exiting.

Here is a complete, runnable example: a daily bot that logs into a portal, opens a report, and reads a summary value. This is the Python sync client — the default and most common style for Vibium scripts.

from vibium import browser_sync as browser
import os
 
# 1. Launch — headless so it runs on a server with no display
vibe = browser.launch(headless=True)
 
# 2. Navigate & read
vibe.go("https://portal.example.com/login")
 
# 3. Act — log in (credentials from env vars, never hard-coded)
vibe.find('input[name="username"]').type(os.environ["PORTAL_USER"])
vibe.find('input[name="password"]').type(os.environ["PORTAL_PASS"])
vibe.find('button[type="submit"]').click()
 
# Vibium auto-waits for the dashboard to be actionable
vibe.go("https://portal.example.com/reports/daily")
 
# 4. Verify & log
total = vibe.find("#daily-total").text()
print(f"Daily total: {total}")
 
vibe.quit()

The same workflow in the JavaScript sync client looks nearly identical — Vibium keeps naming consistent across languages:

const { browser } = require('vibium/sync')
 
const bro = browser.launch({ headless: true })
const page = bro.page()
 
page.go('https://portal.example.com/login')
 
page.find('input[name="username"]').type(process.env.PORTAL_USER)
page.find('input[name="password"]').type(process.env.PORTAL_PASS)
page.find('button[type="submit"]').click()
 
page.go('https://portal.example.com/reports/daily')
 
const total = page.find('#daily-total').text()
console.log(`Daily total: ${total}`)
 
bro.close()

Notice what is absent: no sleep(), no explicit "wait for element" scaffolding. Vibium's actionability model waits for each element to be present, visible, and enabled before it types or clicks. In RPA, where a slow-loading enterprise portal is the norm, that removes the single most common cause of flaky bots.

When should you choose Vibium over a traditional RPA tool?

Choose Vibium when the task is web-based, repetitive, and rules-driven, and when you value code you can version, review, and run cheaply. Choose a full RPA suite when you must automate desktop applications, orchestrate hundreds of attended bots across a large non-technical workforce, or need a vendor's governance and audit dashboards out of the box.

The table below maps common RPA needs to the right tool.

A fair summary: Vibium is not a drop-in replacement for an enterprise RPA platform that automates SAP on a Citrix desktop. But for the very large category of "log into a web app and do a repetitive thing," a 30-line Vibium script is cheaper to build, easier to review, and trivial to schedule.

How do you build a real data-entry bot?

A data-entry bot reads records from a source (a CSV, an API, a spreadsheet) and re-keys each one into a web form — the single most common RPA task. The pattern is a loop: for each record, fill the fields, submit, confirm, and record the result.

from vibium import browser_sync as browser
import csv
 
vibe = browser.launch(headless=True)
vibe.go("https://crm.example.com/contacts/new")
 
results = []
with open("contacts.csv", newline="") as f:
    for row in csv.DictReader(f):
        # Fill the form fields for this record
        vibe.find('input[name="fullName"]').type(row["name"])
        vibe.find('input[name="email"]').type(row["email"])
        vibe.find('input[name="company"]').type(row["company"])
        vibe.find('button[id="save-contact"]').click()
 
        # Verify: read the confirmation banner Vibium waited for
        status = vibe.find(".toast-message").text()
        results.append((row["email"], status))
 
        # Reset to a blank form for the next record
        vibe.go("https://crm.example.com/contacts/new")
 
vibe.quit()
 
# Log an audit trail of every record processed
for email, status in results:
    print(f"{email}: {status}")

Two RPA habits are baked into this example. First, every record is verified by reading the confirmation message before the loop continues — a bot that types but never checks is a bot that silently loses data. Second, the outcome of each record is logged, giving you an audit trail you can diff against the source file. For the field-by-field mechanics, see Fill and submit a form and find element.

How do you extract data and download reports?

The mirror image of data entry is data extraction: a bot reads values off a page and writes them somewhere structured. Vibium reads text with el.text(), attributes with el.attr(), and can pull entire tables into rows you export as CSV.

from vibium import browser_sync as browser
import csv
 
vibe = browser.launch(headless=True)
vibe.go("https://dashboard.example.com/orders")
 
row_count = len(vibe.findAll("table#orders tbody tr"))
 
with open("orders.csv", "w", newline="") as f:
    writer = csv.writer(f)
    writer.writerow(["Order", "Customer", "Amount"])
    for i in range(row_count):
        cells = vibe.findAll(f"table#orders tbody tr:nth-child({i + 1}) td")
        writer.writerow([cells[0].text(), cells[1].text(), cells[2].text()])
 
vibe.quit()
print(f"Exported {row_count} orders")

For a step-by-step version of this pattern, see Extract a table to CSV. When the "report" is a file (a PDF invoice, an XLSX export), Vibium handles the download click and the file-ready wait; the Handle a file download wait guide covers saving the file and confirming it landed on disk.

Sometimes the cleanest source is not the rendered page but the underlying API call the page makes. Vibium can observe those requests — Monitor network requests shows how to read JSON responses directly, which is often faster and more stable than scraping HTML.

How do you make an RPA bot reliable enough to trust?

A bot you run unattended must survive slow pages, missing elements, and pop-ups without corrupting data or hanging forever. Reliability in Vibium comes from four practices: lean on auto-waiting, verify every consequential step, isolate failures per record, and always clean up the browser.

The most important reliability rule is verify, don't assume. Vibium's AI-native check() lets a bot confirm an outcome in plain English, which is invaluable when the "success" signal is visual rather than a fixed element.

# Deterministic check — read a known element
assert "Success" in vibe.find(".toast-message").text()
 
# AI-native check — describe the outcome in plain English
result = vibe.check("the record was saved and no error banner is shown")
if not result.passed:
    print(f"Save failed: {result.reason}")

The table below lists the failure modes that break RPA bots and how Vibium addresses each.

Here is the resilient loop skeleton every production Vibium RPA bot should follow:

from vibium import browser_sync as browser
 
vibe = browser.launch(headless=True)
try:
    for record in records:
        try:
            process(vibe, record)          # fill + submit
            verify(vibe)                    # confirm success
            log_ok(record)
        except Exception as e:
            log_error(record, e)            # record it, keep going
            vibe.go(FORM_URL)               # reset to a known state
finally:
    vibe.quit()                             # always clean up

Pop-ups that hijack a flow are common on enterprise portals; Handle a cookie banner shows the dismiss-first pattern. And because element selectors are the part of a bot most likely to drift over time, keep them in one place — the Page Object Model pattern keeps a long-lived bot maintainable as the target site changes.

How do you schedule and run bots unattended?

An RPA bot only pays off when it runs on its own. Because a Vibium script is a normal Python or JavaScript program, you schedule it with the same tools you already use — cron, Windows Task Scheduler, systemd timers, GitHub Actions, or any CI runner.

The one rule for unattended runs is go headless. Pass headless=True so no visible browser window is required on a server that has no display.

# Headless launch for servers, containers, and CI
vibe = browser.launch(headless=True)

A minimal cron entry that runs a report bot every weekday at 7 a.m.:

# m h dom mon dow   command
0 7 * * 1-5   cd /opt/bots && /opt/bots/.venv/bin/python daily_report.py >> /var/log/daily_report.log 2>&1

Because Vibium is a single Go binary that auto-downloads Chrome for Testing, there is no separate browser install or driver-version juggling to maintain on the server — a real operational win over stacks that pin a browser build to a driver build. For containers, headless mode, Linux dependencies, and CI specifics, follow Run Vibium on a server.

Where does AI fit into Vibium-based RPA?

AI enters Vibium RPA in two distinct places, and it helps to keep them separate. First, inside a script via check() and do(), which let a bot verify outcomes and take fuzzy actions in natural language. Second, outside a script via Vibium's built-in MCP server, which lets an AI agent such as Claude drive the browser directly.

The built-in MCP server is what makes Vibium "AI-native" for RPA orchestration. Instead of writing every selector, you can let an agent plan and execute steps against a live browser, which is powerful for exploratory or one-off automation where hard-coding a script is not worth it. Setup is one command:

claude mcp add vibium -- npx -y vibium mcp

See Vibium MCP in Claude Code for the full walkthrough. A pragmatic pattern is to combine both: use an AI agent to discover a workflow interactively through MCP, then harden the reliable path into a deterministic scheduled script for daily production runs.

Two honest caveats. AI-driven steps cost tokens and add latency, so they belong at decision points and verification — not in a tight 10,000-record loop where deterministic find()/click() is faster and cheaper. And AI checks are probabilistic; for anything financial or compliance-sensitive, back them with a deterministic assertion on a known element.

How does Vibium compare to writing RPA on Selenium or Playwright?

If you already automate the web, you might reasonably ask why not just use Selenium or Playwright as your RPA engine. All three can drive a browser; the differences are in protocol, packaging, and built-in AI.

The fair read: Selenium and Playwright are more battle-tested and have larger ecosystems, and for a team already standardized on either, that is a good reason to stay. Vibium's edge for new web-RPA work is the lean single-binary install, auto-waiting by default, and the AI-native verification that neither classic tool ships. For deeper, honest breakdowns see Vibium vs Playwright and Vibium vs Selenium.

A quick RPA-with-Vibium checklist

Before you promote a bot to production, confirm it does all of this:

• Launches headless (headless=True) for unattended runs.
• Reads secrets from environment variables, never hard-coded.
• Verifies every consequential step with text() or check().
• Wraps each record in try/except so one failure does not abort the run.
• Uses try/finally so the browser always closes (quit() / close()).
• Writes an audit log of what it processed and any errors.
• Keeps selectors in one place (a page object) for easy maintenance.
• Is scheduled by cron, Task Scheduler, or CI — not run by hand.

If you want the terminology behind any of this, the glossary defines RPA, actionability, WebDriver BiDi, headless, and more in plain English.

Next steps

• What is Vibium? — the fundamentals in five minutes
• Install Vibium — get set up with pip or npm
• Automate a login flow — the entry point of most bots
• Fill and submit a form — the core data-entry pattern
• Extract a table to CSV — the core data-out pattern
• Run Vibium on a server — headless, containers, and CI
• Vibium MCP in Claude Code — let an AI agent drive the browser
• Page Object Model — keep long-lived bots maintainable
• The Master Vibium course — the guided path with projects and reviews