OOperations Demoactive
FFinance Demoactive
NNorthwind Tradingactive
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.
Agentic business platform
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.
$
MIT licensed core. Self-host anywhere.npm create flowdular@latest
app.flowdular.com/operations-demo/dashboard
Dashboard
Parties128
Catalog items412
Open expenses36
Agent runs today57
Recent activity
Orders
Open orders3
Awaiting approval1
This month16 440
| Order | Customer | Status | Total |
|---|---|---|---|
| SO-1041 | Acme Industries | Pending approval | 12 400.00 |
| SO-1040 | Northwind Trading | Approved | 3 180.00 |
| SO-1039 | Globex Logistics | Draft | 860.00 |
MITCore license
22Core modules
6Delivery gates
22Agent skills
TypeScriptEnd to end, server to screen
The platform beneath your product
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.
sales.orders.readsales.orders.managesales.orders.approveauth.users.readcatalog.items.managesystem.settings.manage
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.
authuserscatalogagentsworkflowsorders
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.
lease acquired run r_41dtool catalog.items.search 3 rowstool parties.contacts.create idempotentrun committed audit #1 284
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.
Allow sign-up
Email confirmation
Session lifetime
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.
documentsnotificationsimportexportsreportssearchconnectorsmeteringapprovalsdirectoryaccessaudit
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.
researchevidenceadapterspdfdocxxlsxpptxcsvtemplates
Operator CLI
Dry run by default, --apply to write, --json for machines. Modules add their own namespaced commands with declared risk and approval.
$pnpm flowdular doctor --json
$pnpm flowdular module new sales.orders --spec modules/sales-orders/spec/module.yaml
$pnpm flowdular module enable sales.orders --apply
$pnpm flowdular auth sync-scopes --module sales.orders --apply
$
Workflows
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 need
Before we pay a new supplier, somebody should check them. Right now it depends on who opens the invoice.
Finance lead
You draw it
Five steps, named the way your team already says them out loud.
You test it
It runs on sample data first. No agent is called and nothing is written.
Going live is a separate confirmation.
It runs without you
Then it runs on a schedule you set, or when another system calls in.
Pull the data
Read and decide
Check your rule
Approve paymentclears the rule
Send to a personneeds a person
No elevated permissions
Publishing checks every permission the process needs against the person publishing it, and checks again before each live run.
No silent changes
What runs live is the revision you confirmed. Editing it creates a new draft that has to be tested and confirmed again.
No duplicate runs
A schedule fires at most once per slot, and a slot missed while the platform was down is skipped, never replayed. A webhook needs a fresh, valid signature.
No missing history
Every run opens step by step in an inspector, and the record is chained so an entry edited later stops matching.
Security
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.
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.
How a change ships
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.
AM
We need customer orders with an approval step above 10 000.
Planner routed the brief to
BusinessUXBackendFrontendAgentic
id: sales.ordersversion: 0.1.0capabilities: [api, database, client, translations]entities: - orderpermissions: - sales.orders.read - sales.orders.manage - sales.orders.approverules: - approval above 10000
Gates for sales.orders
spec-schema0.4s
module-schema0.6s
dependencies1.1s
typecheck8.2s
tests5.7s
format0.9s
6 of 6 passed
Orders
Rendered inside the real shell, with real permissions
feat(sales.orders): orders with approvalsandbox/orders-approval into main
spec-schemamodule-schemadependenciestypechecktestsformat
Gates passed · Ready for review
Sandbox
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.
See how it works
Your coding agentClaude Code or Codex CLI on your machine, or the bundled simulation that calls nothing.
Isolated workspaceEach session gets a real pnpm workspace linked to the platform packages, never your repository.
Reviewed deliverySix gates and a live preview every turn, then eject into modules/ or open a pull request.
Official Modules registry
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.
01
Choose what you need
Add capabilities one at a time through the CLI. Keep your application focused as your business grows.
02
Keep the source
Modules live in your project, with their screens, data model and tests. Your team or coding agent can inspect and change them.
03
Build on reviewed releases
Contributions go through tests and review before release. Your team decides when to install, enable and update each module.
Official Modules
Select the capabilities you need
Tests + review
Your application
Source in your project
Your business logic
Built something others could use?
Share a module through a pull request. Contributor skills guide coding agents through implementation, tests and review; maintainers decide what joins the registry.
The module contract
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.
- spec/module.yaml
- module.json
- migrations
- 0001_catalog_core.up.sql
- 0002_catalog_history.up.sql
- src
- acl/permissions.ts
- api/endpoints.ts
- agent/tools.ts
- services/database-repository.ts
- client/CatalogView.tsrx
- platform.ts
- translations
- en.json
- pl.json
- tests
- endpoints.test.ts
- migrations.test.ts
const list = defineEndpoint({ id: 'catalog.items.list', path: '/api/catalog/items', methods: ['GET'], access: { kind: 'permission', permission: PERMISSIONS.read }, handler: ({ octane }) => jsonResponse({ items: service.list(principalFromContext(octane)!.tenantId), }),});
- An approved spec/module.yaml is the source of intent.
- Permissions are declared once and enforced on every route.
- Every query is tenant-scoped and every mutation checks the session.
- Translations ship per module and are validated for key drift.
system.coreauth.coreusers.coreprofile.coreaccess.coredirectory.coreaudit.coreapprovals.coredocuments.corenotifications.coreimport.coreexports.corereports.coresearch.coreconnectors.coreadapters.coreresearch.coremetering.coreagents.coreautomations.coreworkflows.coresandbox.coreparties.corecatalog.coreexpenses.coresystem.coreauth.coreusers.coreprofile.coreaccess.coredirectory.coreaudit.coreapprovals.coredocuments.corenotifications.coreimport.coreexports.corereports.coresearch.coreconnectors.coreadapters.coreresearch.coremetering.coreagents.coreautomations.coreworkflows.coresandbox.coreparties.corecatalog.coreexpenses.core
Agents
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.
- A run is pinned to one immutable agent revision.
- The workspace narrows the tools the code allows, and each run narrows them again.
- A tool outside that set is refused before it is called.
- Provider credentials are encrypted with a key held outside the database.
The same guardrails in your editor
Twenty-two skills in .ai/skills load into your coding agent, and AGENTS.md carries the contract, so the rules are the same in the sandbox and in your terminal.
/spec-interview
/spec-approval
/module-new
/module-update
/core-extend
/auto-review
/bug-hunt
/perf-audit
/ux-design
/auth-security-review
/test-hardening
/migration-authoring
/database-adapter
/translations-i18n
/cli-extension
/agent-tool-design
/business-agent-design
/integration-adapter
/workflow-development
/variables
/deploy-operate
/release-eject-pr
Tools this run could call
9declared in code4kept by the workspace2granted to this run
parties.customer.getcatalog.item.list
run.queuedidempotency=inv-8f2
agent.startedrevision=7 attempt=1
tool.callparties.customer.get
tool.deniedTOOL_NOT_GRANTED
run.completed1.4s
Model provider bound per workspace
Open source
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 licensed core with no seat limits.
- Self-host with the included Docker Compose and Kubernetes manifests.
- CI verifies types, tests, specs, formatting, the build and the container.
- Contribute a module or a fix through a pull request with gate evidence.
flowdular/flowdularThe agentic foundation framework for OctaneJS
Licensing
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.
CoreMIT license
Free foreverThe complete foundation in the repository.
- Platform core, foundation modules, CLI and sandbox
- Commercial use, modification and redistribution
- Self-host on your own infrastructure
- Community support on GitHub
EnterpriseCommercial license
Per organizationFor companies running Flowdular in production at scale.
- Commercial terms with warranty and indemnification
- Priority support and fixes with an SLA
- Guided deployment, upgrades and module reviews
- SAML sign-in and the integrations your organization requires, built to order
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.
Start here
Keep the foundation. Shape everything above it.
Walk through what the platform already does, or start a working app on your machine in one command.
Run it locally
$npm create flowdular@latest my-app
$cd my-app
$pnpm flowdular setup quick --apply --confirm reset-local-auth
$pnpm dev
See what it does
The product tour, the module contract and the code behind every claim on this page.
See demoBrowse the source on GitHub