Show HN: Oomol – A local-first, code-first workflow automation engine

[monica-guli]

Hi HN,

We’ve been working on [OOMOL](https://oomol.com) for the past few years – a workflow automation platform built for developers.

Unlike Zapier or n8n, OOMOL runs locally in a containerized environment, supports full Python and Node.js (with third-party libraries), and gives you the same flexibility as writing real code. It’s like VS Code meets workflow automation.

Key points: - Local-first (no cloud lock-in) - Python and Node.js support (you can mix both!) - Pip/npm libraries supported out of the box - Fully visual with programmable nodes - Share & reuse flows as containers or subflows

We’re still early, and would love feedback from the HN community. Happy to answer anything!

[danfunk]

I hold a lot of hope that visual workflow tools like this will help more people use software to solve their own problems. With an LM's assistance a lot more people can create code but they need some kind of organizational structure - a software architecture that "citizen developers" can easily conceptualize. Targeting Data analysts and scientists seems like a good idea.

I admire the openness of the platform you are creating. I appreciate your blog post's note that current SaaS, cloud native, multi-tenant systems don't permit the kind of flexibility you need. There is substantial depth here - you have been working on this a while. Secrets for api calls, a repository for sharing solutions. I'd try it if it ran on Linux.

My company is working on a similar project, and I have mad respect for your efforts and how far you have come.

[monica-guli]

Really appreciate your thoughtful comment — it means a lot, especially coming from someone clearly thinking deeply about the space.

We share your hope: with the help of LMs, more people are able to write code, but they still need structure — something in between scripting and architecture. Our goal is to make that structure accessible, visual, and developer-friendly. Targeting data analysts and scientists is definitely something we're thinking about.

Glad you also picked up on our local-first direction — that was one of the core motivations behind OOMOL. We were frustrated by the limits of cloud-native SaaS: hard to customize, hard to self-host, and hard to mix real code into the flow. We wanted something that feels more like building actual software — but still composable.

At the moment, OOMOL runs on macOS and Windows. If you’re interested in Linux support or have ideas about your use case, we’d love to chat — we’re always learning from other builders in this space.

And likewise — mad respect for what you're working on. Would be great to swap ideas sometime.

Feel free to reach out at [e-mail] — always happy to connect.

[zazaulola]

Explain to me what tasks can be solved in the approach with flows? I used Node-Red in some automation processes. I managed to solve only simple problems that are easy to solve without AI. But how do you program in this style? What does the flow style look like, for example, a program to find the shortest solution of a sokoban or game 15?

PS. Usually, when I need to make all photos in the folder black and white, I use imagemagick.

[monica-guli]

Great question — and I completely agree with your experience. Most flow-based tools like Node-RED or n8n are great for simple, event-driven tasks — but once you try to model anything non-trivial, like search algorithms or puzzle solving, they tend to fall short.

OOMOL takes a different approach.

Each node is a fully programmable unit — you write full Python or Node.js code, import pip/npm libraries, manage state, and do whatever logic you want. The flow just connects these pieces in a modular way.

So when it comes to problems like solving Sokoban or the 15 puzzle, it’s not about drawing a visual BFS graph — instead, you might structure it like:

- One node to define the state structure - One node to generate next states - One node to manage a queue (e.g. in memory or Redis) - One node to evaluate whether the goal is reached - And inside the node code: your BFS or A* logic

In this sense, OOMOL doesn’t force you to express logic visually — the *code is the logic*, and the *flow is how you organize and compose that logic across tasks*. Think of it as “wiring together programmable building blocks” rather than trying to drag-and-drop logic trees.

That said, you raise an important point: *for many simple tasks — like batch processing images using ImageMagick — scripts or shell commands are 100% the right tool.* OOMOL isn't trying to replace that.

Where OOMOL helps is when: - You have multiple steps to coordinate (e.g. conditionally processing based on metadata) - You need to integrate with APIs, databases, or cloud storage - You want to track, retry, or debug failed tasks - You’re composing reusable automation pipelines that grow in complexity over time

In short: > *Not every task needs a workflow engine — but once you start composing real logic across systems, code + flow gives you both power and structure.*

We’re still early and figuring out how to best serve developers like you — really appreciate you pushing on this distinction. Would love to hear what types of things you’ve tried to automate, and where tools like Node-RED started to fall short.