# Cabloy: a Node.js fullstack framework built around Vona, Zova and AI spec-driven work

> Cabloy is a MIT licensed Node.js fullstack framework whose backend (Vona) and frontend (Zova) exchange OpenAPI contracts and generated types in both directions, and whose main pitch is guiding AI coding agents from confirmed specs to verifiable delivery. It ships as two editions with different UI layers and demonstration suites.

**cabloy/cabloy** — Cabloy is a Node.js fullstack framework for AI vibe coding, with AI Spec-Driven Development guiding work from confirmed specs to verifiable delivery.

- Repository: https://github.com/cabloy/cabloy
- Website: https://cabloy.com
- Stars: 985 · Forks: 132
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/cabloy-cabloy

## A fullstack framework whose point is the loop, not the parts

Cabloy is described as a Node.js fullstack framework for AI vibe coding, with AI Spec-Driven Development guiding work from confirmed specs to verifiable delivery. That phrase sets the agenda. The project is not primarily a set of components, it is a workflow: an AI coding agent is supposed to be pointed at a spec, work through it, and leave behind something that can be checked.

The scaffolding for that is visible in the repository layout. Alongside the application code there are AGENTS.md, CLAUDE.md, a .claude/ directory, a .codex/ directory, a .cursor/ directory, a .agents/ directory, a repo-agent-governance/ directory and a repo-specs/ directory. Those are instruction and specification files aimed at coding agents, kept in version control next to the code they describe, and the demo suites are described as high-quality, project-native code examples that improve development efficiency while reducing token use.

That last claim is the interesting one. The demonstration suites are not decoration, they are reference code for an agent to imitate. A master-detail form suite, an e-commerce suite and a system management suite give an agent working inside the repository concrete patterns to copy rather than invented ones.

The audience is Node.js teams that intend to let an AI agent write much of the application code and want the agent's output to be reviewable. The topics attached to the repository are simply full-stack and nodejs, and the project publishes to npm as the cabloy package, with the documentation site at cabloy.com and a demo at cabloy.com/demo.

The honest caveat is that the README describes the model rather than showing it. The AI Spec-Driven Development section is a link to a documentation page, and the demonstration section is a single video with a duration of 3:50. If the spec-driven claim is the reason you are considering the framework, the documentation site is where the actual answer lives.

## Vona and Zova, connected in both directions

The architecture is two halves named Vona and Zova, and the README is explicit that Cabloy connects them in two ways.

The first is integrated SSR. Zova builds the frontend and SSR artifacts, and in Vona integrated SSR, Vona consumes those artifacts to render the page, with Zova hydrating it in the browser. The important detail is who does what: the frontend build produces the artifacts, the backend renders the page from them, and the client-side code takes over afterwards. That is server-side rendering with the render step owned by the backend, and it means a page can be produced on the server without the backend needing to know anything about Vue.

The second is bidirectional contract flow. Vona's OpenAPI contracts generate Zova SDKs and schema-aware helpers, so the frontend calls the backend through generated code rather than hand-written fetch calls. Then the flow reverses: Zova's generated metadata and types for routes, components and icons feed back into Vona's tooling and type hints. The backend's view of the frontend's surface is derived from the frontend's own source rather than maintained by hand.

Both halves are visible as top-level directories in the tree, vona/ and zova/, each with its own packages-cli and its own CLI binary. The package.json scripts call those binaries directly, for example the vona script running node ./vona/packages-cli/cli/src/bin/vona.ts with a project path argument, and the zova script doing the same for ./zova/packages-cli/cli/src/bin/zova.ts. The development commands are similarly split, with dev pointing at the vona directory and separate scripts for the admin and web SSR targets.

The practical value of a two-way loop is that neither side's types drift. The cost is that the project is a framework with opinions rather than a set of libraries, and the shape of your application follows the shape of the tool.

## Starting a project with one command, or cloning a starter

There are two documented ways in, one per edition.

For the Basic edition, the project generator is invoked through npm create:

```bash
npm create cabloy@latest
```

That is the whole of the Basic setup step in the README, and it is worth noticing what is not there. There is no list of peer dependencies to install by hand, no database to provision before the first run, and no configuration file to edit. The framework is published to npm as cabloy, and the generated project is a working baseline rather than an empty shell.

For Cabloy Start, the README points at a separate repository and a single command run from its root:

