DEV Community

Cover image for Vibium: A CLI Browser Automation Tool
Majdi Zlitni
Majdi Zlitni

Posted on

Vibium: A CLI Browser Automation Tool

#webdev #testing #ai #automation

Browser automation has been dominated by tools like Selenium and Playwright. They're very powerful, but you need to understand the DOM, manage selectors, and set up a testing stack before doing anything meaningful.

Vibium takes a different approach, by using a step-based commands.

  • Open a website
  • Find an element
  • Fill a field
  • Click a button
  • Validate the result

Vibium supports two ways for agentic usage:
A command-style skill used for browser automation, and an MCP server for structured workflows. For element discovery, vibium find uses semantic signals like text, labels, placeholders, test IDs, CSS, XPath, and the accessibility tree, then returns stable references that can be reused until the page changes.

Table of Contents

Why Vibium?

Traditional automation usually follows a familiar path:

  1. Find the CSS selector
  2. Inspect the DOM
  3. Set up a framework
  4. Write the code
  5. Maintain the selectors as the app changes

In Playwright, that ends up looking like this:

await page.Locator("#username").FillAsync("Admin");
Enter fullscreen mode Exit fullscreen mode

Nothing wrong with that it works, and it's the standard for a reason. But it requires you to already know the DOM structure before you write a single line.

Vibium flips the workflow around. Instead of hunting for selectors first, you discover elements interactively and reference them as you go:

vibium fill "@e1" "Admin"
Enter fullscreen mode Exit fullscreen mode

Vibium finds the element for you and hands back a temporary reference (@e1) that you can immediately act on.

Installing Vibium

Install the CLI globally with npm:

npm install -g vibium
Enter fullscreen mode Exit fullscreen mode

The first browser-based command you run will automatically download a managed Chrome for Testing build, so there's no separate browser setup step.

Verify everything works:

vibium go https://example.com
Enter fullscreen mode Exit fullscreen mode

A browser will open with the given URL

Your First Vibium Automation

Let's automate a simple login flow against the OrangeHRM demo site.

The plan:

  1. Start recording
  2. Open OrangeHRM
  3. Find the username field and enter a value
  4. Find the password field and enter a value
  5. Click the login button
  6. Stop recording and save the trace

Using Vibium map to scans the current page for interactive elements.

Here a line by line PowerShell script:

vibium record start

vibium go "https://opensource-demo.orangehrmlive.com"

vibium map

vibium fill "@e1" "Admin"

vibium fill "@e2" "admin123"

vibium click "@e3"

vibium record stop
Enter fullscreen mode Exit fullscreen mode

Vibium tutorial

That's a full, working login automation in about ten lines no selector hunting, no test framework scaffolding.

Understanding the Core Commands

Start recording

vibium record start
Enter fullscreen mode Exit fullscreen mode

Open URL

vibium go "https://example.com"
Enter fullscreen mode Exit fullscreen mode

Find element

vibium find placeholder "Username"
Enter fullscreen mode Exit fullscreen mode

Fill input

vibium fill "@e1" "Admin"
Enter fullscreen mode Exit fullscreen mode

Find and click button

vibium find role button
vibium click "@e3"
Enter fullscreen mode Exit fullscreen mode

Recording

This is the one distinction worth internalizing before you build anything real with Vibium.

Recording mode is great for exploring a workflow, and sketching out an automation quickly.

Viewing the Trace

After you stop recording:

vibium record stop
Enter fullscreen mode Exit fullscreen mode

Vibium writes out a record.zip trace file. Open it with the Playwright Trace Viewer:

npm install -g playwright
playwright show-trace record.zip
Enter fullscreen mode Exit fullscreen mode

From there you can step through screenshots, actions, timing, failures, and browser state for the whole session handy for debugging a flaky step after the fact.

playwright record

Where Vibium Fits

AI agents. Vibium's command surface maps naturally onto the kind of steps an LLM already reasons in "open the site, find the login field, enter credentials, click submit, verify the result" which makes it noticeably easier for an agent to generate a working automation than raw locator-based code.

Test automation. Regression suites, smoke tests, end-to-end tests, and user-journey validation (login → create user → update profile → logout, for example) all map cleanly onto Vibium's step-based style.

Internal automation. Repetitive browser work data entry, admin dashboards, report pulling, back-office workflows is often not worth building a full test framework for. Vibium's low ceremony makes it a reasonable fit for these one-off or lightly-maintained scripts.

Vibium vs. Selenium vs. Playwright

Selenium and Playwright still win on ecosystem maturity, plugin support, and battle-tested reliability at scale. Vibium's edge is in how quickly you can go from "I want to automate this" to a working script.

Final Thoughts

Vibium lowers the barrier to entry for browser automation, especially for AI-driven workflows. But it does so by shifting responsibility from the developer to the tool.

If you're a developer, a QA engineer, or you're building AI agents that need to act on the web, Vibium is worth a look.

Top comments (8)

Collapse
 
merbayerp profile image
Mustafa ERBAY •

Interesting approach. I especially like the focus on AI-friendly browser automation instead of raw selectors. One question, though: how stable are the element references across dynamic UIs? Modern SPAs often re-render components after state changes. If Vibium can reliably recover or re-identify elements without manual intervention, that would be a significant advantage for long-running AI agents.

Collapse
 
majdizlitni profile image
Majdi Zlitni • • Edited

Great question @merbayerp, The eN references aren’t static, they are dynamically updated after each interaction but complex re-renders can still break.
For the AI experience it is promising but not that reliable.
I'm planning to go deeper on my next blog.

Collapse
 
merbayerp profile image
Mustafa ERBAY •

Thanks for the honest answer. I actually think that recovery after re-renders is where AI browser automation will either succeed or fail. A resilient strategy (re-identifying elements from semantics, accessibility tree, surrounding context, or even page history) seems more important than the temporary handle itself. Looking forward to your next post—I’d be especially interested in how Vibium plans to balance reliability with speed for long-running autonomous agents.

Collapse
 
ayoub3bidi profile image
Ayoub Abidi •

Good writeup. The @e1 reference idea is actually a smart way to sidestep the whole selector-hunting problem, and the OrangeHRM walkthrough makes it click fast.

Collapse
 
majdizlitni profile image
Majdi Zlitni •

Appreciate it @ayoub3bidi ! Yeah, the @eN simplifies things, especially for a quick automation scenario. Glad the OrangeHRM example helped.

Collapse
 
sleepyfalcon247 profile image
David Frei •

Vibium Is still in its infancy.
Right now, the best tools on the market are probably Endtest and Mabl.

But competition is always good.

Collapse
 
majdizlitni profile image
Majdi Zlitni •

I haven’t heard of Endtest or Mabl before, I’ll take a look, but I noticed they’re not open source.

Collapse
 
sleepyfalcon247 profile image
David Frei •

Endtest and Mabl are cloud platforms, it's a bit like saying that AWS or Azure DevOps are not open source.