ai-beehive: a Java room server for ChatGPT, Midjourney and NewBing, now stopped

What ai-beehive actually solves, and for whom

Most chat front ends hard-code one provider. ai-beehive, described in its README as the 2.0 version of chatgpt-web-java renamed, takes the opposite route: every capability is a cell, and a cell is a room type that users enter and talk to. The README lists the implemented cells as OpenAi GPT 3.5, OpenAi GPT 4, the official ChatGPT 3.5 and 4, OpenAi Image drawing, Midjourney and NewBing. The name comes from that idea. The README says the hexagonal honeycomb inspired the design, because rooms are shaped by drawings and new drawings extend the set of room types.

The audience is narrow and specific. This is a Java backend for developers who want one account system, one permission model and one WebSocket layer in front of several model providers, rather than four separate tools. It is not a hosted product you sign up for. The README points at a demo front end at front.aibeehive.icu and a separate front-end repository by another author, chatgpt-shuowen, which means the backend and the UI live in different projects with different owners.

The cell, drawing and permission model

The mechanism is a three-layer configuration stored in MySQL. A cell is a room type. A drawing is the definition that shapes it. Config items hold the parameters each cell needs, and the README states that basically all parameters of a cell can live in the config item table, with initial values shipped in the initialization SQL. Config items support defaults, required flags, whether a user may use the default, whether a user can see it, whether a user can see the default, whether a user can modify it, and whether it can be modified after a room is created.

Permissions sit on top of that. The README describes a bh_cell_permission table with a cell_code, a type where 1 means view and 2 means use, and a user_id where 0 means every user holds that permission. Use implies view. Only cells in published state can be used at all, and the README notes that even an already-created room cannot send content if its cell is not published. That is a deliberate kill switch: if a provider starts failing, an operator can stop the cell without touching user rooms.

The honest part is how you operate this. The README states plainly that cell and config management must currently be done by hand in the database. There is no admin UI. That single sentence tells you more about the project's maturity than any feature list.

Running ai-beehive locally

The README is thin on deployment. It says the database script lives at beehive-bootstrap/src/main/resources/db/schema-mysql.sql, that a default account exists with the email hellobee@aibeehive.icu and the password 123456, and that MySQL and Redis must be installed first. It then says the deployment instructions are still to be completed and that running it should not be a problem for Java developers. Treat that as an admission, not a guide.

The README names the two services you need before anything else, and the repository root carries a Maven wrapper, mvnw, alongside the beehive-base, beehive-bootstrap, beehive-cell and beehive-web modules. The README does not give the exact property names or a run command, so read the files under beehive-bootstrap rather than assuming a layout.

Login and registration behaviour is controlled by a row in the bh_sys_param table under the param key email-registerLoginConfig. The README gives this shape:

{
  "registerVerificationRedirectUrl": "http://localhost:1002/#/emailValidation?type=email&verifyCode=",
  "registerVerifyCodeExpireMinutes": "验证码过期时间（分钟）",
  "registerTemplateSubject": "邮件标题",
  "registerAllowSuffix": "@qq.com,*",
  "registerEnabled": true,
  "loginAllowSuffix": "@qq.com,*",
  "registerCheckEnabled": true
}

registerAllowSuffix and loginAllowSuffix restrict which email domains may register or log in, with an asterisk as the wildcard. registerEnabled turns registration off entirely. registerCheckEnabled puts new accounts into a pending state until an administrator approves them. This is the one part of the system the README documents well enough to configure without reading source. Everything else in the deployment path, including how the application is started, is left to the reader.

Midjourney rooms and the progress-bar problem

The Midjourney cell is the most developed room type and the README credits the midjourney-proxy project as its reference. It covers imagine (text to image), upscale, variation and describe (image to text). Imagine takes an English prompt typed into the message box and shows a progress bar while it runs. Generated images are shown scaled down to save bandwidth, with an option to view the original.

The failure mode is documented and unpleasant. If you submit illegal content, the README says there is no prompt or error shown, and the message is effectively treated as an exception; a scheduled task resets the task state. So a user can sit in front of a progress bar that will never resolve, and the only recovery is a timer. Upscale has its own constraint: a generated image can be upscaled once, and the README says the button cannot be clicked again.

