01
Author
A workflow can be edited in the visual Studio or through typed source. Both views operate on the same versioned workflow document.
Open source · Developer tooling · Internal alpha · 2026
FlowCordia: visual workflows and typed code in one governed system
FlowCordia is a Git-native workflow platform for teams that need visual authoring and typed code to remain one product. Business users work in Studio, developers keep typed functions and runtime configuration in the repository, GitHub owns durable review and history, and Trigger.dev remains the execution foundation.
View source on GitHubThe problem
Visual workflow tools are approachable, but they often become hard to review, version, test, and govern once the workflow becomes important software. Code-first systems solve the versioning problem but move the workflow away from the people who understand the business process.
FlowCordia explores the middle ground: one workflow model that can be authored visually, represented as typed source, reviewed through GitHub, deployed against an exact revision, and observed through the runtime that actually executes it.
My role
My work focused on the FlowCordia product layer inside the inherited Trigger.dev codebase: the workflow model, Studio authoring path, repository-backed source, deterministic compilation, GitHub proposal lifecycle, product controls, self-hosting contracts, and the operational surfaces around workflow delivery. I did not rebuild the durable execution engine. Trigger.dev remains the execution plane for deployments, queues, waits, retries, workers, and run observability.
Product boundaries
Current repository state
Internal alpha
Maturity
Git + workflow JSON
Source of truth
Trigger.dev
Execution
Open source
Distribution
How the workflow lifecycle works
02
Test
Testing runs the saved graph through the FlowCordia runtime and returns bounded node traces with input, output, timing, failure, and cancellation state.
03
Stage
Staging validates the graph, compiles the workflow, and verifies the encrypted credential bindings required by the exact release.
04
Deploy
Deployment promotes the immutable staged release through the existing Trigger.dev deployment service instead of creating a second execution engine.
05
Review
Published changes move through governed GitHub proposal branches and pull requests, with repository identity resolved again on the server.
06
Rollback
Rollback promotes a previously deployed release and records the transition instead of silently rebuilding an earlier state.
The architecture decisions
01
One portable workflow model
Studio drafts, repository workflow JSON, generated task source, validation, and execution need to agree on the same workflow contract.
02
GitHub owns durable review
Changes move through proposal branches and pull requests instead of a private approval system that would duplicate repository history.
03
Compile instead of reimplement
FlowCordia compiles workflow intent into the existing Trigger.dev execution plane rather than duplicating queues, retries, workers, or deployments.
04
Fail closed when evidence is missing
Promotion and release paths are designed around exact revisions, checks, policy evidence, and bounded release artifacts instead of optimistic production claims.
Governance and safety contracts
Exact repository identity
The browser does not choose installation IDs or repository coordinates. Project, installation, branch, and repository identity are resolved from authenticated server context.
Secrets stay server-side
Credential values, GitHub private keys, webhook secrets, and environment secrets are not returned through browser loaders or stored inside the Studio workflow document.
Readiness is tied to a commit
Repository readiness checks resolve the production branch to one immutable commit and verify GitHub permissions, workflow paths, the durable index, Trigger configuration, and preview settings.
Runtime proof is version-locked
Preview and release projections match the proposal head, deployed worker, task inventory, and exact workflow version before FlowCordia treats runtime evidence as valid.
What exists today
The repository currently covers repository-backed workflow discovery, durable Studio drafts, visual and typed authoring, deterministic source generation, runtime testing, encrypted credential checks, GitHub proposal branches, exact-head review, preview-environment handoff, immutable staged releases, version-locked runs, rollback, typed repository functions, signed webhook ingress, and self-host readiness contracts.
That breadth is also why the maturity label stays conservative. FlowCordia is still an internal alpha. I am documenting what the repository and captured application can prove today instead of calling the product production-ready before the remaining environment-backed release evidence is preserved.
Product evidence
These screenshots come from the actual FlowCordia application and self-host environment. I removed invalid or duplicated captures and selected the screens that prove the product lifecycle: discovery, visual authoring, typed source, repository governance, deployment, and self-host setup.
Workflow library
The library exposes workflow identity, validity, source ownership, and direct entry into Studio. It is the product entry point, not just a list of Trigger.dev tasks.
Visual Studio
Studio edits one canonical workflow through a visual graph. The saved graph is versioned and is the same workflow that can be opened through the typed source view.
Typed source workspace
The source workspace exposes deterministic TypeScript for the workflow alongside project files and test input. Source is parsed back into the canonical workflow model rather than executed in the browser.
Repository connection
Repository binding is server-owned. GitHub remains the durable review and history layer, while FlowCordia resolves the connected repository and environment instead of trusting browser-supplied coordinates.
Immutable deployment history
Deployments preserve exact version identity and runtime details. Stage and deploy operate on explicit releases, and rollback promotes a previously deployed release instead of mutating an unknown current state.
Self-host setup
The self-host setup surface reports platform readiness without returning secret values to the browser. GitHub App credentials are validated server-side before they are stored.
What I learned
The difficult part of workflow software is not drawing nodes. It is keeping authoring, source, validation, deployment identity, credentials, observability, review, and rollback consistent when several people and systems can change the workflow.
The strongest architecture decision was also a restraint decision: keep GitHub responsible for review and history, keep Trigger.dev responsible for durable execution, and make FlowCordia responsible for the workflow product experience and the contracts that connect those systems.
Related work