NocoBase 3.0 answers AI coding by becoming the foundation

NocoBase has been releasing 3.0 alphas since July 30th, reaching alpha.13 by August 31st, without an official announcement. The documentation reveals an AI Builder section with an AI Portal feature, and package analysis shows 3.0 adds two new packages compared to the 2.3 beta line: plugin-multi-portal and portal-template-default, indicating a focus on multi-portal management and AI integration.

NocoBase https://www.nocobase.com/ has been publishing 3.0 alphas since July 30th. As of today it is at 3.0.0-alpha.13 . There is still no release announcement — nothing on the blog, no "Announcing NocoBase 3.0" post. That silence is easy to misread. The blog has been busy: 2.2 shipped as a stable release on August 23rd and got its own announcement , and the beta line has already moved on to 2.3. Only 3.0 keeps stacking up releases without a word. Meanwhile the documentation is already there. docs.nocobase.com carries an AI Builder section spanning 18 pages , and its centerpiece — the AI Portal Quick Start https://docs.nocobase.com/ai-builder/ai-portal/ — states a prerequisite of NocoBase = 3.0.0-alpha.6 . There is even a link to request a demo environment. So 3.0 has not gone unexplained. It has gone unannounced. When someone asked about it on the forum "Not 2.3, but 3.0. Is some major update in preparation?" , a staff member replied with four words: "Stay tuned for our release." t/13661 https://forum.nocobase.com/t/nocobase-3-0-0/13661 This post walks through what the documentation says, then checks it against the packages and a running instance. Heads up:everything here describes an alpha. The documentation is published, but the release itself is not announced. Nothing guarantees the final 3.0 will look like this. How this was checked:the runtime observations come from 3.0.0-alpha.9 official Docker image + PostgreSQL 16, fresh install , with 2.1.23 alongside for comparison. Before publishing I re-verified the same facts against the— the portal seed data, the path assignment, and the template version are all unchanged. Package composition comes from npm; release notes from the GitHub Releases API. 3.0.0-alpha.13 packages npm's dist-tags show four lines in flight: latest : 2.2.5 ← stable lives here beta : 2.3.0-beta.6 alpha : 3.0.0-alpha.13 ← released 2026-08-31 v1 : 1.9.74 The 3.0 alphas started with alpha.1 on July 30th and reached alpha.13 in about a month. Worth noting if you script against releases: alpha.1 through alpha.3 exist only on npm. GitHub Releases starts at alpha.4 . Compare the dependencies of @nocobase/preset-nocobase — the package that bundles the built-in plugins — across the three lines: 2.2.5 stable 104 packages 2.3.0-beta.6 104 packages ← same composition as 2.2 3.0.0-alpha.13 106 packages ← 2.3-beta + 2 more Nothing was removed. Stable and beta carry an identical set, and 3.0 carries exactly two packages more. That difference is the whole answer: | Package | Display name | What npm says it does | |---|---|---| plugin-multi-portal | Portal manager | Manage multiple portals, each with its own layout and menu | portal-template-default | Default Template | A React and shadcn/ui template for building a standalone frontend backed by NocoBase | You might expect the release notes to point the same direction. Tallying components across alpha.4 – alpha.13 gives a flat top: Portal manager 9, AI employees 9, client-v2 9. Split by date, though, the shape returns: | Releases | Dates | Portal-related changes | |---|---|---| | alpha.4–8 | Jul 31 – Aug 10 | 9 | | alpha.9–13 | Aug 11 – Aug 31 | 0 | Every portal change landed in the first ten days. After that, the alphas absorb general work shared with the 2.3 line — AI employees, client-v2, Workflow, Multi-space. alpha.10 alone runs to about 11,000 characters of notes covering the whole product. So the release notes aren't a good instrument for "what is 3.0 adding". They carry the 2.3 development stream too. The package composition is the cleaner signal. The portal changes from those first ten days do sketch the intent: That last one is a different kind of feature from the rest. The AI Portal Quick Start https://docs.nocobase.com/ai-builder/ai-portal/ opens by stating the problem directly: We found that AI vibe coding can produce a good-looking page, but it has a hard time connecting to a real business system — or it ends up reimplementing authentication, permissions, and collection design from scratch. NocoBase, as a low-code/no-code platform, already provides all of that. You can treat it as the foundation of your system kernel, letting the AI Agent focus on business logic while NocoBase supplies reliable authentication, database, API, and permission infrastructure. For this we provide an application entry called AI Portal. Its source code lives locally and is reserved for the AI Agent to write. The division of labor: What I did not expect is that no-code isn't being replaced . The AI Builder landing page https://docs.nocobase.com/ai-builder/ presents two ways to build a UI, side by side: | no-code Portal | AI Portal | | |---|---|---| | Access path | /v/<name | /x/<name | | Where pages come from | Configured in the UI AI can edit the configuration | React source, written by an AI agent | | Output | Configuration in the database | Source you can commit to Git | | Iteration | Click through the UI, or have AI change the config | Change code, dev → deploy | | Freedom | Bounded by block capabilities | Whatever you want | | Suits | Standard CRUD, internal admin backends | Custom interactions, complex business systems | The docs say plainly that a no-code portal is enough when "the page structure is very standard" or when non-coders need to adjust pages themselves. AI Portal is an addition, not a migration. The quote says the source "lives locally". The Deployment and Source Management https://docs.nocobase.com/ai-builder/ai-portal/deploy/ page pins that down: Portal source lives in three places: the local dev workspace, source storage, and the deployed artifacts. | Location | What it is | |---|---| Dev workspace | ./<portal on the developer's machine --path to relocate . This is where the AI agent runs | | Source storage | nocobase by default NocoBase keeps it ; switch to git for a repository | | Deployed artifacts | The build output, served at /x/<portal / | So "locally" means a working directory on someone's laptop, not a directory on the server. You pull the source down, point a coding agent at it, push, and deploy: nb portal pull main fetch the source locally nb portal dev main dev server, localhost:5173 by default nb portal push main --message "Add customer management page" nb portal deploy main afterwards, visit /x/main/ The prerequisites are worth reading as operational requirements: Node.js = 22 , pnpm, the alpha build of @nocobase/cli , and "an AI Agent, such as Claude Code, Codex, or Cursor ". Naming third-party coding tools in your own product documentation is a choice. One default deserves attention. Source storage starts as nocobase , and the docs are candid about what that costs you: The default nocobase is the fastest to start with, since you don't need a repository first.It has no version history though, so a bad change can only be rolled back by overwriting everything.If this Portal will be iterated on long term, move it to Git early. The comparison table's "output: source you can commit to Git" describes what you can configure, not what you get by default. That is the official account. The alpha ships as a Docker image, so here is what a fresh install looks like. image: nocobase/nocobase:3.0.0-alpha.9 The multiPortals table comes seeded with three rows: | uid | title | portalType | routePath | isDefault | |---|---|---|---|---| default portal | Main | ai | /main | true | default admin | Desktop layout | no-code | /admin | | default mobile | Mobile layout | no-code | /mobile | There is now a portalType column, and the default entry is the ai one . The familiar admin UI has become a no-code portal at /admin .The docs describe /v/ and /x/ prefixes, but routePath in the database holds plain values like /main . I checked what the server actually returns — including a path that doesn't exist , which turns out to be the only way to see what is going on: | Path | Status | What came back | |---|---|---| / | 200 | The NocoBase SPA | /admin | 200 | Same byte-identical HTML | /main | 200 | Same byte-identical HTML | /zzz-nonexistent | 200 | Same byte-identical HTML | /v/main | 200 | A different shell, for no-code portals | /v/zzz-nonexistent | 200 | Same as above byte-identical | /x/main/ | 200 | The AI Portal's build output | /x/zzz-nonexistent/ | 404 | — | A 200 on /admin or /main means nothing here. A nonsense path returns the same HTML , so those are client-side routes in the SPA. /v/ serves its own shell but likewise ignores the name. /x/ is the only prefix where the portal name changes what the server does. /x/main/ returns different HTML and 404s on a name that doesn't exist. Look inside and the asset references are pinned to the portal's own path: <link rel="icon" type="image/x-icon" href="/x/main/favicon.ico" / "The source lives locally and the agent writes it" turns out to describe how it's served, too: an AI Portal is a separately built frontend that NocoBase serves , not a region of the NocoBase UI. If you'd rather not boot anything, the same conclusion is sitting in the package. Unpack plugin-multi-portal and the prefix assignment is right there in the bundled JS: T = "ai" === S ? "/x/" : "/v/" That line, the three seeded portals, and the portalType values are identical in alpha.9 , alpha.12 , and alpha.13 . portal-template-default is a 574-file React scaffold: React 19 with TypeScript, Vite, Refine https://refine.dev/ as the data layer, Tailwind CSS 4, shadcn/ui about 60 components , lucide, vitest, Playwright. It carries its own version number — 3.1.1 , unrelated to the app's. preset-nocobase depends on it through the caret range ^3.0.3 , which means the same 3.1.1 lands whether you install alpha.9 or alpha.13 , and the template can move without the app moving. It also ships an AGENTS.md , written for coding agents rather than people: This repository is a starter for building a NocoBase-powered application. Keep changes focused on the application being built and follow these guidelines before introducing new abstractions. The guidelines tell the agent to search for and reuse existing implementations, to extend src/components/ui by composition instead of editing the shadcn/ui base, to split tests between tests/ and e2e/ — and to put every dependency in devDependencies , with the reason spelled out: production serves only the built dist and never installs the project's Node dependencies. The delivery model was decided before the template was written. For what it's worth, that agent-facing documentation is the same material you read in a browser. I diffed the copy bundled under plugin-ai 1,115 files against the public pages: the prose is identical , differing only in front matter and list markers. Shipping documentation for AI agents is not a 3.0 feature. 2.1.23 already bundled 1,056 files under plugin-ai/dist/ai/docs , and Skills existed then too. What is new in 3.0 is that the place to put agent-written code AI Portal , the scaffold for writing it the template , and the machinery for running several entries side by side Portal manager all arrived together. The shift is from "let an agent operate NocoBase" to "run an agent-written frontend as the application's front door." Assuming the direction holds, a few things follow. The admin UI isn't going anywhere. /admin persists as a no-code portal, and the docs themselves recommend it for standard CRUD. This widens the menu. The ceiling on what you can build moves. The screens that were awkward in NocoBase were the ones that blocks couldn't express. Writing those in React while auth, permissions, and APIs stay with the platform is a genuine expansion of scope. The operational profile changes, though. AI Portal source lives in a developer's working directory and reaches production through push, build, and deploy. Something that was configured in a browser becomes something that needs a development environment and someone who can drive it. "No-code, so operations are light" stops holding for whatever you build this way — and Node.js 22, pnpm, and a coding agent become deployment requirements, not just developer preferences. Decide on source storage before you start. The default keeps no version history, and the docs recommend moving to Git early for anything long-lived. With an agent generating changes, volume and frequency both go up; starting without history is a poor trade. Licensing is unclear. The documentation doesn't say whether AI Portal is Community or commercial, and the pricing page doesn't list it yet. If that matters to your evaluation, it's an open question rather than an answer. Trying it is cheap — the Docker image is public, and booting it in an isolated environment to look at /x/main/ tells you a lot. Keep an alpha away from real data. alpha.13 with /ai-builder/ /v/ for no-code, /x/ for AI Portal, with the docs recommending each for different work /x/ varies by portal name AGENTS.md aimed at coding agentsPlenty of products promise to build software with AI. NocoBase's answer is to be the part underneath — on the reasoning that a model can produce a presentable screen but not a trustworthy permission model. Whether or not 3.0 lands this way, the way it splits the problem is sound. Runtime observations from 3.0.0-alpha.9; versions and package contents verified against 3.0.0-alpha.13 on 2026-08-31. Alphas move quickly — check the current release before relying on any of this. nb portal command reference