# BuildingAI: a self-hosted, block-based AI application builder

> BuildingAI is an Apache-2.0 monorepo that packages agents, RAG knowledge bases, MCP tool calls and membership billing behind a visual configuration interface. The Docker path is short; the operational surface underneath it is not.

**BidingCC/BuildingAI** — AI时代的WordPress，东半球首个积木式AI应用搭建系统，人人都可免费搭建自己的AI应用系统，例如企业智能体系统、AI漫剧系统、AI论文学术系统、AI客服系统...

- Repository: https://github.com/BidingCC/BuildingAI
- Website: https://www.buildingai.cc
- Stars: 1,895 · Forks: 457
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/bidingcc-buildingai

## What BuildingAI actually solves, and for whom

BuildingAI is aimed at people who want an AI application system they control, without writing the plumbing. The README describes it as an enterprise-grade open-source intelligent agent platform for AI developers, AI entrepreneurs and organizations, built around a visual configuration interface it calls Do It Yourself. The intended output is a native enterprise AI application: an agent, a knowledge-base assistant, a support bot, a document workflow.

The problem it targets is assembly work. Standing up an agent product normally means stitching together a model gateway, a vector store, a chat UI, a user table and a payment path. BuildingAI ships those as one system. Its feature list names AI conversations, agents with memory and tool use, knowledge bases with vector search and RAG, MCP integration over SSE and Streamable HTTP, unified model management, an extension mechanism, and membership, billing and payment features.

That list also defines the audience. If you only need a chat wrapper around one model, this is far more machinery than the job requires. It pays off when the billing and membership layer matters as much as the model calls, because that is the part most teams end up writing badly and late.

## The monorepo, the containers and how a request moves

The repository is a pnpm and Turbo monorepo. The root package.json names the workspace buildingai-monorepo, version 26.1.2, and the top level holds packages/, extensions/, skills/, templates/, scripts/ and docker/. Backend code is NestJS 11 with TypeORM 0.3 against PostgreSQL 17, and the badges also list TypeScript 5, Vue 3, Vite 7, Nuxt 4 and NuxtUI 3.

The runtime shape is visible in docker-compose.yml. It defines a Redis 8.2.2 service and a PostgreSQL 17.6 service, both pulled from a Tencent Container Registry path, each with a healthcheck and each with a memory and CPU limit taken from environment variables. The compose file sets a default memory limit of 3584M and a CPU limit of 1.0 for a service, with a 512M reservation. Data is bind-mounted to ./docker/data/redis and ./docker/data/postgres/postgres_data, so the database survives a container rebuild only as long as those directories do.

The application process itself is managed by PM2, not by compose. The .env.example exposes PM2_APP_NAME, PM2_INSTANCES, PM2_EXEC_MODE, PM2_MAX_MEMORY and PM2_WATCH, and the root scripts stop, restart and delete call the CLI at packages/cli/bin/cli.js with pm2:stop, pm2:restart and pm2:delete. Configuration reaches both sides through .env: the backend reads DB_HOST, DB_PORT, REDIS_HOST and REDIS_PORT, while the web tier reads VITE_DEVELOP_APP_BASE_URL, VITE_PRODUCTION_APP_BASE_URL and the API prefixes VITE_APP_WEB_API_PREFIX and VITE_APP_CONSOLE_API_PREFIX. Two prefixes, /api and /consoleapi, are the split between the user-facing API and the admin console API.

## Installing BuildingAI with Docker Compose and finishing setup

The README states minimum requirements of 2 CPU cores, 4 GB RAM and 5 GB of free disk, and calls Docker the simplest and most stable option. Docker and Docker Compose must already be installed. The quick start is three commands: enter the directory, copy the environment file, start compose.

```bash
cd buildingai
cp .env.example .env
docker compose up -d
```

The README says to update APP_DOMAIN in .env for production, and the example file ships it empty with a comment pointing at a real URL. Image pulling and build take roughly 5 to 10 minutes depending on hardware and network; progress appears in the Node.js container logs, and the README says the project is up once an accessible URL shows there.

Then the browser step. Visit the install wizard and complete it.

```text
http://localhost:4090/install
```

Port 4090 comes from SERVER_PORT in .env.example, so changing that value moves the install URL with it. The README points to a separate deployment guide for other methods and does not describe them inline. Two values in .env.example deserve attention before you expose anything: JWT_SECRET defaults to the literal string buildingai, and DB_PASSWORD defaults to postgres. Neither is a production value.

## Where the defaults will bite you

The environment file is written for a local first run, and several defaults are unsafe the moment the install is reachable from a network. JWT_SECRET is buildingai. DB_PASSWORD is postgres. SERVER_CORS_ORIGIN is *, and SERVER_CORS_ENABLED is true. SERVER_SHOW_DETAILED_ERRORS is false, which is the right default, but the secret and credential defaults are not.

