ChatGPT-Next-Web-Pro, and the three places its deployment notes contradict its own image

The quick start pulls an image that will not start without an authorize code

The two step deployment for the open source shape is short. Pull the image, then run it:

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

Two notes come with it. The port mapping's left side is yours to change and the right side is the container's, fixed at 3000. And any other setting is passed the same way with `-e <NAME>=<VALUE>`, with a relay endpoint added as `-e BASE_URL="https://xxxxxx"`, defaulting to `https://api.openai.com` when it is left out. The page also recommends a relay service of its own where configuration is unnecessary and a key is enough, which is worth reading as a vendor suggestion rather than as documentation.

The catch is in the Dockerfile at the repository root. Its command checks for an authorize code first and stops the container if the variable is empty:

if [ -z "$AUTHORIZE_CODE" ]; then \
        echo "MISSING AUTHORIZE_CODE" && exit 1; \

The quick start above passes only `OPENAI_API_KEY`. Taken literally, the documented command produces a container that prints a missing authorize code message and exits.

The documented curl for the backend compose file downloads a web page

The backend version is installed differently, by fetching a compose file from the repository:

curl -o docker-compose.yml https://github.com/vual/ChatGPT-Next-Web-Pro/tree/main/docker/with-backend/docker-compose.yml

That URL points at a GitHub tree page rather than at a raw file, so the command writes the HTML of a directory listing into a file called `docker-compose.yml`. The page anticipates exactly this, with an instruction to skip the curl if it fails or if what lands on disk is HTML, and to open the `docker/with-backend` directory and copy the contents into a file of the same name by hand.

Once you have the file, the sequence is ordinary: edit the environment variables inside it, then `docker compose pull` and `docker compose up -d`. One recommendation is attached to that step, to run the first start without `-d` so the logs are visible, confirm there are no errors, stop it, and only then start it detached. A separate page holds the detailed deployment steps and another holds a reference Nginx configuration.

So the backend path is manual by design at exactly the point where the no-backend path is a copy and paste. That asymmetry is not explained, and it is the reason the two shapes feel like different products.

The compose file at the root deploys the upstream image, not this fork

The `docker-compose.yml` in the repository root does not reference the project's own image. Both of its services use `yidadaa/chatgpt-next-web`, the upstream image, under two profiles named `no-proxy` and `proxy`, each mapping port 3000 and each passing the same set of variables: `OPENAI_API_KEY`, `GOOGLE_API_KEY`, `CODE`, `BASE_URL`, `OPENAI_ORG_ID`, `HIDE_USER_API_KEY`, `DISABLE_GPT4`, `ENABLE_BALANCE_QUERY`, `DISABLE_FAST_LINK`, and `OPENAI_SB`. The proxy profile adds `PROXY_URL`.

Those variable names are the upstream's, not this fork's. Nothing in the root compose file mentions drawing, music, video, the MCP directory, or an authorize code, which is the same set of variables the Dockerfile declares as empty defaults.

That makes the root compose file inherited rather than written for this project. It is the file a reader finds first, and running it gives you the upstream application with none of the additions this fork exists for. The backend variant lives elsewhere, under `docker/with-backend/`, which is the path the curl command in the deployment notes was supposed to be pointing at.

The open source build marks login, keys, messages, and payments unavailable

The feature matrix is three columns wide, comparing the 3.8 line of the no-backend build, the 3.9 and later no-backend build, and the build with a backend. Reading the rows marked unavailable in both open source columns gives a clear picture of what you do not get.

All of login and registration is absent: phone, email, and WeChat QR scanning. So is AI administration, meaning platform management, model management with defaults for translation, summarisation, and image reading, and API key management. So are package resources, package information, redemption codes, order information, member information, member packages, session topics, session messages, the three payment routes (WeChat Pay, the epay gateway, and Hupijiao), sensitive word management, and shortcut prompt management.

The 3.9 column adds the creative features the fork is known for, so the gap between 3.8 and 3.9 is midjourney-plus with face swap and inpainting, a standalone midjourney drawing panel, gpt-image-1 with redraw, luma video, S3 compatible storage across Aliyun OSS, Tencent COS, minio, AWS, and Cloudflare R2, showing the model name in a session topic, custom user names and avatars, and custom plugin buttons. File parsing of pdf, word, ppt, excel, image with OCR, audio, html, txt, and zip into markdown stays in the backend column alone.

Default credentials appear twice in the deployment notes

The important prompts are grouped under a heading that means important, and the first line is the default account for the management side: `admin/123456`, with an instruction to change the password immediately after entering.

