Why I Built Another Browser Automation Platform

Aser Nasr — Sat, 22 Aug 2026 18:29:06 +0000

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?

GitHub: https://github.com/figranium/figranium

I got tired of Apify’s proxy bills and SaaS limits, so I built an open-source visual browser engine

Aser Nasr — Tue, 18 Aug 2026 14:05:38 +0000

Headless browser automation usually forces you to choose between two extremes: writing raw Playwright/Selenium scripts from scratch, or relying on heavy SaaS platforms that lock basic API access behind paywalls and charge exorbitant fees for AI execution.

When speed, predictability, and local execution matter, AI-powered execution guesses often introduce unnecessary latency and failure points. Older deterministic tools like UI.Vision exist, but they lack clean API-first integration or modern visual orchestration interfaces.

I built Figranium to fill that gap: an open-source, self-hosted browser automation platform designed around deterministic execution, visual block editing, and instant REST API triggers.

Core Technical Architecture

Figranium is structured as a decoupled, lightweight control plane running inside Docker containers:

Visual Studio (Frontend): Built with Vite, TypeScript, and a custom canvas editor for building and organizing execution graphs.
Execution Engine (Worker): A Node.js execution environment leveraging Playwright for headless Chromium control.
API Engine & Orchestrator: Exposes saved JSON workflow configurations as executable REST endpoints, allowing external services to trigger automation flows on demand.

Why Speed-First & Deterministic Matter

Many modern automation platforms rely heavily on LLM-based element parsing. While useful for dynamic layout changes, LLM execution is nondeterministic, significantly slower, and introduces recurring API token costs.

Figranium prioritizes execution speed and selector reliability. Workflows execute directly against Playwright's native DOM selection engine (CSS/XPath), making runs predictable and fast without extra cloud dependencies.

Architecture Trade-offs

Building a self-hosted visual automation tool comes with clear trade-offs:

Memory Bounds: Concurrent execution is strictly bound by host system memory when spawning multiple headless browser instances simultaneously.
Shadow DOM Traversal: Complex nested shadow DOMs still require targeted custom execution blocks rather than pure visual selectors.

Try It Out

Figranium is completely open-source (GPLv3-licensed) and fully self-hosted.

Homepage: https://figranium.dev
GitHub Repository: https://github.com/figranium/figranium

If you are running web scraping pipelines, synthetic monitoring, or automated testing, I’d love to get your feedback on the architecture and API integration!

DEV Community: Aser Nasr