B4.run: file-system routes and generated types around LangGraph.js
Build LangGraph agents like Next.js apps.
At a glance
- What is it?
- B4.run is a TypeScript framework that wraps LangGraph.js with Next.js-style file-system routing, typegen, fixture-backed tests and a default Node build. It is aimed at TypeScript teams that want agent conventions, not at Python projects or teams that prefer raw graphs.
- Who is it for?
- Adopt B4.run if your team writes TypeScript agents on LangGraph.js and wants routes, generated types and a deterministic test loop without hand-wiring each graph. Do not adopt it if your stack is Python or if you want to keep full control of graph construction, because B4.run requires LangGraph.js and layers conventions on top of it.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem B4.run targets: agent code that outgrows its routing
A LangGraph.js project starts small. A graph, a few nodes, a tool or two. Then the application around it grows: HTTP entry points, per-route tool sets, state schemas, environment configuration, a test suite that either hits a live provider or mocks it badly. None of that is graph logic, and LangGraph.js does not prescribe it. B4.run's README frames its job as supplying "file-system routing, generated types, local test and development conventions, persistence primitives, and build targets around LangGraph.js." The audience is narrow and stated: TypeScript teams already committed to LangGraph.js. The README is explicit that Python projects should stay with raw LangGraph.js, and that B4.run "requires LangGraph.js and targets TypeScript and Node.js." If your agents run in a Python service, this is not a partial fit. It is the wrong tool, and the project says so itself.
How a route becomes an agent: discovery, typegen and the tool boundary
The mechanism is convention over discovery. You author one supported entry, an `agent`, `workflow`, `graph` or `chain`, in a route's `src/app/**/index.ts`. B4.run discovers the route from the file position and treats that entry as the runtime entry. Shared tools live in `src/tools/`; route-local tools can sit beside the route and stay subject to that route's runtime policy. During typegen and build, B4.run emits TypeScript declarations for routes, route parameters, state and tools. One constraint in the README is easy to miss: state types are emitted only "when the discovered state schema supplies valid defaults." A schema without discoverable defaults does not produce a state export, so the generated surface depends on how you write the schema, not just on the route existing.
The layering is worth restating because it sets expectations. LangGraph.js remains the graph runtime and is required. LangChain integrations remain available: the built-in `agent()` path uses them, while raw `graph` and `chain` routes own their imports and provider behavior. The README does not claim coverage for every LangChain package or provider, so a route that reaches an unusual integration is your responsibility, not a framework guarantee. Deployment and observability stay external too. B4.run emits a Node runtime and LangSmith artifacts by default, but it does not provision infrastructure, host the app or manage secrets.
Installing B4.run and running the first activation
The README gives a single scaffold command and states that Node.js 24 or later is required. The generated project is the first activation path, and the README calls it the no-key path, meaning no provider credentials are needed to get through it.
npm create b4-app@latest my-agent
cd my-agent
npm install
npm testAfter `npm install`, `npm test` runs the starter's default fixture suite. The README records a credential-sanitized clean-room run on August 31, 2026 in which npm resolved `create-b4-app` 0.8.21, the generated starter installed, and its default fixture suite passed with one opt-in test file skipped. That observation is tied to that version and date. The README warns that `@latest` can move, so treat the receipt as evidence about 0.8.21 rather than a standing promise about whatever resolves today.
The deterministic part is the test mode. Fixture-backed tests replay committed responses and fail on an unmatched interaction instead of silently calling a provider. Live and recording modes exist as explicit opt-ins, which means the default loop cannot quietly spend tokens or depend on network state. For a first real use, the README points at the runnable developer agent in `examples/code-fixer/server/`, with a walkthrough alongside it. That example reproduces a historical defect, repairs source in an isolated workspace, verifies the patch independently, and pauses for approval before local export. The homepage shows one recorded repair, and the evaluation report retains the failed attempts as well. For development, `b4 dev` runs the app; the README states that default SQLite-backed state can survive a `b4 dev` restart when the app root and its SQLite files persist.
Where B4.run stops: migration, target variance and the state defaults trap
The clearest limitation is the boundary the README draws around capability support. It tells you to validate the subset your application uses, because support varies by target. That is a fair warning and also a real cost: the framework emits a runnable Node server, a Dockerfile and LangSmith graph artifacts from the default build, but the README says to validate the runtime, storage, auth and provider boundary for whichever deployment target you pick. B4.run does not provision infrastructure, host the app or manage secrets, so the operational work does not disappear. It moves.
Migration is incremental rather than automatic. If you already have a graph, the README's path is to keep its nodes, edges and imports, expose it as a raw `graph` route, and validate invocation and checkpointer behavior for each target. That is a manual port with a documented shape, and the checkpointer is named specifically as something to verify. The state-schema default rule is the second sharp edge. A schema that lacks discoverable defaults yields no emitted state type, which will surface as missing declarations rather than a clear error about the schema itself. Teams that generate schemas dynamically, or that treat defaults as optional, should expect friction at typegen time. Finally, the README's own framing is honest about scope: raw `graph` and `chain` routes own their imports and provider behavior, so moving to B4.run does not standardize provider handling for you.
B4.run against raw LangGraph.js and Next.js-style agent servers
The obvious alternative is raw LangGraph.js, and the README recommends it for anyone who does not want B4.run's application conventions. The difference is not the graph engine, which is the same in both cases. It is everything around it. Raw LangGraph.js leaves route wiring, type generation, test replay and build output to you, which is more work and more freedom. B4.run fixes those conventions: one supported entry per route file, tools in `src/tools/` or beside the route, generated declarations during typegen and build, fixtures that fail on unmatched interactions, and a default build that emits a Node server, Dockerfile and LangSmith artifacts. If your team already has a routing layer and a test harness it trusts, B4.run replaces working infrastructure with its own opinions. If your team is hand-wiring routes for every new agent and hand-mocking providers in tests, the conventions are the point. The README also positions B4.run against the Next.js mental model directly: author the application shape, not route wiring. Teams that disliked Next.js's file-system routing for the same reasons (implicit discovery, generated files you do not edit) will dislike this for the same reasons.
Maintenance, releases and what the MIT licence leaves to you
The repository is not archived, and the last push was on 2026-09-15, the same day this is written. Recent releases are close together: v0.8.31 on 2026-09-12, v0.8.30 on 2026-09-10, v0.8.28 on 2026-09-09. That cadence is visible in the release list, and the versioning is still pre-1.0, which is the practical upgrade consideration. A pre-1.0 package can change generated type shapes or build output between minor releases, and the README's own note that `@latest` can move is the same warning from the other direction. If you pin, pin deliberately. The root `package.json` also carries pnpm overrides for `langsmith`, `ws`, `esbuild`, `js-yaml`, `qs` and `vite`, which tells you the workspace manages transitive versions centrally; if you consume the published packages rather than the monorepo, your resolution may differ from the one the maintainers test against. The licence is MIT, which permits commercial use and modification, and the repository includes `SECURITY.md` and `SUPPORT.md` at the top level. MIT grants no warranty, and nothing here is legal advice; if your organization treats generated build artifacts as distributed software, have counsel review the notice requirements rather than assuming the licence text covers your packaging.
Editorial conclusion
Adopt B4.run if your team writes TypeScript agents on LangGraph.js and wants routes, generated types and a deterministic test loop without hand-wiring each graph. Do not adopt it if your stack is Python or if you want to keep full control of graph construction, because B4.run requires LangGraph.js and layers conventions on top of it. Before committing, verify two things in a scratch app: that your target's capability subset is covered, since the README says capability support varies by target, and that `npm create b4-app@latest` still resolves to a version whose starter passes `npm test`, because the README notes that `@latest` can move.
Frequently asked questions
Does B4.run replace LangGraph.js?
No. The README states that LangGraph.js remains the graph runtime and is required by B4.run, which adds application conventions around it rather than replacing it.
What Node.js version does B4.run need?
Node.js 24 or later. The README states this requirement in the quickstart, and the root package.json sets the engine to node >=24.0.0.
Can I use B4.run with an existing LangGraph.js graph?
Yes, incrementally. The README says to keep the graph's nodes, edges and imports, expose it as a raw graph route, and validate invocation and checkpointer behavior for each target.
Do B4.run tests call a model provider by default?
No. Fixture-backed tests replay committed responses and fail on an unmatched interaction instead of silently calling a provider; live and recording modes are explicit opt-ins.
Community notes