NocoBase 3: an agent-first no-code platform whose quick start, repo tooling and production mode pull in different directions

Agents write the code, NocoBase supplies permissions, workflows and approvals

NocoBase positions itself as the platform for building, running and evolving business systems with AI, with a division of labour stated in one line: agents write the code and do the work, NocoBase provides the foundation and governance, and people make the decisions. The problem it targets is that every AI-built project otherwise rebuilds permissions, workflow engines and approvals from scratch, and that architecture drifts when developers, models or even sessions change.

The product is split three ways. NocoBase Core is the open-source application foundation, with permissions, workflows, files and other building blocks ready to use, so agents only build what is specific to the business. NocoBase Studio is a governance layer that puts Claude Code, Codex and OpenCode into one agent team that moves issues forward while people approve key decisions. NocoBase Solution is a line of agent-driven business apps built on Core. This repository is the TypeScript monorepo, organised as Lerna workspaces under packages/*/* and packages/*/*/*, with a WYSIWYG no-code interface alongside the agent workflow.

The quick start installs NocoBase 3 from the beta tag

There are two documented routes, and both create a NocoBase 3 application backed by SQLite, so no separate database server is needed. Requirements are Node.js 24 or newer and pnpm 11, and Windows users are told to use WSL.

With a coding agent that supports Skills, open it in an empty directory and install the app creation Skill:

npx skills@latest add nocobase/skills-v3 --skill nocobase-create-app -g

Pick your agent during installation and start a new session if it does not see the Skill. Then send it this instruction:

Follow the nocobase-create-app Skill to create and start a NocoBase 3 application in the current empty directory, using the default template and SQLite.

From the terminal, run this in the parent directory of your projects:

PNPM_CONFIG_MINIMUM_RELEASE_AGE=0 pnpm create @nocobase/app@beta my-app --template-tag=beta
cd my-app
pnpm nocobase config init --dialect sqlite
pnpm nocobase config check
pnpm dev

The first line pulls the app creator and its template from the beta tag, and the PNPM_CONFIG_MINIMUM_RELEASE_AGE=0 prefix sets pnpm's minimum release age to zero for that command, so freshly published beta packages are not held back. config init writes a SQLite configuration, config check validates it, and pnpm dev starts the app. What you get is a beta: the newest v3 build is tagged nocobase-v3-beta/2026-11-02.1.

Three release tracks, and the repository scripts still call nocobase-v1

Within one day the project published three different releases: v2.4.0-alpha.16 and v2.3.0-beta.20 on 3 November 2026, and NocoBase v3 Beta 2026-11-02.1 on 2 November. The main branch itself last received a push on 30 September 2026. Anyone choosing a version has to pick a track first, because the quick start points at v3 while the numbered v2 alphas and betas keep shipping in parallel.

The repository tooling adds to the split. The root package.json routes almost every script through a nocobase-v1 binary: dev runs nocobase-v1 dev --rsbuild, dev:umi runs the older dev server, dev:client-v2 and build:client-v2 pass --client-v2-only, and test, e2e, benchmark, perf and build all go through the same CLI. The repository uses yarn, with a yarn.lock at the root and docs run by yarn --cwd docs, while the quick start uses pnpm. The engine requirement differs too: package.json declares node >=22, the quick start asks for Node.js 24+. If you are contributing to the monorepo rather than creating an app, follow the repository's own toolchain and read AGENTS.md first, as the contribution guidance asks.

APP_ENV=production serves Not Found on port 13000 without nginx

The .env.example file carries a warning that is easy to miss: when APP_ENV is set to production, opening http://localhost:13000/ shows "Not Found". In production mode the application does not serve the front end itself, and the recommendation is to put nginx in front to serve static files, with a sample configuration at docker/nocobase/nocobase.conf in the repository.

The consequence for a first deployment is that switching the example file from development to production and restarting gives you an apparently broken server. Plan the reverse proxy as part of the deployment, not as an afterthought. The same file ships defaults that are only suitable for local work: APP_PORT=13000, API_BASE_PATH=/api/ and APP_KEY=test-key. Replace the key before exposing anything.

Logging is set through LOGGER_TRANSPORT (console, file or dailyRotateFile), LOGGER_LEVEL (error to trace), LOGGER_FORMAT (console, json, logfmt or delimiter), and LOGGER_MAX_FILES and LOGGER_MAX_SIZE, where rotation by days needs a d suffix and sizes take k, m or g. Logs go to storage/logs by default.

Cluster mode only works with the distributed plugins enabled

Scaling out is controlled by two variables in .env.example, and both come with conditions. CLUSTER_MODE starts the application in cluster mode, equivalent to pm2 -i with the given value. The comment attached to it is blunt: cluster mode only works properly when the plugins related to distributed architecture are enabled, otherwise the application may encounter unexpected issues, and it does not work in development mode at all. Setting CLUSTER_MODE on a default install is therefore a way to create hard-to-diagnose bugs, not a free performance gain.

A second setting splits request handling from background work. Left empty, the server runs standalone and processes both HTTP requests and background jobs. A value of ! makes it a master that only serves UI requests. A value of * makes it a worker that only processes background jobs, and a comma-separated list of topics limits a worker to those job topics. A mixed form starting with ! followed by topics serves requests plus jobs for the named topics. This gives you a way to move heavy workflow jobs off the web process, but each role has to be deployed and monitored separately.

docker-compose.yml is a development bench, not a deployment

The docker-compose.yml at the root defines the services used to develop and test NocoBase against several databases: a Verdaccio npm registry, mysql:8, postgres:latest started with wal_level=logical, a KingbaseES image pulled from registry.cn-shanghai.aliyuncs.com that is pinned to linux/amd64 and runs privileged, and an Adminer instance. Ports come from .env.example: Adminer on 10101, MySQL on 10102, Postgres on 10103 and Verdaccio on 10104. The nocobase service itself runs yarn start on a node:16-stretch-slim image with the whole checkout mounted at /app, which does not match the node >=22 requirement in package.json.

The Dockerfile is also a build pipeline rather than a pull-and-run image. It starts from node:22-bookworm, logs in to a Verdaccio registry at http://host.docker.internal:10104/ with test credentials through an expect script, then runs yarn create nocobase-app with APP_ENV=production and installs production dependencies. Without that local registry populated, the build has nothing to install from. A USE_ALIYUN_MIRROR=1 build argument switches Debian sources to mirrors.aliyun.com. For running NocoBase, start from the quick start and the documentation at docs.nocobase.com, not from these files.

Two license files and a NOASSERTION label

GitHub labels the repository license NOASSERTION. The root holds two license files, LICENSE.txt and LICENSE-APACHE.txt, while package.json declares Apache-2.0 for the private monorepo root. The README calls NocoBase open source and calls Core the open-source application foundation, but it does not spell out which terms cover which packages in the tree.

The practical consequence is that you should not assume every package is Apache-2.0 because the root package.json says so. Read LICENSE.txt before embedding NocoBase in a product you sell or host for customers, and check the license field of each package you depend on under packages/. Studio and Solution are presented as separate offerings on nocobase.com, so their terms are also a separate question from the repository's.

On the community side, questions go to forum.nocobase.com, reproducible bugs and improvement requests go to GitHub Issues, and the repository root carries SECURITY.md for security reports. Contributors are asked to read AGENTS.md before changing the repository, and CLAUDE.md and CONTEXT.md sit next to it for coding agents working in the tree.

Editorial conclusion

NocoBase fits teams that want agents to build internal business systems on a shared foundation of permissions, workflows and approvals instead of regenerating that plumbing per project, and who are comfortable running a beta: the quick start installs NocoBase 3 from the beta tag. It is a poor fit for anyone who needs a single stable release line today, or who expects docker compose up to produce a production server. Before committing, read LICENSE.txt alongside LICENSE-APACHE.txt, decide between the v2 and v3 release tracks, and plan an nginx front end for APP_ENV=production.

Frequently asked questions

Official sources

1. Issues
2. nocobase/nocobase on GitHub
3. Project website
4. README
5. Releases