Describe works differently from what the name suggests in other tools. You upload an image, the service returns four candidate prompts, and options 1 through 4 send the corresponding prompt as a new imagine message. It is a prompt-generation loop, not a captioning endpoint.

NewBing, the official ChatGPT cell and the API key rotation

Two cells are flagged as unreliable in the README. NewBing is described as working locally but not online, with the cause still being investigated. That is a strong statement: the same code behaves differently depending on where it runs, and the maintainers had not found out why. The official ChatGPT cells were given better error-type handling for returned values, which suggests the reverse-engineered path was fragile enough to need classification rather than simple failure.

The README's implementation notes mention one concrete technique: OpenAi ApiKey rotation. Multiple keys are cycled to spread load or work around per-key limits. The README does not document the rotation policy, the failure behaviour when all keys are exhausted, or where keys are stored, so anyone relying on this should read the source rather than the documentation.

For OpenAi GPT 3.5 and 4, every parameter of the OpenAI call is exposed as a config item, and the README notes you can decide per item whether users may configure it themselves. That is a sensible design for a multi-tenant tool and also a way to let users burn your quota if the defaults are wrong.

The stack, and what it costs to keep running

The framework list is a snapshot of mainstream Java backend choices around 2023: Spring Boot 3.x, JDK 17, MySQL 8.x, MyBatis Plus, MapStruct, Lombok, Redis, WebSocket, thumbnailator for image handling, lock4j for distributed locks, Forest as the HTTP client, Hutool, SaToken for authentication, SpringDoc for API docs, and the Grt1228 chatgpt-java SDK. Tokens are stored in Redis via SaToken, according to the README.

JDK 17 and Spring Boot 3 are the two constraints that age worst. Spring Boot 3 requires Jakarta namespace packages, so any library in this stack that still ships javax imports will not drop in cleanly. The README does not state a supported upgrade path, and the release list stops at v2.1.0 in July 2023 while the last push to the repository was on 2026-04-13. There is no evidence of a migration guide or a compatibility matrix in what the README describes.

The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. It also includes a patent grant. None of that removes the practical problem: the README says the project has stopped being maintained, so you inherit the code as-is. For a project that talks to third-party APIs, that matters more than usual, because provider endpoints change and the SDK version pinned here will not move with them. This is not legal advice; check the LICENSE file at the repository root and your own obligations.

Alternatives and what is different about them

The closest reference point named in the README is chatgpt-web-java 1.0, the earlier version of the same project. The README links its final branch at v1.1.0 and a separate demo site. The difference is architectural: 1.0 is a single-purpose ChatGPT web backend, while ai-beehive generalises the same idea into cells, drawings, config items and per-cell permissions. If you only need ChatGPT and no Midjourney or NewBing, 1.0 is the smaller surface, and it is equally unmaintained.

The other named reference is midjourney-proxy, which the README credits for the Midjourney cell implementation. That project is a proxy focused on one provider rather than a multi-provider room server. If Midjourney is your whole requirement, a dedicated proxy plus your own front end avoids carrying the cell and permission machinery. If you need one login and one permission system across several providers, that machinery is the reason to look at ai-beehive at all.

What no alternative here provides is a maintained path. The README's own plan list (admin-side cell management, more cells such as 文心一言, 通义千问 and chatglm, an image gallery, a prompt store) reads as a wish list, not a roadmap, and the stop notice at the top overrides it.

Editorial conclusion

Adopt ai-beehive only as a reading exercise or as a self-hosted experiment on a machine you control, and only if you accept the README's own statement that it has stopped being maintained. Do not build a product on it: the README says deployment instructions are still to be completed, cell and config management are manual database edits, and NewBing is described as working locally but not online. Before anything else, verify that the MySQL schema at beehive-bootstrap/src/main/resources/db/schema-mysql.sql loads cleanly on MySQL 8.x, then change the default account hellobee@aibeehive.icu with password 123456, which the README states ships in the database.

Frequently asked questions

Official sources

1. hncboy/ai-beehive on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases