Browser automation is already a solved problem.
At least, that's what I thought before I started working on Figranium.
There are excellent projects for controlling browsers programmatically, particularly Playwright and Skyvern. If all you need is to open a browser, click things, fill forms, extract information, and interact with a website, the basic capabilities are already there.
So why build another platform?
The problem I wanted to solve was a little different.
From browser automation to reusable automation
Writing a browser automation script is one thing.
Turning that script into something another application can reliably call is another.
You eventually end up building infrastructure around the automation itself:
- How is the workflow configured?
- How are inputs passed to it?
- How is it deployed?
- How does another application trigger it?
- How do you reuse the same workflow?
- How do you make the automation accessible without embedding browser-control code everywhere?
I wanted the browser workflow to be the reusable unit.
That became the basic idea behind Figranium.
Build visually, execute through an API
Figranium lets you construct browser automation workflows visually and then execute those workflows through an API.
The conceptual model is simple:
Visual workflow → browser automation → API endpoint
Instead of every automation becoming a custom application, the workflow itself can become an operation that other software can call.
That makes the browser part feel more like infrastructure rather than something that has to be manually wired into every project.
Why not just use Playwright?
Playwright is one of the technologies that makes this possible in the first place.
Figranium isn't intended to replace the underlying browser automation technology.
The distinction is more about abstraction.
Playwright gives you powerful browser-control primitives.
Figranium focuses on turning browser workflows into reusable, executable tasks.
There are situations where writing Playwright directly is absolutely the better choice. If you're building a complex test suite or need very fine-grained programmatic control, a framework like Playwright gives you exactly that.
But if the goal is closer to:
"I want this browser workflow to exist as a reusable operation that my application can call."
then a higher-level abstraction starts to make sense.
Dockerized execution
Another important part of the project is deployment.
Browser automation has a reputation for becoming annoying once you move it from a development machine into an actual server environment.
Browsers, dependencies, system libraries, processes, and configuration all have to coexist.
That's one reason I wanted Figranium to be Docker-friendly from the beginning.
The goal is to make the workflow something you can actually run as infrastructure rather than something that only works conveniently on the machine where it was created.
What I learned
One of the biggest things I've learned while building this is that browser automation isn't just about browser actions.
The difficult parts quickly become things like:
- workflow representation
- execution state
- deployment
- API boundaries
- error handling
- reproducibility
- making visual workflows expressive enough without making them overwhelming
A visual interface looks simple from the outside, but the system underneath still needs to represent real automation logic.
That has probably been one of the most interesting parts of building Figranium.
Where Figranium is going
There are still plenty of things I'd like to improve.
I'm particularly interested in making browser workflows easier to build, reuse, deploy, and integrate with other software without forcing every user to become an expert in browser automation infrastructure.
Figranium is open source, so I'm also interested in hearing from people who have tried similar approaches.
If you've built browser automation systems before:
What did you end up having to build around Playwright/Selenium to make your automations actually usable as infrastructure?
