# Flowdular

Source: https://flowdular.com/

The software your company runs on, built the way you work.

Customers, catalog, expenses and approvals, on a foundation where accounts, permissions, audit and workspace isolation already work. Describe a new process and it becomes a module.

## Get started

```sh
npm create flowdular@latest my-app
```

Node.js 22.22 or newer. No database server to install.
Follow the [project README](https://github.com/flowdular/flowdular) for setup and development commands.

## A working foundation, not another starter kit.

Flowdular owns the shared concerns every business platform needs, so each capability you add stays a small, explicit module that people and agents can read, test and replace.

## From a business brief to a pull request, with every step checked.

The sandbox ties design and implementation to an approved specification. One session, one preview, one delivery, whether the change touches one module or five.

## The workshop where features get built.

A separate application that turns a business brief into a reviewed module. It drives the coding agent your team already uses, in an isolated workspace, against the same gates the platform runs. Sample data you attach and recorded adapters let it build on realistic input offline.

## Every module owns its API, data, screens, translations and tests.

A module is a package with a spec. The scaffold derives endpoints, permissions, migrations and client entry points from it, and validation keeps them in sync for as long as the module lives.

## Start with the shared work. Build what makes your business yours.

Bring ready-made business capabilities into your application, then adapt them to your processes. Official Modules gives your team reviewed source to build on, so more time goes into the work that sets your business apart.

## The part that decides, kept on a short leash.

A process can hand a case to an agent. What that agent may reach is not a matter of trust: your workspace binds it to a model provider, narrows its tools, and every run is recorded at a pinned version.

## Say what should happen. Watch it run before it is real.

A decision your team keeps making by hand becomes a process you can draw, test on sample data, and only then let near the real thing. Some steps are a rule, some are a person, and some are an agent reading the case and deciding.

## The questions a buyer asks first, answered in the code.

No badges and no promises for a later release. Every line below is a property of the running system, and the file that implements it is in the public repository.

## Built in the open. Owned by you.

Flowdular is developed publicly on GitHub. The core is MIT licensed, the roadmap lives in issues, and a change lands only through the same gates the sandbox runs.

## MIT core. Enterprise when you need it.

Use the foundation freely, in any company, forever. Add an enterprise agreement when your organization needs support, guarantees and integrations.

## Platform capabilities

- **Accounts and workspaces**: Multi-tenant from the first request: a sign-up wizard, workspace slugs in the URL, memberships, invitations and external sign-in providers.
- **Permissions and audit**: Roles built from module.entity.action scopes, API tokens and per-module settings. A module endpoint declares the permission it needs and denies by default, and agent, workflow and automation actions append to a trail that cannot be edited unnoticed.
- **Module composition**: Enable a module with one command. The CLI writes the composition, installs the package, grants scopes, and the running app reloads without a rebuild. An owner then switches each module on or off per workspace from Administration, with dependencies checked and every change audited.
- **Agent runtime**: Reusable agents run against registered tools with leases, recovery, idempotency and durable run history. Tools reach data only through approved endpoints.
- **Workflows**: Typed pipelines on a visual canvas: agent, action, validator, gate, input and output nodes, with dry runs and run history.
- **Administration**: Users, roles, modules per workspace, settings and audit in one place. Module settings live in the module drawer. Two locales out of the box.
- **Business building blocks**: The pieces a business module reaches for instead of writing its own: documents on an encrypted object store, notifications with e-mail and signed webhooks, CSV import, list export, workspace reports, search with a command palette, connectors with allowlisted hosts and sealed credentials, and metering with budgets.
- **Research, data and documents**: Agents search the web through adapters an owner puts in order: the search built into Anthropic and OpenAI models, SearXNG, Firecrawl or a connector, with retries, fallback and a circuit breaker. Every result and page read is kept as citeable evidence with a digest. Data adapters pull records in or push lists out, on demand or on a schedule, with a dry run to check the mapping. Agents read uploaded files as text, and templates render PDF and DOCX with each workspace's edits versioned.
- **Operator CLI**: Dry run by default, --apply to write, --json for machines. Modules add their own namespaced commands with declared risk and approval.

## Workspace security

- **Your data cannot cross into another workspace**: Every workspace-owned table has row-level security enabled and forced, bound to the workspace identifier set for the current transaction. The database refuses a row from another workspace even when application code asks for it.
- **No connection that can switch the rule off**: The role the application connects with is neither a superuser nor allowed to bypass row-level security, and the platform proves that on the live connection through its readiness check.
- **Background work sees less than the app**: Scheduled and recovery work connects as a separate read-only role granted only the few columns it needs to find a job. Payloads, inputs and permission snapshots stay unreadable on that connection.
- **Every action names the permission it needs**: Each module declares its permissions in one file, and its endpoints refuse a request that does not carry the matching one. A route is never open because someone forgot to close it.
- **Recorded history cannot be quietly rewritten**: Agent, workflow, automation and sandbox actions append to a hash-chained trail where each entry covers the one before it. A verify call walks the chain and reports the first entry that no longer matches.
- **Keys never sit in the database**: Provider credentials and stored run payloads are encrypted with keys the deployment supplies from its own secret store. A database dump on its own reveals nothing readable.
- **Sign-in stays with your identity provider**: OIDC sign-in, SCIM provisioning and an MFA policy per workspace ship in the core. An access review lists who holds what, with attestations, so the quarterly question has an answer on file.
- **Destructive steps need a signed approval**: An agent tool that deletes, pays or reaches outside runs only under a grant an approver signed for that request. A production restore refuses to start without one, and the grant is part of the record.
- **Data leaves on your terms, with a receipt**: Every module declares its data classes, so retention sweeps, legal holds, workspace export and erasure with a certificate work the same for every table. Backups carry key fingerprints and support point-in-time recovery.

## Core license

- Platform core, foundation modules, CLI and sandbox
- Commercial use, modification and redistribution
- Self-host on your own infrastructure
- Community support on GitHub

## Common questions

### Can we use Flowdular commercially without paying?

Yes. The core is MIT licensed. Build and sell products on it, modify it and keep your changes private.

### What does the enterprise license add?

Commercial terms, support with response times, help with deployment and upgrades, and the integrations larger organizations require. The code you run stays the same core.

### Which AI models do the agents use?

Agents run through model providers configured per workspace. The default local provider simulates runs without calling any external service, so you can start offline.

### Do we own the modules the sandbox builds?

Yes. A module is ordinary code in your repository, delivered as files or as a pull request. There is no runtime dependency on a hosted service.

[Source code](https://github.com/flowdular/flowdular) · [Core license](https://github.com/flowdular/flowdular/blob/main/LICENSE)
