Flow-Like: A Typed Board Model Where FlowScript and the Canvas Edit the Same Graph
Flow-Like: Strongly Typed Enterprise Scale Workflows. Built for scalability, speed, seamless AI integration and rich customization.
At a glance
- What is it?
- Flow-Like is a source-available Rust platform for building application logic as typed Flows, with a desktop Studio, a text language called FlowScript, and a Docker Compose self-hosting path. The core judgement: the round-trip between text and canvas is the interesting part, and the licence is the part you need to read before adopting.
- Who is it for?
- Flow-Like fits teams that want executable logic versioned as text while still having a canvas to trace branches and inspect failed runs, and that are willing to run a multi-service Compose stack (API gateway and replicas, execution manager with gVisor sandboxes, queue bridges, WASM compiler, PostgreSQL, Redis, RustFS) on one Linux host. It does not fit anyone who needs a permissive OSI licence today, or who wants a single binary instead of that topology.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Flow-Like targets: logic that outlives the system it was written into
The README opens with a specific complaint: most software work starts in the middle, with a database that already exists and an API whose quirks never made it into the docs. A useful change still has to fit that system and stay understandable after it ships. Flow-Like's answer is to treat one executable process as a Flow, persist its graph as a Board, and let a Rust runtime execute that Board locally or on configured infrastructure. The unit a team owns is the App, which keeps Flows beside the Events and Pages that expose them, the data they use, reusable packages, members, roles, and release settings. An App Event selects a Flow entry, version, and execution location for an API, schedule, chat, form, Page, REST endpoint, MCP server, or another supported caller. That is a governance-shaped problem, not a scripting-shaped one. The intended user is a team that already ships internal tooling and wants the wiring, the access rules, and the run evidence in one place rather than spread across a scheduler, a few scripts, and a dashboard nobody maintains.
FlowScript and the canvas write to one Board, and that is the whole architecture
FlowScript is the typed text form of a Flow. The canvas shows the same Flow as nodes, pins, and connections. The README states plainly that edits from either view update its Board. The mechanism is a reconciler: Studio renders the current Board as canonical FlowScript, and when you apply a source edit, Studio parses it, checks it against the node catalog, and writes the change back as Board commands. The Rust runtime executes that Board. The README's worked example is an incident triage entry that trims a report string, checks whether it contains "production is on hold" case-insensitively, and routes to a log error or a print info node. As text that is a short function with an if and an else. On the canvas the README says the same rule appears as six nodes: Generic Event, Trim String, Contains, Branch, Log Error, Print Info. The trim and contains calls resolve to catalog nodes, and their values travel over typed wires into the Branch node. The README is honest about where each view pays off: FlowScript during broad edits and code review, the canvas when tracing a branch or inspecting a failed run. The round-trip boundaries are documented in FlowBook rather than in the README, which is worth knowing before you assume every construct survives a canvas round trip.
Getting Studio running from source: mise, bun, and one env file
The README lists prerequisites as Git, mise, Tauri 2 system dependencies, protoc, and a C/C++ toolchain. From the repository root the sequence is: git clone --branch dev https://github.com/Rheosoph/flow-like.git, then cd flow-like, mise trust, mise install, bun install, cp apps/desktop/.env.example apps/desktop/.env, and mise run dev:desktop. mise install supplies the toolchain declared in mise.toml, and mise run dev:desktop detects the current platform and starts Studio. Other tasks named in the README are mise tasks, mise run dev:web, mise run dev:docs, mise run dev:book, mise run check, and mise run fix. The detailed setup guide is at docs.flow-like.com/dev/build. Two details matter here. The clone targets the dev branch, not a tagged release, and the recent releases listed are beta-v0.1.10, beta-v0.1.9, and beta-v0.1.8, so you are building pre-1.0 code either way. The presence of mise run check and mise run fix suggests a defined lint and format path, but the README does not say what either task runs or whether check is a gate in CI.
Self-hosting is a Compose stack with gVisor sandboxes, not a container
The checked-in Compose directory runs the browser app, API gateway and API replicas, the execution manager with disposable gVisor sandboxes, queue bridges, a WASM compiler, realtime signaling, server-side Event services, PostgreSQL, Redis, and bundled RustFS object storage, all on one Linux host. Studio stays a desktop application and can connect to that backend. The README points at three starting files: docker-compose.yml for service topology, health checks, ports, volumes, and an optional monitoring profile; .env.example for image tag, URL, identity, storage, replica, and signing-key settings; and flow-like.config.example.json, whose contents are cut off in the material available here. That list is the real adoption cost. Disposable gVisor sandboxes mean the execution manager expects a host kernel that supports them, and the README does not describe a fallback. Bundled RustFS means object storage ships with the stack rather than being delegated to S3, which simplifies a demo and complicates a production topology where you already have storage. Realtime signaling and queue bridges are separate services, so a partial deployment is not something the README offers.
Where Flow-Like is the wrong tool
The licence is the first constraint. The repository metadata reports NOASSERTION while the README badge says BSL 1.1. Those two disagree, and the LICENSE file is the only thing that settles it. If your organisation has a policy against non-OSI licences, that unresolved question blocks adoption before any technical evaluation does. This article takes no position on the licence terms themselves; it only notes that the material contradicts itself and that the file, not the badge, is authoritative. The second constraint is operational. The Compose path is one Linux host with a set of cooperating services, and the README does not describe a minimal or degraded mode. If you want a single binary you can drop on a VM, the README does not describe one. The third constraint is maturity. Releases are labelled beta through v0.1.10, the default branch is dev, and the README directs source builds at dev rather than at a tag. Anyone who needs a stable API surface for a multi-year internal platform is evaluating a moving target, and the README does not make compatibility promises across beta releases.
Compared with n8n and Temporal, the difference is where the type lives
The repository topics name both n8n-alternative and temporal-alternative, so the comparison is invited. n8n is the closer visual analogue: a node canvas you wire together and run. The difference Flow-Like claims is that the canvas is not the source of truth. It is a rendering of a typed Board that also has a canonical text form, and that text form is what you review in a pull request. With n8n, the workflow JSON is the artifact; here the README says Studio renders the Board as canonical FlowScript and applies source edits back as Board commands. Temporal sits on the other side. It is a durable execution engine you drive from code, with no authoring surface, and the README does not claim Flow-Like replaces that durability model. Flow-Like's pitch is closer to keeping the executable logic, its interfaces, data, packages, access, releases, and run evidence in one unit called an App. That is a packaging and governance claim, not a durability claim. Reading the topics as a feature-by-feature equivalence with either project would be a mistake; the material supports a positioning statement, not a benchmark.
Maintenance cost and the licence question you have to resolve first
The maintenance surface is the toolchain and the stack. mise.toml pins the toolchain, so version drift is handled by mise install rather than by documentation you have to follow by hand, which is a real reduction in setup cost. Against that, bun install pulls the JavaScript side, Tauri 2 system dependencies are platform-specific, and protoc implies generated code somewhere in the build. Upgrades mean moving between beta tags, and the README does not describe a migration path between them or state whether Boards written by one beta load in the next. On licensing, the README badge says BSL 1.1 and the repository metadata says NOASSERTION. A Business Source License typically carries an additional-use grant, a change date, and a change licence, and those terms determine whether your intended use is permitted. None of that is visible in the material supplied here. Read LICENSE in the repository, and if your use case is commercial, have someone qualified read it too. This is a description of what to check, not legal advice.
Editorial conclusion
Flow-Like fits teams that want executable logic versioned as text while still having a canvas to trace branches and inspect failed runs, and that are willing to run a multi-service Compose stack (API gateway and replicas, execution manager with gVisor sandboxes, queue bridges, WASM compiler, PostgreSQL, Redis, RustFS) on one Linux host. It does not fit anyone who needs a permissive OSI licence today, or who wants a single binary instead of that topology. Before adopting, read the LICENSE file, because the repository metadata reports NOASSERTION while the README badge says BSL 1.1 and those two disagree; then run mise tasks and mise run check against the dev branch to see what the toolchain actually expects on your platform.
Community notes