liujh0729-jpg/AI-enterprise-OEM

What it is

AI-enterprise-OEM is a self-hostable enterprise service platform that combines an internal workbench with a business social network. It targets teams that need one account system covering both internal management and external customer acquisition and business matching, rather than a single-purpose tool.

The workbench includes 15 modules: Agent, Workbuddy enterprise cloud, multi-dimensional tables, RPA, content creation, marketing tools, digital asset management, AI email, CRM, BI, OA, OKR, AI customer service, an app center and a topic hall. Alongside these sit 11 business service lines (marketing, supply and marketing network, finance and tax, cross-border, flexible staffing, logistics, IT, IP, legal, think tank, asset trading), plus a 15-section platform admin panel, business social networking, recruiting and a supply-demand marketplace README.

The stack is Hono 4 + Prisma + MySQL 8 or PostgreSQL on the backend, and Next.js 16 + React 19 + Ant Design 6 on the frontend. A shared contracts package defines the 1254 HTTP operations used by the frontend, backend, MCP server and OpenAPI snapshot.

Quick start

Prerequisites: Node.js 24 or later, pnpm 10 or later, and a reachable MySQL 8 or PostgreSQL instance.

pnpm install
pnpm setup   # interactive: pick MySQL/PostgreSQL, enter connection details, write backend/.env, generate client, create tables
pnpm dev:api & pnpm dev:web

Open http://127.0.0.1:15890 and register a local account to use social and supply-demand features. For a platform admin account, set ADMIN_USERNAME / ADMIN_PASSWORD in backend/.env, then run:

pnpm --filter aiworkin-enterprise-api exec tsx scripts/seed-admin.ts

Admins are not created automatically at install time. A Docker Compose setup with MySQL, backend and frontend is also provided with docker compose up --build, followed by the same admin-seeding command inside the api container. A hosted demo is available at enterprise.aiworkin.com.

Configuration and upstream dependency

Most social and supply-demand features work locally without any key. Features that publish to the upstream AIworkin market, sync provider data or pull business-lead resources require binding an AIPDD API key under "Open Integration → API Key Management". Basic reference data can instead use a platform-level key configured in the admin panel. Without an upstream key, those actions return a guidance-style 403 while local publishing continues to work README.

Several environment variables are required for a correct deployment: DATABASE_URL, DB_PROVIDER, JWT_SECRET, and EXTERNAL_CRED_KEY. The last two must be random values in production; the backend refuses to start without them. Switching between MySQL and PostgreSQL requires re-running pnpm setup, because Prisma client generation and table creation differ by dialect.

Constraints

• The PostgreSQL path derives a schema from the MySQL schema and uses prisma db push instead of the migration history; the README lists a known difference in free-text case sensitivity between the two databases.
• CI covers MySQL 8 migrations, but the database-dependent integration scripts (test:regression, test:query-plans, test:performance, test:geo-recovery) target PostgreSQL only.
• The project explicitly excludes the upstream commercial version's SNS NestJS backend, coin-related reward/settlement business, and server-side key issuance. AWcoin is read-only display only.
• Frontend builds need a raised Node heap (default 6 GB via the provided script); the default ~4 GB heap can OOM when compiling 55 pages.
• Licensed under Apache-2.0 LICENSE.

HotRepo's take

The repository was recorded once on the HotRepo new-project list on 2026-11-08, gaining 8 stars in a roughly one-hour window and reaching 108 total stars with 1 fork. That is a single snapshot, so it does not establish a trend. What stands out from the technical facts is the scale of the scope claimed in the README: 1254 HTTP operations, 301 Prisma models and 55 page routes are far larger than a typical young project, and the README documents concrete dialect handling and CI checks rather than only feature marketing. Whether the implementation matches that scope is not something the current HotRepo records can confirm.