vercel-labs/workflow-builder-template: a visual AI workflow builder you host yourself

The problem this template is aimed at

Building a workflow automation product means writing the same three layers every time: a canvas that lets someone arrange nodes, an execution layer that runs them, and a set of connectors to services people already use. The repository is a working example of all three, published as a template rather than a library. The README describes it as "a template for building your own AI-driven workflow automation platform," which sets the expectation correctly. You are meant to fork or deploy it and then change it.

The audience is a developer or small team with a product idea that involves triggers and actions. The included nodes cover Resend for email, Linear for tickets, Slack, PostgreSQL, GitHub, Stripe, Firecrawl, fal.ai, Perplexity, Clerk, Webflow and a generic external API call. That list is a reasonable sketch of what a first version needs, and it is also the clearest signal of scope: this is infrastructure for people who will write code, not a no-code product for an operations team.

How the pieces fit together

The stack is Next.js 16 with React 19 on the front, React Flow for the canvas, Jotai for state, Drizzle ORM over PostgreSQL, and Better Auth for sessions. Workflow DevKit handles execution. The database schema in the README lists five tables: user, session, workflows, workflow_executions and workflow_execution_logs. That split matters, because it means a workflow definition and its runs are separate records, and node-level detail lands in its own log table rather than being crammed into an execution row.

Execution is exposed over HTTP. POST /api/workflows/{id}/execute starts a run, GET /api/workflows/{id}/executions returns history, and GET /api/workflows/executions/{executionId}/logs returns the per-node logs. Code generation hangs off the same shape: GET /api/workflows/{id}/generate-code returns TypeScript, and the README says the output includes type-safe code, real integration calls, error handling and execution logging. The generated functions carry a "use workflow" directive, which is the marker Workflow DevKit uses to treat a function as a workflow rather than ordinary code.

There is one structural detail worth noticing. Action nodes in the README sit between two HTML comments marked PLUGINS:START and PLUGINS:END, annotated "Auto-generated by discover-plugins." The dev and build scripts both run that discovery step before the framework starts, and there is a separate create-plugin script. So the node catalogue is generated from the plugins directory rather than hand-maintained, and adding a connector means adding a plugin, not editing the README.

Running it locally and generating your first workflow

Prerequisites are Node.js 18 or newer, a PostgreSQL database and pnpm. The README asks for a .env.local file with database, auth and AI credentials. The AI Gateway key is what backs the natural-language workflow generation, so the app runs without it but that feature will not.

DATABASE_URL=postgresql://user:password@localhost:5432/workflow_builder
BETTER_AUTH_SECRET=your-secret-key
BETTER_AUTH_URL=http://localhost:3000
AI_GATEWAY_API_KEY=your-openai-api-key

Install dependencies, push the schema and start the dev server. The dev script runs plugin discovery first, so the node list in the UI is rebuilt from the plugins directory on every start.

pnpm install
pnpm db:push
pnpm dev

The README says to visit http://localhost:3000 to get started. Once there, the practical first test is to create a workflow with a Manual trigger and a single action node, then execute it. That exercises the whole path: definition stored in the workflows table, a row in workflow_executions, and node detail in workflow_execution_logs. If the run completes, the database wiring and the execution engine are both fine.

The second test is code generation. Calling the endpoint for a workflow you built by hand returns the equivalent TypeScript.

GET /api/workflows/{id}/generate-code

Read the output carefully. The README's example shows a function that calls generateEmail and sendEmail and returns status, subject and body, with the "use workflow" directive at the top. Whether the generated code matches your node graph exactly is the thing to check before you build anything on top of it.

Where the template stops short

The README does not document rollback, retries or idempotency for a partially completed run. Execution logs exist, and the generated code is described as including error handling, but there is no described mechanism for undoing the steps that already succeeded when a later node fails. For a workflow that sends an email and then creates a ticket, that gap is the difference between a demo and something you would put in front of customers.

Authentication is present through Better Auth, but the README does not describe roles, permissions or per-workflow access rules. The schema lists user and session tables only. If you need one team to see only its own workflows, that is work you add.

The deployment path is the other constraint. The one-click Vercel deploy creates a Neon Postgres database and prompts for Better Auth credentials and an AI Gateway key, which is convenient, but it also means the template's default shape assumes Vercel and Neon. Running it on your own infrastructure is possible since it is a Next.js app with a Postgres connection string, but the README documents the Vercel route and nothing else.

Finally, there are no releases. The repository has no published versions, so there is no upgrade path to follow beyond tracking the main branch. The last push was on 2026-08-05, which is recent, but a template with no tags means every pull is a potentially breaking change you have to review yourself.

How it compares with n8n and similar tools

n8n is the obvious comparison, and the difference is in what you receive. n8n is a finished application you install and use, with its own node library, credentials store and execution model, licensed under a fair-code scheme rather than a permissive one. This template is source code you own and modify. You get the canvas and the execution layer, but you also get the responsibility for every node, every migration and every deployment.

That distinction decides the choice. If the goal is to automate internal processes this week, a finished tool wins, because the work of building and hosting the automation platform is not the work you set out to do. If the goal is to ship a product where the workflow builder is part of the value you sell, the template wins, because you can change the node set, the UI and the execution semantics without negotiating with an upstream project.

A smaller but real difference is the code generation. The template can turn a visual graph into TypeScript with the "use workflow" directive, which means a workflow can graduate from the canvas into a normal function in your codebase. Most visual automation tools keep the definition inside their own runtime and offer an export at best. Whether that matters depends on whether you expect your users to want the code.

Licence and the cost of keeping up

The repository reports its licence as NOASSERTION, while package.json declares "license": "Apache-2.0". Those two statements disagree, and the disagreement is the first thing to resolve before adopting the code. Apache-2.0 is permissive and includes a patent grant, which is what most teams would expect from a Vercel Labs template, but the repository metadata does not confirm it. This is not legal advice; it is a note that the two sources conflict and a licence file exists in the repository root to check.

The upgrade cost is tied to the stack rather than to the template's own versioning. There are no releases, so there is nothing to pin. Next.js 16, React 19, Drizzle and Better Auth all move independently, and the build script runs a production migration step before the Next.js build, which means a schema change and a code change ship together. Budget for reading diffs on main rather than for bumping a version number.

On the plus side, the plugin discovery script means integration work is additive. A new connector goes in the plugins directory and appears in the node list at the next dev or build, which keeps the cost of extending the template lower than the cost of tracking it.

Editorial conclusion

Adopt it if you are building your own automation product and want a working canvas, integration layer and code generator to start from rather than a blank repository. Skip it if you need a hosted tool you can hand to non-engineers today, since you still supply Postgres, Better Auth secrets, an AI Gateway key and the deployment. Before committing, verify the licence question first: package.json declares Apache-2.0 while the repository metadata reports NOASSERTION, and that mismatch should be resolved by whoever owns the codebase.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. vercel-labs/workflow-builder-template on GitHub