FAQ

Here are the questions developers ask before adopting B4.run. Each answer links to the full page when there is one.

Adopting B4.run#Copy link to section: Adopting B4.run

Do I have to use LangGraph?#Copy link to section: Do I have to use LangGraph?

Yes. B4.run is a meta-framework for LangGraph the way Next.js is a meta-framework for React. LangGraph runs the graph. B4.run adds the conventions around it: file-system routing, type inference, the dev server and the build step. If you don't want LangGraph, B4.run is the wrong tool. See Mental Model.

Can I bring my own model provider?#Copy link to section: Can I bring my own model provider?

Yes. An agent() route runs on a LangChain chat model. B4.run infers the provider for known model families and lazy-loads the matching LangChain integration package. For an alias, an ambiguous name, a local model or a provider-router model id, set provider to one of the built-in provider ids. Raw graph and chain routes can create any provider's model directly. See Model providers.

How does B4.run compare to Mastra / CopilotKit / Vercel AI SDK?#Copy link to section: How does B4.run compare to Mastra / CopilotKit / Vercel AI SDK?

They solve different problems.

• Vercel AI SDK is a client-and-server toolkit for chat UIs and provider-agnostic LLM calls. B4.run sits one layer up and organizes whole agent projects. You can use the AI SDK inside a B4.run route.
• CopilotKit is a frontend-first framework for embedding copilots in existing apps. B4.run is backend-first: it produces a deployable agent runtime. The two work together through B4.run's AG-UI endpoint. Both b4 dev and b4 start serve POST /agui/{routeId} with the same route middleware, and the chat example wires a CopilotKit runtime to it through B4HttpAgent.
• Mastra is a general-purpose agent framework with its own runtime and abstractions. B4.run is narrower. It keeps LangGraph and removes the boilerplate around it.

If you're already on LangGraph, B4.run fits. If you're not, pick the framework whose runtime you want to live in.

Does B4.run support Python?#Copy link to section: Does B4.run support Python?

No. B4.run is TypeScript-only because it relies on type inference: it reads tool parameter types from function signatures at build time and writes them to .b4/b4.generated.d.ts. In Python, use langgraph directly. LangSmith deploys both.

Is B4.run production-ready?#Copy link to section: Is B4.run production-ready?

B4.run is pre-1.0, and the API is still changing. By default, b4 build emits a runnable node target (server.mjs plus a hardened Dockerfile) and a langsmith target (langgraph.json). The edge targets are opt-in: hono for Cloudflare Workers and other edge runtimes, and vercel for Vercel. node .b4/build/server.mjs runs the node target's build output on 0.0.0.0, and b4 start serves the app's source tree the same way. Pin a version and read the release notes before each upgrade. See Deployment.

Working in B4.run#Copy link to section: Working in B4.run

Can I drop down to raw LangGraph when I need to?#Copy link to section: Can I drop down to raw LangGraph when I need to?

Yes. A route's index.ts can default-export an agent() descriptor or named-export a workflow, graph, or chain. The graph shape gives you a raw StateGraph with no B4.run abstractions in the way. You can mix shapes across routes in one project. See Routes.

What does b4 build actually do?#Copy link to section: What does b4 build actually do?

It walks your routes, runs typegen, then writes deployment artifacts for each target in build.targets (node and langsmith by default).

• The node target emits .b4/build/server.mjs, which boots the real B4.run runtime (Agent Protocol, AG-UI, and the sandbox if configured), plus a hardened Dockerfile. Run it with node .b4/build/server.mjs or docker build/docker run. b4 start serves the source tree instead of the build output.
• The langsmith target emits .b4/build/langgraph.json plus a per-route entry file under .b4/build/<routeSlug>.ts. Each agent route's entry imports your default agent() descriptor, turns it into a LangGraph graph, and wires in the route's tools. Each assistant_id is <routeId>#<kind>, for example /navlog#agent.
• The opt-in hono target emits .b4/build/app.mjs plus a wrangler.toml for edge runtimes, and the opt-in vercel target emits a Vercel Build Output tree.

See CLI Reference and Deployment.

Why a meta-framework instead of a library?#Copy link to section: Why a meta-framework instead of a library?

A library is something you call. A meta-framework is something you write inside. B4.run's conventions (folder-as-route, co-located tools, typed state per route) only pay off when the whole project follows them, the same way Next.js routing works because every page lives under app/. A library would leave you writing the boilerplate B4.run removes. See Mental Model.

Operating B4.run#Copy link to section: Operating B4.run

Can I deploy outside LangSmith?#Copy link to section: Can I deploy outside LangSmith?

Yes. b4 build's node target emits a server.mjs that boots the real B4.run runtime, plus a hardened Dockerfile. Build the image and run it wherever you run containers, or run node .b4/build/server.mjs directly. b4 start serves the same runtime from the source tree rather than the build output. This is the only deployment path that runs the execution sandbox. You can also feed the langsmith target's .b4/build/ output (langgraph.json) to any container that runs the LangGraph runtime. That path skips both the B4.run runtime and the sandbox. See Deployment.

Can B4.run run on Cloudflare Workers?#Copy link to section: Can B4.run run on Cloudflare Workers?

Yes, for apps that fit the edge subset. Add "hono" to build.targets and b4 build emits an app.mjs plus a wrangler.toml you deploy with wrangler deploy. Durable state goes to Postgres over a @neondatabase/serverless WebSocket pool, set through a DATABASE_URL binding. You don't need the nodejs_compat flag.

The sandbox, workspace file and shell tools, tool-output offloading, and long-term memory aren't available there. If your app uses them, the build fails and names them. The runtime repeats that check per request for anything that skipped the build. Route skills, plan.md, and memory.md are bundled into the manifest at build time and served from it at request time.

Read Edge and Hono before you commit to this path. That "yes" rests on a gated CI lane serving real AG-UI turns under local workerd (the same binary Cloudflare runs). Nobody has deployed to Cloudflare itself yet. What is proven, and what is not lists the gaps that leaves, bundle size and production connection limits among them.

Can B4.run use Postgres for long-term memory?#Copy link to section: Can B4.run use Postgres for long-term memory?

Yes. SQLite is the default local store, but @b4run/memory-pgvector provides a Postgres + pgvector backend for production and multi-instance deployments. Add pgvectorMemoryStore({ connectionString, dimensions }) to memory.store, and add openaiEmbedder() when you want hybrid keyword + vector recall. See Recall and Retrieval.

How do I gradually migrate an existing LangGraph project?#Copy link to section: How do I gradually migrate an existing LangGraph project?

Move one graph at a time. Create a B4.run route, named-export your existing StateGraph from its index.ts as graph, and point the new assistant_id at it. Tools, prompts, and model providers come along unchanged, because B4.run wraps your code without rewriting it. Once the route is live, you can move state and tools into B4.run's conventions, or leave the graph as it is.

Related#Copy link to section: Related