NocoBase: Open-Source AI and No-Code Platform for Business Systems

What NocoBase Solves and Who It Is For

NocoBase addresses the problem of building custom business systems. The conventional options are writing a bespoke application from scratch, buying a SaaS tool with vendor lock-in, or assembling something with a no-code platform that cannot handle complex workflows. NocoBase aims at a fourth path: a platform with production-proven infrastructure built in, on which both AI coding agents and human operators can build.

The README describes the target as teams who want speed and reliability together. Speed comes from AI coding agents that can handle setup, development, migration, and release end to end. Reliability comes from infrastructure that is tested in production and not regenerated from scratch with each AI prompt.

The intended users include developers who want to hand off routine configuration work to AI agents, and non-technical users who need to modify business systems visually without touching code. The README states the WYSIWYG interface is designed for regular users, not just developers.

AI Coding Agents and the WYSIWYG Interface Working Together

NocoBase exposes two parallel paths for building and modifying a system. The first is through AI coding agents. The README states it works with mainstream agents including Claude Code, Cursor, Codex, OpenCode, and TRAE. Agents get a full CLI and can handle setup, development, migration, and release operations end to end.

The second path is the WYSIWYG no-code interface, which lets people build and modify the system visually. Users can switch between usage mode and configuration mode with one click. Data models, pages, workflows, and permissions are all configurable visually through this interface.

The two paths are designed to coexist. AI agents can create data models, pages, and workflows quickly. People can then refine UI and interactions in the visual interface. The reverse is also supported: AI can continue building from human-created configuration. The README describes this as splitting the work as needed, with both sides working on the same data model so results stay transparent.

The AGENTS.md and CLAUDE.md files in the repository root suggest the project maintains explicit documentation for AI agent behavior, consistent with a platform that treats AI coding agents as first-class users.

Installing NocoBase with the CLI

The README provides a quick start that installs NocoBase through its CLI tool:

npm install -g @nocobase/cli
nb --version

This installs the NocoBase CLI globally and prints the version to confirm the install. Node.js 22 or later is required, as specified in package.json. Once the CLI is available, create a new NocoBase application:

nb init --ui

The --ui flag initializes the application with the visual interface included. The README also mentions an optional step for starting an AI agent build session at the same time:

codex

The comment in the README notes claude and opencode as alternatives to codex. These are the AI coding agent sessions that can then interact with the NocoBase CLI during the build.

The application runs on port 13000 in development mode by default, as shown in the .env.example file. The environment file also shows APP_ENV, APP_KEY, and logging configuration options including LOGGER_TRANSPORT, LOGGER_LEVEL, and LOGGER_FORMAT. For production, the .env.example notes that opening the app directly will show 'Not Found' and recommends using nginx to proxy static files.

AI Employees: Roles, Permissions, and Audit Logs

NocoBase introduces a concept it calls AI employees: AI agents that can work directly inside a running system, not just during the build phase. These are distinct from the coding agents that help build the system.

AI employees get roles with field-level read and write permissions, the same permission system that applies to human users. The README states that every AI action follows the same fine-grained permissions as human users: each AI employee has its own role with field-level access control. Admins can adjust AI permissions at any time.

Audit logs record every data change and workflow trigger, making AI actions traceable. This is presented as a reliability feature: teams that need to audit what AI employees did, and when, can do so through the same audit log that captures human user actions.

External agents can connect through MCP, HTTP APIs, and the CLI. The README lists platforms including OpenClaw, Hermes, Dify, Coze, and n8n as examples of external agent platforms that connect through standard protocols. Connections to Telegram, WhatsApp, Slack, and Gmail are also mentioned for querying data, triggering actions, and executing business workflows.

Plugin Architecture and Database Decoupling

NocoBase uses a microkernel design where everything is a plugin. The README describes this as a composable plugin approach: new features are added through plugins that follow shared conventions, and custom plugins can be mixed with official ones.

This architecture has a concrete implication for long-term maintenance. Because features are plugins rather than monolithic code, the system can grow without the team having to fork or modify the core. The same plugin architecture applies to both AI-built and manually built extensions.

Data is decoupled from the UI. Business data stays in standard relational structures, separate from the interface definition. The README states that users' data always stays in their own database, without platform lock-in. The docker-compose.yml in the repository shows MySQL 8 and PostgreSQL as supported databases, with environment variables DB_DATABASE, DB_USER, and DB_PASSWORD configuring the connection.

The data model is shared between AI agents and human operators: both work on the same underlying model. The README states this is what keeps AI output transparent, because the data model is visible and configurable through the WYSIWYG interface even when AI built it.

Where NocoBase Is Not the Right Tool

NocoBase requires Node.js 22 or later. Teams locked to an older Node.js version cannot run it without an upgrade.

The plugin architecture and microkernel design add configuration overhead compared to simpler no-code tools. A team that needs a quick spreadsheet replacement with basic filtering and forms will find NocoBase heavier than tools designed specifically for that use case.

The platform is not a traditional database viewer. Data models, permissions, workflows, and audit logs are built-in infrastructure, which means there is more to configure before a basic system is usable. The learning curve is steeper than a drag-and-drop tool with no backend concepts.

The repository has three parallel release tracks: a stable release (v2.2.18 as of 2026-09-25), a beta track (v2.3.0-beta.12), and an alpha track (v2.4.0-alpha.8). Teams that need stability should pin to the stable release. The alpha and beta tracks receive more frequent breaking changes.

The license field in the repository is NOASSERTION from GitHub's detection, but package.json lists Apache-2.0. The LICENSE-APACHE.txt file at the repository root contains the Apache 2.0 terms. Teams with license requirements should review both LICENSE.txt and LICENSE-APACHE.txt to understand which applies.

Maintenance, Docker, and Recent Releases

NocoBase received its most recent push on 2026-09-17 and released v2.2.18 on 2026-09-25, confirming active development. The release notes are published as a blog timeline at nocobase.com rather than solely as GitHub Release notes.

Docker support is documented in the docker-compose.yml and Dockerfile at the repository root. The Dockerfile uses node:22-bookworm as the build base. The docker-compose.yml defines services for the application, MySQL 8, PostgreSQL, and an adminer database UI. A Kingbase database option is also in docker-compose.yml for enterprise use cases.

The application supports cluster mode through the CLUSTER_MODE environment variable. The .env.example explains the server running modes: standalone (handles all requests and background jobs), master (handles UI requests only), and worker (handles background jobs only). Cluster mode is documented as requiring distributed architecture plugins and not working in development mode.

The repository runs as a Lerna monorepo with packages organized in packages/*/* and packages/*/*/* directories. The yarn.lock and lerna.json files at the root manage the multi-package workspace.

Editorial conclusion

NocoBase suits teams that want to build internal business tools quickly without writing a custom backend from scratch, and who want AI coding agents to be first-class contributors to the build process. It is not suited to teams that need a simple spreadsheet-style database view with no configuration: the plugin architecture and data-model-driven approach add overhead that only pays off at moderate complexity. Before adopting, verify that Node.js 22 is available in the target environment and that the required database (MySQL 8, PostgreSQL, or SQLite as shown in docker-compose.yml) is acceptable. The NocoBase CLI (nb) version can be checked with nb --version after global install.

Frequently asked questions

Official sources

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