```bash
npm run init
```

The Start repository is at github.com/cabloy/cabloy-start, and the script it runs is node scripts/init.ts, which is also the init script in this repository's own package.json. The README points to the Fullstack Quickstart page for prerequisites and development commands, which is where the details live rather than in the README itself.

Once a project exists, the scripts in package.json show the shape of the workflow. There is an upgrade script and, more usefully, a dry-run variant of it, upgrade:dry-run, which passes a --dry-run flag to the same script. On a framework that publishes as often as this one, that is the script worth knowing before anything else.

The build story is layered in the same way, with separate targets for the backend and for each frontend application, a docker variant for the backend build, and a combined build that runs the Zova build before the Vona one. The repository also has a lint-staged configuration, an oxlint configuration, an oxfmt configuration, husky in .husky/ and a lerna.json, so the tooling conventions are set up rather than left to the adopter.

## Two editions that differ in UI layer and in what ships

Cabloy is available through two complete project baselines, each maintained in its own repository, and both are MIT licensed. This is the clearest decision you have to make before starting, and the README tabulates the differences precisely.

The UI layer is the headline difference. Cabloy Basic uses DaisyUI with Tailwind CSS. Cabloy Start uses Vuetify. Everything else in the core capability table is the same for both: master-detail forms including multiple levels of nested detail records, image uploads and file uploads with local and Cloudflare storage backends, payment integrations demonstrating simulated payments along with PayPal and Stripe, and a Markdown editor with image uploads and syntax highlighting.

The demonstration suites differ. Both editions include the Student Training Management suite, which demonstrates master-detail forms, nested detail records, image and file uploads, and in Start additionally data-scope-based RBAC. The E-commerce suite, a complete Admin site, Web site, personal center, payment flows and Markdown editing, is in Basic only. The System Management suite, covering user, role and department management plus RBAC and menu authorization, is in Start only.

The README is careful about what the table means. A note in the legend says that not included means the suite is not part of the default edition baseline, and that it does not limit what can be built with Cabloy. So choosing Basic does not mean you cannot build user management later; it means the reference code for it is not in the baseline you cloned.

If a suite is unwanted, the project provides the switch. The README says that for production deployments you set PROJECT_DISABLED_SUITES to a comma-separated list of unneeded suite names to disable them, with a link to the Environment and Config Guide for the built-in environment variables. That is a small but telling design choice: the baseline ships everything, and trimming it is an explicit, documented configuration step rather than something you do by deleting files.

Pick the edition by looking at your team's existing UI conventions, since the UI layer is the thing you will touch on every screen.

## A pinned stack, and a release train that moves daily

The technology stack is pinned in the README, which is useful precisely because it tells you what you are signing up for rather than what you could choose.

On the general side, TypeScript ^5.9.3 and Zod ^4.3.6. On the backend, Koa ^3.2.0, Knex ^3.2.9, ioredis ^5.10.1 for the Redis client and better-sqlite3 ^12.9.0 as the SQLite driver. On the frontend, Vue ^3.5.32, Vite ^8.0.14, Quasar ^2.19.3 and TanStack Query ^5.100.10.

Several of those choices are worth a sentence each. Koa rather than Express is a minimal middleware core. Knex is a query builder, and the pairing of Knex with better-sqlite3 as the driver gives you a synchronous SQLite path for development and a Redis client for caching or queues. TanStack Query on the frontend is the server-state layer, which pairs with the SDK generation story: the generated Zova SDKs produce typed calls, and TanStack Query handles caching and invalidation around them.

The release cadence is the fact that should shape your planning. The three most recent tags are cabloy@5.1.220, cabloy@5.1.219 and cabloy@5.1.218, all published on 2026-10-19, The npm version in package.json matches at 5.1.220. This is a project shipping several releases a day.

That has two consequences. Upgrading is not a monthly chore, it is a decision you take whenever you choose to, which is why the dry-run upgrade script matters. And a patch number means very little as a compatibility signal, so the changelog and the upgrade script are where the real information lives. The repository is not archived, the last push was on 2026-10-22, and the default branch is main.

The licence is MIT for both editions, with a LICENSE file at the root and a LICENSES.md file alongside it. MIT means no copyleft obligation on your application code, which matters for a framework whose whole premise is that you build a product on top of it.

## What the framework does not do for you, and the alternative shape

