Flow-Like: typed workflows in Rust, with FlowScript and a canvas over one Board

What Flow-Like solves for teams whose logic already has a home

Most software work starts in the middle. The README says so directly: the database already exists, the API has quirks that never made it into the docs, and a useful change still has to fit that system and stay understandable after it ships. Flow-Like's answer is to make one executable process, the Flow, the thing you own and review, and to keep it beside the Events and Pages that expose it, the data it uses, reusable packages, members, roles and release settings. That bundle is called an App, and the App is the unit a team ships.

The intended reader is not someone who wants a drag-and-drop toy. It is a developer who wants a workflow to be typed and reviewable in a repository, but who also wants to trace a branch visually when a run fails. The repository topics list n8n-alternative, retool-alternative and temporal-alternative, which tells you the comparison set the maintainers have in mind. The difference is the artifact: not a JSON blob behind a hosted editor, but a Board that the Rust runtime executes and that both editing surfaces read and write.

One Board, two editors: how FlowScript and the canvas stay in sync

The mechanism is a round trip. FlowScript is the typed text form of a Flow. The canvas shows the same Flow as nodes, pins and connections. Studio renders the current Board as canonical FlowScript; 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 then executes that Board.

The README's incident-triage example makes the mapping concrete. A call like `trim` or `contains` in FlowScript resolves to a catalog node, and its value travels over a typed wire into a Branch node. The checked-in FlowScript is said to generate the six-node canvas with the real reconciler and Studio auto-layout, so the picture is not a mock-up. The README is also honest about where each view pays off: FlowScript earns its keep during broad edits and code review, while the canvas is for tracing a branch or inspecting a failed run.

The interesting constraint is the node catalog. A source edit is not free-form code that compiles to anything; it is parsed and checked against the catalog before it becomes Board commands. That is what keeps the two views reconcilable, and it is also the ceiling on what FlowScript can express. The README points to FlowBook for the current round-trip boundaries, which is the honest place to look before assuming an arbitrary construct survives the trip.

Installing Flow-Like: build Studio from source or run the Compose stack

There are four documented ways in: the hosted web app at app.flow-like.com, a Studio download for macOS, Windows or Linux, a self-hosted Compose stack, and a source build of the `dev` branch. The source route is the one with full instructions. The README asks for Git, mise, Tauri 2 system dependencies, `protoc`, and a C/C++ toolchain, then gives this sequence from the repository root.