A default like that is a normal thing for an admin panel to ship, and the note is the right note to attach to it. What makes this one worth a second look is that the same page publishes the demo addresses for the vendor's own deployment, and the management demo comes with its account and password written next to the link: `annyun` and `123456`. The user facing demo is described as supporting WeChat QR authorisation login and email registration, with phone number login noted as not configured on the demo site.

So a reader has three pieces of information in one section: a default password for any deployment they make, and the working credentials for someone else's deployment. Both are cheap to change and cheap to publish wrongly. If you run this, set the admin password before the container is reachable from anywhere but localhost, and treat the demo credentials as public information.

The runtime writes its proxy config at boot and seeds an MCP config at build

The runner stage of the Dockerfile installs proxychains-ng and does not ship a configuration file for it. Instead the command builds one at startup from the `PROXY_URL` value: strict chain, DNS through the proxy, a remote DNS subnet, read and connect timeouts of 15000 and 8000, localnet entries for 127.0.0.0 and for the IPv6 loopback, and finally a ProxyList line assembled by cutting the protocol, host, and port out of the URL. Port 3000 is exposed and the hostname is set to 0.0.0.0 when a proxy URL is present.

The MCP side is done the other way round, at build time. The builder creates `/app/app/mcp`, sets it to mode 777, and copies `mcp_config.default.json` over it as `mcp_config.json`, with an `ENABLE_MCP` variable available to turn the feature on. A world writable directory seeded from a default file is a reasonable starting point for an editor that writes user configuration, and it is also the first place to look if you want to know what MCP servers a fresh install is configured to reach.

One more build detail is easy to miss and affects everything else: the base image is pulled from a mirror host rather than the default registry, and the dependency stage points yarn at a mirror registry as well.

A generated mask step runs before every build, and app:clear starts a dev server

The package manifest is named `chatgpt-web-pro`, marked MIT, and its scripts show the shape of the project. A step called mask runs `npx tsx app/masks/build.ts`, and it is chained in front of every real build: `build` runs the mask then a standalone Next build, `export` does the same with an export mode, and the desktop build runs it before Tauri. The `dev` script runs the mask in watch mode alongside `next dev`, which is why two processes always start together.

The desktop path is Tauri, with `src-tauri/` at the root and scripts named `app:dev` and `app:build`. One of those scripts is wrong in a small but telling way: `app:clear` is defined as `yarn tauri dev`, so a command named clear starts a development server rather than clearing anything.

The rest of the manifest is ordinary tooling: eslint and prettier configuration, husky installed by a prepare script, jest for tests with separate watch and CI modes, a prompts script that fetches prompt files, and a proxy dev script that runs an init script under proxychains. The tree also carries four README translations, a Vercel configuration, a Gitpod configuration, jest and Next configuration, and a TODO file left at the root.

Tags stop in November 2025 while the tree moved in July 2026

The release history is three entries: 3.9.15 on 2025-06-13, 3.9.17 on 2025-09-01, and 3.9.18 on 2025-11-30. The last commit on the default branch is dated 2026-07-19, which is also the update date given for the no-backend version, and the image tag used in the deployment instructions is 3.9.18. So the documented install is the November build while the branch has moved on by about eight months.

The backend version carries its own date of 2025.12.01 and a version string of `latest`, which is not a version. Since the quick start pins 3.9.18 and the backend compose file is fetched from the moving branch, the two installation paths are on different clocks.

The page opens with assurances: that the code is open source, that its security matches the original ChatGPT-Next-Web exactly, that no version contains malicious code or steals keys, and that anyone worried can install a packet capture tool on the server and inspect every outbound request. No such analysis is published here, so what can be read is the compose file, the Dockerfile, and the default credentials above. Alongside a LICENSE file and an MIT field in the manifest, the page also routes requests for an authorization code or the source through a WeChat contact, which is a different arrangement from an MIT repository.

Editorial conclusion

Before anything else, read the terms of the services you point this at. The feature list includes reverse engineered model endpoints labelled gpt-4o-all and GPTs, plus a recommended third party relay where you only supply a key, and neither is something the software can make compliant for you. Beyond that, this fork fits an operator who wants the upstream interface with drawing, music, and video bolted on and is willing to run two services. Four things to check first. Whether your build starts at all, since the image exits with a missing authorize code message when that variable is empty and the quick start does not pass it. Which compose file you are actually running, since the one at the repository root deploys the upstream image rather than this fork. What the open source build gives up, because login, key management, message storage, sensitive word filtering, and payments are all marked unavailable outside the backend version. And the default admin password, which is printed in the deployment notes along with the demo admin account for the author's own site.

Frequently asked questions

Official sources

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