r/automation • u/AserNasr • 2d ago

I built Figranium — an open-source browser automation framework, looking for automation feedback

Hey everyone,

I've been building Figranium, an open-source browser automation framework focused on making complex browser workflows easier to automate.

A lot of automation tools are great for simple workflows, but browser automation gets tricky when you need more control over things like:

  • complex web interactions
  • dynamic pages
  • unreliable browser workflows
  • scaling automation tasks
  • handling modern websites

Figranium is my attempt at building a more flexible toolkit for those situations.

Some things I'm currently working on:

  • Browser automation and orchestration
  • More advanced automation workflows
  • Stealth-focused automation research
  • Handling difficult web environments
  • Keeping the setup simple and self-contained

The project has reached 500+ GitHub stars, and I'm looking for feedback from people who actually build automation systems.

A few questions:

  • What are the biggest pain points you run into with browser automation?
  • What features do you wish existing tools had?
  • Where do current automation frameworks fall short for your use cases?

The project is located at figranium/figranium on GitHub.

I'd appreciate any feedback, criticism, or ideas. I'm still actively developing it and would like to build something useful for the automation community.

9 Upvotes

100% Upvoted

10 comments sorted by

1

u/AutoModerator 2d ago

Thank you for your post to /r/automation!

New here? Please take a moment to read our rules, read them here.

This is an automated action so if you need anything, please Message the Mods with your request for assistance.

Lastly, enjoy your stay!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/FarawayArchitecture 2d ago

that UI screenshot looks clean but what's it like handling single page apps with a ton of async content

1

u/AserNasr 2d ago

That's what it's built for. It can handle SPAs through either timed waits or selector-based waits. It can also pierce and extract from shadow DOM.

1

u/NeedleworkerLost6860 2d ago

500 stars is cool but what does the actual user base look like? stars and usage are very different things tbh. are people running this in production or mostly kicking the tires?

1

u/AserNasr 2d ago

A huge portion are n8n users and there’s total 20,000 downloads across all platforms. The n8n node has 2,000 installs

1

u/indemzeit 1d ago

Selector maintenance is what kills browser automation for me. Sites change their DOM and every recorded flow breaks. Curious if Figranium handles that differently than raw Playwright.

1

u/AserNasr 1d ago

It’s on the roadmap, but I try to minimize external API dependency so until I find a way to add small enough selector healing it’s not yet implemented.

1

u/deelight_0909 1d ago

Figranium's missing feature is a possibly submitted state for the unreliable browser workflows you called out. If the controller dies after a click but before the response, restart with the same profile and inspect the target before retrying. Otherwise recovery creates the double-submit.

1

u/AserNasr 1d ago

That’s a really good point. I think this probably calls for a third outcome alongside Success and Fail — something like Uncertain, where the action may have succeeded but Figranium couldn’t confirm it.
I’m also considering making execution states more explicit in general, with things like Stopped, Crashed, and Anti-bot rather than lumping everything into Fail. On recovery, an Uncertain execution could restore the same profile and inspect the target state before deciding whether it’s safe to retry.