The honest limitation is that Cabloy is a large, opinionated surface. A repository with vona/, zova/, packages-cabloy/, repo-specs/, repo-e2e/, repo-observability/, repo-docs/ and repo-docs-internal/ at the top level is not a codebase you absorb in an afternoon. The scripts show how many targets exist, with separate dev, build and SSR commands for admin, web and commerce applications on the frontend and a separate backend build with a docker variant. Every one of those is a knob you will meet.

The second limitation is about the spec-driven model itself. The README gives the model a name and a link, and the repository provides the instruction files that an agent would read, but it does not document the process in a way that a reviewer can evaluate. If your concern is that AI-generated code arrives unverified, the repository layout is evidence that verification artefacts exist, since repo-specs/ and the e2e directory are there, but the README does not say how a spec is confirmed or how delivery is checked. That question has to be answered by the documentation site before you commit a team to it.

The alternative is not another framework, it is a different shape of project. The conventional arrangement keeps a backend service and a frontend application in separate repositories, generates a client from the backend's OpenAPI document in one direction only, and shares types through a published package or a checked-in contract. The difference against Cabloy is not in the individual technologies, since Koa, Knex, Vue and Vite are all ordinary choices, it is in the direction of the flow. One-way generation gives you a stable contract with a clear owner, and the frontend can be rewritten or replaced without touching the backend. The two-way loop in Cabloy gives you a frontend whose routes, components and icons are known to the backend tooling, and it makes the frontend and backend move together, which is exactly what you want for an agent writing across both and exactly what you do not want if you need the two to be independently deployable or independently replaceable.

That is the trade to make consciously. A framework that synchronises both sides removes a category of mismatch, and in exchange it makes the pair a single unit you version together. For a team shipping one product with an agent working across the whole stack, that is a reasonable exchange. For a team maintaining a public API for third-party clients, the closed loop is a liability rather than a feature.

## Conclusion

Cabloy fits a team that wants one repository holding backend, frontend, generated SDKs and AI guidance files together, and that is willing to work inside the Vona and Zova conventions rather than assembling a backend, a Vue app and a contract pipeline by hand. It does not fit a team with an existing Koa or NestJS service, a Vue application with its own build pipeline, or a preference for a slow and stable release train, since the project published three versions on 2026-10-19 alone. Before you adopt it, read AGENTS.md and CLAUDE.md in the repository root, run the upgrade script with the dry-run flag to see what it would change, and confirm the edition you pick, Basic with DaisyUI and Tailwind or Start with Vuetify, matches the UI your team already maintains.

## FAQ

### How do I create a new Cabloy project?

For the Basic edition, run `npm create cabloy@latest`. For Cabloy Start, clone the Cabloy Start repository and run `npm run init` from its root. The README points to the Fullstack Quickstart page for prerequisites and development commands.

### What is the difference between Cabloy Basic and Cabloy Start?

Cabloy Basic uses a DaisyUI and Tailwind CSS UI layer and includes the E-commerce demonstration suite, while Cabloy Start uses a Vuetify UI layer and includes the System Management suite. Both include the Student Training Management suite and the same core capabilities, and both are MIT licensed.

### How do I remove a demonstration suite I do not need?

Set the PROJECT_DISABLED_SUITES environment variable to a comma-separated list of unneeded suite names. The README links to the Environment and Config Guide for the built-in environment variables.

### What is Vona and Zova in Cabloy?

Vona is the backend and Zova is the frontend. The README describes two links between them: integrated SSR, where Vona consumes the artifacts Zova builds and Zova hydrates the result in the browser, and a bidirectional contract flow, where Vona's OpenAPI contracts generate Zova SDKs and Zova's generated metadata feeds back into Vona's tooling.

### How do I check what an upgrade would change before applying it?

The package.json scripts include upgrade:dry-run, which runs the upgrade script with a --dry-run flag, while the regular upgrade script runs node scripts/upgrade.ts.

## Sources

- [cabloy/cabloy on GitHub](https://github.com/cabloy/cabloy)
- [License: MIT](https://github.com/cabloy/cabloy/blob/main/LICENSE)
- [Project website](https://cabloy.com)
- [README](https://github.com/cabloy/cabloy/blob/main/README.md)
- [Releases](https://github.com/cabloy/cabloy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cabloy-cabloy