ChatGPT-Next-Web-Pro: a fork that adds Midjourney, Suno and an admin backend

What the fork adds on top of ChatGPT-Next-Web

Upstream ChatGPT-Next-Web is a chat front end. This fork keeps that and adds two things that change the deployment story: an extended model panel and, in the backend build, an account and billing system.

The feature table in the README splits everything into three columns: no-backend 3.8.*, no-backend 3.9+, and with-backend. That split matters more than any single feature. Midjourney-plus (the AI face swap and inpainting modes), the standalone Midjourney drawing panel, Luma video and gpt-image-1 redraw are marked as absent from 3.8.* and present in 3.9+. File parsing of pdf, word, ppt, excel, image OCR, audio, html, txt and zip is marked present only in the with-backend column. So is every account feature: phone, email and WeChat official-account QR login, model management, apikey management, plan resources, redemption codes, orders, members, WeChat Pay, Yipay and Hupijiao payment.

The audience is therefore narrow and concrete. This is for someone running a paid or gated access point for models, not for a developer who wants a nicer chat window. If you are the latter, the extra tables and payment integrations are dead weight you still have to configure.

How model routing and storage actually work

The architecture is the standard Next.js pattern: a browser client, Next.js API routes acting as the proxy, and a set of upstream providers behind them. The Dockerfile builds with BUILD_MODE=standalone, copies .next/standalone, .next/static and .next/server into the runner stage, and exposes port 3000. Nothing exotic.

The interesting part is where credentials live. In the stateless image, the API key arrives as an environment variable at container start, and BASE_URL decides whether requests go to api.openai.com or to a relay. The README notes that without BASE_URL the default is https://api.openai.com. With the backend build, the README describes platform-level apikey management and model management where you set which model is the default, which handles translation, summarization and image recognition. That is a different trust model: keys sit in the application database rather than in the container environment, and the admin console becomes the thing worth protecting.

Storage follows the same pattern. The dependency list includes @aws-sdk/client-s3, @aws-sdk/s3-request-presigner, ali-oss and cos-nodejs-sdk-v5, which matches the README's claim of S3-compatible storage covering Aliyun OSS, Tencent COS, minio, AWS and Cloudflare R2, plus Aliyun, Tencent and minio as named options and a custom upload interface. The Dockerfile also copies app/mcp/mcp_config.default.json to app/mcp/mcp_config.json and sets ENABLE_MCP, so there is an MCP server configuration path in the image, though the README does not document it.

Installing the stateless image and sending a first message

The README gives a two-step Docker flow for the no-backend version. First pull the image tagged 3.9.18 from the Aliyun registry.

docker pull registry.cn-hangzhou.aliyuncs.com/ann-chat/chatgpt-next-web-pro:3.9.18

The second step runs it with your key. The README's example maps host port 3000 to container port 3000 and passes OPENAI_API_KEY.

docker run -d -p 3000:3000 \
  -e OPENAI_API_KEY="sk-xxxxxx" \
  registry.cn-hangzhou.aliyuncs.com/ann-chat/chatgpt-next-web-pro:3.9.18

The README states that the right side of the port mapping is the internal container port and cannot be changed, while the left side can, giving 3030:3000 or 3080:3000 as examples. If you use a relay, append -e BASE_URL="https://xxxxxx". Open http://localhost:3000 and you should get the chat interface; if the key is wrong you will see provider errors in the response, not at startup, because nothing validates the key when the container boots.

For the with-backend version the README points at a docker-compose.yml under /docker/with-backend/ and gives a curl to fetch it, with a fallback instruction to open the directory on GitHub and copy the contents by hand if the download returns HTML. Then:

docker compose pull
docker compose up -d

The README advises running without -d the first time to watch the logs, then restarting detached once it is clean. The default admin credentials are given as admin/123456, with an instruction to change the password immediately.

The AUTHORIZE_CODE gate and other ways a deploy fails

The Dockerfile's CMD is the sharpest constraint in the repository. It checks AUTHORIZE_CODE first and, if the variable is empty, prints MISSING AUTHORIZE_CODE and exits with status 1. The stateless docker run example in the README does not pass AUTHORIZE_CODE. That is a real contradiction between the documented command and the image's entrypoint, and it is the first thing to test on your own build rather than assume.