Resource sizing is a second trap. The README floor is 4 GB RAM, while docker-compose.yml caps a single service at 3584M by default and .env.example sets DOCKER_MEMORY_LIMIT to 6144M. Those numbers do not obviously agree with each other, and the compose defaults are overridden by whatever is in your .env, so a machine that barely meets the README minimum can still have containers killed by the limit rather than by the host. Watch the Node.js container logs during the first build, as the README suggests, and treat the memory values as something to tune rather than accept.

Upgrades are the third. The repository ships three releases: 26.1.0 on 2026-04-30, 26.1.1 on 2026-05-15 and 26.1.2 on 2026-08-13, with the last push to master on 2026-08-21. Nothing in the README or the file listing describes a rollback path or a database migration procedure, and DB_SYNCHRONIZE defaults to false while DB_DEV_SYNCHRONIZE is true. If you intend to run this in production, the upgrade story is the thing to establish before you have data you care about, because the project does not document one.

## BuildingAI against Dify, FastGPT and the rest of the field

The repository topics place BuildingAI next to coze, dify and fastgpt, and those names are the honest comparison set. The difference in approach is where the commercial layer sits. Dify and FastGPT are generally adopted as application and workflow platforms you host and then integrate outward: you bring your own accounts, quotas and payment handling, and you build the business layer yourself.

BuildingAI puts membership, compute billing and payments inside the same install as the agents and knowledge bases. That is the distinguishing design choice, and it is the reason the platform ships user registration and subscription handling rather than leaving them to the integrator. If your product is the AI application itself and you want to charge for it, that saves real work. If your AI feature is a component inside an existing product with an existing billing system, the built-in one is dead weight you will have to route around or disable.

The second difference is the extension mechanism. BuildingAI ships extensions/ and skills/ directories and an extension system for adding capabilities and AI skills, which is closer in spirit to a plugin platform than to a fixed workflow editor. That is a bet on customization over configuration, and it means the quality of your install depends on extensions you may not control.

## Questions worth answering before you deploy

Is this a hosted service? No. The README describes an open-source platform you deploy, with Docker Compose as the recommended path and a live demo at demo.buildingai.cc for evaluation. The official site and documentation are separate from the code.

Does it need a GPU? Nothing in the README or the compose file mentions one. The stated requirements are CPU cores, RAM and disk, and model access is handled through the model management feature that aggregates providers under a unified API specification. You supply the model credentials.

What does the licence allow? The repository is Apache-2.0, stated in both the README and package.json. That permits commercial use and modification, but it also means you inherit the obligation to keep the licence and notice files intact in redistributions. That is a description of the licence text, not advice about your situation.

How current is it? The last push to master was on 2026-08-21, and the most recent release, 26.1.2, was published on 2026-08-13. The repository is not archived. Whether that release cadence suits your maintenance budget is a judgement the release dates let you make directly.

## Conclusion

BuildingAI fits teams that want agents, RAG and billing behind one self-hosted install and are willing to run PostgreSQL, Redis and a PM2 process themselves. It does not fit anyone who wants a purely managed service, or who cannot spare the 4 GB RAM floor from the README. Before adopting it, read .env.example and set APP_DOMAIN and JWT_SECRET, then confirm from the deployment guide which other deployment methods are supported, because the README only names Docker Compose and links out for the rest.

## FAQ

### What does BuildingAI mean and what is it?

In this project it names an open-source intelligent agent platform you deploy yourself, described in the README as aimed at AI developers, AI entrepreneurs and organizations. It combines agents, RAG knowledge bases, MCP tool calls, model management and membership billing behind a visual configuration interface.

### What company is building BuildingAI?

The repository is published under the GitHub account BidingCC, and package.json lists the author as BuildingAI Teams with the site https://www.buildingai.cc. The README links to that site as the official website and to a separate documentation site.

### Is BuildingAI free?

The source is released under the Apache License 2.0, stated in both the README and package.json, so there is no licence fee to run it. You still pay for the hardware and for whatever model providers you connect through model management.

### How to start building AI applications with BuildingAI?

The README recommends Docker Compose: copy .env.example to .env, run docker compose up -d, and then open http://localhost:4090/install in a browser to run the setup wizard. It states minimum requirements of 2 CPU cores, 4 GB RAM and 5 GB of free disk.

## Sources

- [BidingCC/BuildingAI on GitHub](https://github.com/BidingCC/BuildingAI)
- [License: Apache-2.0](https://github.com/BidingCC/BuildingAI/blob/master/LICENSE)
- [Project website](https://www.buildingai.cc)
- [README](https://github.com/BidingCC/BuildingAI/blob/master/README.md)
- [Releases](https://github.com/BidingCC/BuildingAI/releases)

---

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