git clone --branch dev https://github.com/Rheosoph/flow-like.git
cd flow-like
mise trust
mise install
bun install
cp apps/desktop/.env.example apps/desktop/.env
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. If the build fails, the first thing to check is the Tauri prerequisite list, because that is the step most likely to be incomplete on a fresh machine. The README lists additional tasks: `mise tasks` to enumerate them, plus `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.

For a first real use, the incident-triage example is the shortest path to seeing the round trip. It receives an incident report and chooses a log path.

use log::*

eventsGeneric triageIncident(payload: Struct, report: string) {
    const normalized = report.trim()
    if (normalized.contains({ substring: "production is on hold", ignoreCase: true })) {
        error({ message: normalized, toast: false })
    } else {
        info({ message: normalized, toast: false })
    }
}

Paste that into a Flow, then switch to the canvas. You should see the rule as six nodes: Generic Event, Trim String, Contains, Branch, Log Error and Print Info. That switch is the whole product in one gesture, and it is the first thing worth verifying on your own machine.

The Compose stack and what it assumes about your host

Self-hosting is not a single 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 on one Linux host. Studio stays a desktop application and can connect to that backend. The word to notice is Linux: gVisor sandboxes and this service list are not a macOS or Windows deployment story.

Three files are the entry points. `docker-compose.yml` holds service topology, health checks, ports, volumes and an optional monitoring profile. `.env.example` covers image tag, URL, identity, storage, replica and signing-key settings. A `flow-like.config.example.json` is also checked in. The signing-key and replica settings are the two that deserve a decision before you start, because they are the ones a team usually wants to source from its own secret store rather than a copied example file.

The trade-off is density. You get a complete execution environment with sandboxing and object storage in one command, and in exchange you are operating a multi-service stack on one host. The README does not describe a high-availability topology for this Compose path; the Cargo workspace does list separate AWS, Azure, GCP and Kubernetes backends, but those are not what the Compose directory documents.

Where Flow-Like is the wrong tool

The release history is the first limitation, and it is not a small one. The most recent release is beta-v0.1.10, published on 2026-09-07, following beta-v0.1.9 on 2026-09-05 and beta-v0.1.8 on 2026-08-19. The version number is honest about maturity. Anyone who needs a stable interface to build a business on, or a support contract with response times, is looking at the wrong project today.

The second limitation is the build surface. A source install pulls in Rust, Tauri 2 system dependencies, `protoc`, a C/C++ toolchain, mise and bun. That is a reasonable ask for a Rust team and a heavy one for a data analyst who just wants to connect two SaaS APIs. The hosted web app and the Studio download exist precisely because the source path is not for everyone, but the README does not document what the hosted tier includes or how long runs are retained there.

The third is the round trip itself. Because source edits are checked against the node catalog, FlowScript is not a general-purpose language you can push arbitrary logic through. The README defers the exact boundaries to FlowBook rather than stating them inline. If your Flow needs a construct outside the catalog, the text view will not be the place to express it. And the README does not document rollback of a Board to a previous version, so treat version history as something to confirm before you rely on it.

Flow-Like compared with n8n and Temporal

The repository tags both n8n-alternative and temporal-alternative, so the honest comparison is with both, and they fail in different directions. n8n is a node-based automation tool where the workflow is assembled in a hosted or self-hosted editor and the integration catalog is the centre of gravity. Flow-Like's centre of gravity is the typed Board: the same graph is canonical FlowScript that you can diff and review, and the node catalog exists to keep the two views reconcilable rather than to maximize the number of connectors. If your problem is gluing a hundred SaaS APIs together, n8n's catalog is the more direct answer.

Temporal is a durable execution engine where you write ordinary code in a supported language and the server guarantees workflow replay. Flow-Like overlaps on the execution side, since a Board is executed by a Rust runtime locally or on configured infrastructure, but it does not present itself as a durability and replay guarantee. It is an authoring and packaging platform first. Teams that already have Temporal and a codebase they like are unlikely to gain anything by moving the execution layer; teams that want the workflow itself to be the reviewable artifact are the ones the design is aimed at. The README does not publish a feature-by-feature comparison with either tool, so treat the tags as positioning rather than a specification.

Licence, maintenance and the cost of upgrading

The repository's README badge states BSL 1.1, while the repository metadata reports the licence as NOASSERTION. Those two do not agree, and the difference matters: a Business Source Licence is source-available, not open source in the OSI sense, and its terms typically restrict production or commercial use for a period before converting to a permissive licence. The LICENSE file is the authority here, not the badge and not this article. Read it before you plan a deployment, and if the terms are load-bearing for your business, get your own legal read rather than trusting a summary.

On maintenance, the last push to the repository was on 2026-09-10, and the repository is not archived. Three beta releases landed in the three weeks before that. The project is moving quickly, which cuts both ways for upgrade cost: fixes arrive fast, and a fast-moving beta means a Board written against beta-v0.1.8 may need attention by beta-v0.1.10. The README does not document a migration or compatibility policy between beta releases, so pin the version you deploy and read the release notes for each one you take. The upgrade cost is not the download; it is re-verifying that your Flows still reconcile against the node catalog after the catalog changes.

Editorial conclusion

Adopt Flow-Like if you want a Flow's persisted Board to be the single artifact that text, canvas, packages and run evidence all point at, and you accept a beta numbered v0.1.10. Skip it if you need a hosted service with an SLA, or if your team will not run a Rust and Tauri build. Before committing, read the round-trip boundaries in FlowBook, then open apps/backend/docker-compose/.env.example and check whether the image tag, replica and signing-key settings match your host.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Rheosoph/flow-like on GitHub