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?
- Installing Vibium
- Your First Vibium Automation
- Understanding the Core Commands
- Recording
- Viewing the Trace
- Where Vibium Fits
- Vibium vs. Selenium vs. Playwright
- Final Thoughts
Why Vibium?
Traditional automation usually follows a familiar path:
- Find the CSS selector
- Inspect the DOM
- Set up a framework
- Write the code
- Maintain the selectors as the app changes
In Playwright, that ends up looking like this:
await page.Locator("#username").FillAsync("Admin");
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"
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
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
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:
- Start recording
- Open OrangeHRM
- Find the username field and enter a value
- Find the password field and enter a value
- Click the login button
- Stop recording and save the trace
Using
Vibium mapto 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
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
Open URL
vibium go "https://example.com"
Find element
vibium find placeholder "Username"
Fill input
vibium fill "@e1" "Admin"
Find and click button
vibium find role button
vibium click "@e3"
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
Vibium writes out a record.zip trace file. Open it with the Playwright Trace Viewer:
npm install -g playwright
playwright show-trace record.zip
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.
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 (1)
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.