DEV Community

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

Posted on

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

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.

Figranium Workflow Demo

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:

  1. Memory Bounds: Concurrent execution is strictly bound by host system memory when spawning multiple headless browser instances simultaneously.
  2. 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.

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!

Top comments (0)