$ cat ./pitch.txt

> turn your internal functions
into workflows your customers compose.

your typescript becomes a node. your customers describe the workflow in chat (agent in alpha). your nodes run in your VPC; your data never leaves it.

[ get-early-access ]
● typescript● react flow● grpc + mtls
fetch-customer-orders.tsready
// runs in your worker, your VPC, your auth context
import { defineNode } from "@flowget/types";
import { z } from "zod";
import { db } from "@/lib/db";

export const fetchCustomerOrders = defineNode({
  id: "fetch_customer_orders",
  category: "data",
  input: z.object({ customerId: z.string() }),
  output: z.object({
    orders: z.array(z.unknown()),
    count: z.number(),
  }),
  async run({ input }) {
    const rows = await
      db.orders.findByCustomer(input.customerId);
    return { orders: rows, count: rows.length };
  },
});

$ man 1 the-wedge

your code becomes a first-class node.

Write a TypeScript function with your DB, your ORM, your auth context. Drop it in your REGISTRY_DIR — the worker discovers it, the node shows up in the builder, and the AI agent (in alpha) can compose with it.

// your worker, your VPC
export const chargeCustomer = defineNode({
id: "charge_customer",
category: "payments",
defaultRetryPolicy: { maximumAttempts: 3 },
async run({ input }) {
return stripe.charges.create({ … });
},
});
customer — recent orders
fetch_customer_orders
LIVE
In
customerIdtext · req
Out
ordersobject[]
countnumber

no marshalling. no HTTP boundary. the node runs in your worker, in your VPC, with the same auth context as the rest of your app.

$ ai authoring (alpha) · grounded in your catalog

your customers don't want to draw graphs.
they want to solve problems.

Your customer describes the outcome. An agent — in alpha — composes the graph from real catalog nodes. The guardrail is real today: the engine rejects any node that isn't in your catalog, no matter who (or what) authored it. They review, authorize, and ship — all without leaving the chat.

$ embedded-chat · acme.exampleAI · OpenRouter · BYO model
simulation · ai builds the workflowsimulation
waiting for the agent to compose…
the graph will render when the chat lands

no hallucinated steps.the engine rejects any node that isn't in the catalog you declared — no matter who (or what) authored it — and validates every generated workflow against your types before it's saved.

catalog-grounded

the engine only admits nodes from your declared catalog— regardless of author. made-up steps don't make it past validation.

always a draft

generated workflows land disabled. review the graph, test in sandbox, then enable. no silent prod changes.

conversation, not commands

refine in chat — "change the filter to less than 700". the agent (in alpha) updates the graph; you review the diff.

ai SDK (alpha), your chat UI

the authoring SDK (in alpha) runs the model orchestration, prompts, safety, and billing — you embed it into your existing chat. brand it your way. no iframe, no vendor chrome.

honest FAQ

"then can you read my customers' chats?"

no. the authoring agent (in alpha) runs inside your worker — the same BYO-worker boundarythat protects your domain data. the provider boundary ships today: the LLM your nodes call runs worker-side, on your key. we orchestrate; we don't see plaintext.

BYO LLM key
plug in your own provider key — OpenRouter by default, or bring your own / self-host. calls go worker → provider direct. we never see the bytes.
chats live in your DB
every message and draft persists only in your tenant database. our control plane stores catalog manifests + decisions taken — never message content.
auditable boundary
inspect exactly what crosses our line: metadata (which tools fired, validation results, cost), not content. the provider boundary ships today; the authoring agent is in alpha.

$ cat ./billing.md

your customer knows exactly what they're spending.

no hidden costs. no fine print. no surprise invoice at the end of the month. every node that reports a cost is itemized on its own line — down to the node, per execution — the customer sees what they paid for, you charge for what they actually used.

per-node cost, per execution
each node can report its own cost — LLM tokens, external API calls, storage, compute — in the unit you define (USD if you convert it). the per-node cost event is exactly what you aggregate up to the workflow and roll up to each of your customers.
pass-through billing
define how each node is priced. we run it, attach the cost to that node, and emit it — you decide how it rolls up to a customer. the per-node cost event feeds straight into metered billing — Stripe metered, Lago, Orb — you subscribe once and forward, no bespoke metering pipeline.
no fine print
the dashboards you build show: how many runs, what each cost, why. if a number changes, the breakdown changes with it. trust by default.
…or keep it hidden — your call
don't want to expose costs to your customer? flip a config flag and the entire breakdown disappears from their view. show all, show totals, or show nothing — no-code, plug-and-play, no rewrite.

the principle

whether the customer sees the bill or not is your decision — but if you do show it, it has to be the truth.

execution breakdown · weekly-summary-2026-W21ok
1
LLM Call · resumo executivo
llm_call-summary01
$0.0421
3.4s
2
Create Report · PDF
create_report-pdf01
$0.0184
8.1s
3
HTTP Request · webhook
http_request-webhook01
$0.0024
877ms
4
HITL · approve
human_in_the_loop-approve01
$0.0002
16.6s
5
Cache · weekly-summary-llm
cache-llmcache01
HIT
$0.000028
38ms
6
Trigger · schedule
schedule-trig01
$0.0000
0ms
7
Admin Notification
create_admin_notification-ok01
$0.0000
124ms
cost compositionrun #4827 · 29.1s elapsed
LLM 68%compute 20%storage 8%HITL 4%
subtotal · 7 nodes$0.0631pass-through margin · 15%$0.0095customer pays$0.0726

illustrative — your margin, computed in your app.

$ ls -la ./workflows

workflows are code. the graph is the debugger.

every workflow is a JSON document. track it in your git repo when engineers own it (PR review, CI deploy, rollback like code), or persist it in your database when your customers author it through the AI agent (in alpha). either way, the JSON is the source of truth — code and the AI agent both emit it, and the visual builder visualizes and debugs it. we never lock it inside our cloud.

PR #143 · workflows/credit-risk.json+12 / −4
  {    "nodes": [      { "id": "trigger", "type": "schedule" },-     { "id": "score_check", "type": "if_else",-       "data": { "operator": "<", "right": 600 } },+     { "id": "score_check", "type": "if_else",+       "data": { "operator": "<", "right": 700 } },+     { "id": "await_approval", "type": "await_signal",+       "data": { "signal": "approve", "timeoutSeconds": 86400 } },      ...    ],    "edges": [+     { "source": "score_check", "target": "await_approval",+       "sourceHandle": "false" },      ...    ]  }
~/repo/acmezsh
$ flowget-worker
✓ discovered 12 nodes in ./registry (REGISTRY_DIR)
✓ connected · namespace acme.flowget.cloud

# deploy + run from your own code — via the SDK
$ node scripts/deploy.ts
→ schedules.reconcile("credit-risk") ✓ reconciled
→ submit("wf_credit_risk", { … }) ✓ run started
→ subscribe(runId) · LLM call · HITL pending
⏸ awaiting approval signal — resume with signal()
✓ run completed
JSON contract
stable, documented schema. validate it, generate it from a script, store it wherever your stack puts artifacts.
git-native
engineer-owned workflows live in your repo. PR review, code-owners, branch protection — all the discipline you already have.
db-native
customer-authored workflows live in your database, same row-level security as the rest of your tenant data. no vendor lock.
SDK + worker
boot @flowget/worker to run your nodes; submit, subscribe, and reconcile schedules from your control plane via the SDK. CI/CD-ready. a push/test CLI is on the roadmap.

$ cat ./architecture.md

your data never leaves your infra.

your nodes run in a worker process inside your VPC, connected outbound to the Flowget orchestrator. payloads are encrypted at the worker edge — our cluster orchestrates without ever decrypting your data.

control plane · we run it
flowget saas

multi-tenant orchestration. audit history, billing primitives. visual builder + AI authoring (alpha).

  • durable orchestrator (per-tenant namespace)
  • workflow interpreter
  • catalog db · workflow versions · executions
  • builder UI · AI authoring agent (alpha)
sees: ciphertext payloads, workflow metadata, decisions taken. never sees: your raw domain data.
execution plane · you run it
your worker, your VPC

a single @flowget/worker process. registers your nodes, polls outbound, executes alongside your app.

  • @flowget/worker process
  • direct access to your DB · ORM · secrets
  • payload codec (encrypt before send)
  • scales with your existing infra
sees: everything. domain data, secrets, business logic — all stays on this side of the line.

data residency

your data stays under your control. our cluster only ever handles ciphertext and metadata — never your plaintext; your VPC stays the boundary for everything else.

regulator-friendly

GDPR, HIPAA, regional regulators — they all care where data lives. with BYO worker, you can answer: in your VPC.

audit-ready

every workflow execution is replayable from history. you decide what goes in clear metadata vs. ciphertext payloads — the codec encrypts the payloads before they ever leave your infra.

$ trace ./one-execution

one workflow, end to end — under the hood.

watch a scheduled weekly report run, step by step. with the payload codec on, every byte crossing our cluster is encrypted at your worker edge with a tenant-scoped key. we orchestrate; you hold the plaintext.

the workflow
  1. Schedule trigger
    schedule
  2. Fetch customer orders
    fetch
  3. Aggregate metrics
    aggregate
  4. Build PDF
    pdf
  5. Send email
    email
on the wiregRPC · TLS 1.3 · payload codec
cost
$0.0000
elapsed
0.00s
encrypted pkts
0
Cloud
orchestrator
ciphertext only
Worker
your VPC
holds the key
idle. click [ run end-to-end ] to start.

the codec is opt-in per tenant — leave it off for non-sensitive workloads, flip it on for compliance-bound ones. same SDK on both sides.

$ ls ./features

code what matters to you. we handle the rest.

Skip the orchestrator, the queue, the state machine, the retry math — we've already shipped them. Cost and audit hooks are wired in (you bring the writer); the visual builder and AI authoring are in alpha.

01

domain-native nodes

TypeScript functions in your codebase. Same auth context, same DB pool, same secrets. Zero HTTP marshalling — nodes run in your process, not ours.

02

durable execution, native

Workflows survive deploys, crashes, and 7-day human approvals. We operate the orchestrator; you write business logic.

03

decorators for free

Cross-cutting behavior as stickers: retry ships in the box; you author cache, rate-limit, or audit the same way. Attach to any node that opts in — author once, reuse across the catalog.

04

human-in-the-loop

Pause a workflow for hours or days waiting on approval. Resume on click — every approval carries the actor and timestamp, ready for your audit log.

05

workflow-as-json

The graph is JSON you own. Diff in PR, validate in CI, roll back like code. Visual builder is debug, not source of truth.

06

replayable executions

Every run produces a deterministic history. Time-travel replay is on the way — re-render the graph at any past moment, click a node, inspect its inputs.

$ sign-me-up --early

ship your customers' workflows. not their integration platform.

we open ~ten spots a month in the beta cohort. tell us what we're building together and we'll start the conversation.

[ request-access ] $ see-use-cases
✓ single-tenant cloudsoon on-prem on enterprise