The second failure mode is the version split. The README dates the no-backend source at 2026.07.19 and the with-backend version at 2025.12.01, and labels the backend build "latest". Two artefacts with different dates and different feature sets share one repository, so "I deployed ChatGPT-Next-Web-Pro" says very little about what is running. File parsing and the entire account system exist only on the backend side; if you pull the wrong image you will spend an afternoon looking for menus that are not there.

The third is licensing and provenance. The repository licence is MIT and package.json declares "license": "mit", but the README also has a section titled 授权码或者源码获取方式 (how to obtain an authorization code or source) with a WeChat contact. There is no documented way to tell from the outside which parts of the backend build are covered by the MIT grant and which require that contact. Treat that as an open question to resolve before commercial use, not as a detail.

Where the fork is the wrong tool

If your goal is a private chat UI for a handful of people, this fork is more than you asked for. The stateless build is a superset of upstream with extra drawing and music panels; the backend build adds tables for orders, members, plans and payment providers that you will never populate. Every one of those is an admin surface you own and have to keep patched.

If you need upstream's release cadence, this fork will lag. The README says each release merges the original project, and the release list shows 3.9.15 in June 2025, 3.9.17 in September 2025 and 3.9.18 in November 2025, with the last push to the repository on 2026-07-19. That is a slow-moving branch, so a security fix landing upstream may not reach you quickly.

If you need documented MCP behaviour, look elsewhere for now. The image ships an MCP config file and an ENABLE_MCP variable, but the README does not describe how to configure or use it. Undocumented features in a container you are billing customers from are a liability, not a bonus.

How it compares with LobeChat and upstream

The same author maintains lobe-chat-pro, which the README describes as having a stronger drawing, music and video panel supporting sora, veo, gpt-image-1, nano banana, midjourney, suno, luma, runway, Kuaishou Kling and Doubao image generation. The approach differs: LobeChat is an assistant-and-plugin platform where models are configured as providers, while ChatGPT-Next-Web-Pro is a chat-first interface with an attached admin and billing layer. If your problem is model breadth and plugin composition, lobe-chat-pro is the closer fit. If your problem is selling access with plans and redemption codes, this project has the pieces already wired.

Against upstream ChatGPT-Next-Web, the difference is scope rather than design. Upstream is the chat client; this fork is the chat client plus a small SaaS. The fork inherits upstream's interface and its environment-variable conventions, which is why the repository's own docker-compose.yml still references the yidadaa/chatgpt-next-web image and variables like OPENAI_API_KEY, CODE, BASE_URL and DISABLE_GPT4. That file is a useful reminder of how much of the configuration vocabulary is upstream's, not this project's.

Upgrade cost, maintenance and licence questions

Maintenance is the weakest documented area. The README lists release dates but no migration notes, no schema version, and no rollback procedure; the README does not document rollback at all. If the backend build stores users, orders and plans in a database, an upgrade that changes that schema is a one-way operation unless you have your own backups. That is an assumption you should verify against docs/后台版本部署步骤.md before you put real orders through it.

The practical upgrade path for the stateless image is to change the tag in your docker run or compose file and restart. For the backend version, the README's own advice to run without -d and watch the logs applies to upgrades too, since a failed start is easier to read in the foreground.

On licensing: the repository is MIT, which normally permits commercial use and modification with attribution. The presence of a separate authorization-code contact in the README makes the boundaries unclear for the backend build, and the Dockerfile's hard requirement for AUTHORIZE_CODE suggests the image is gated at runtime. That combination is worth a direct question to the maintainer before you build a business on it. This is an observation about what the repository documents, not legal advice.

Editorial conclusion

Adopt it if you are reselling or internally distributing model access and want login, plans and S3-backed uploads in one container, and you accept that the admin build is a separate artefact from the open source code. Skip it if you only need a private chat UI: upstream ChatGPT-Next-Web does that with less surface. Verify first that your build actually starts, because the Dockerfile exits with MISSING AUTHORIZE_CODE when AUTHORIZE_CODE is unset, and confirm which of the two versions your image corresponds to before you plan any upgrade.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vual/ChatGPT-Next-Web-Pro on GitHub