ChatAny: a self-hosted ChatGPT and Midjourney web front end its own README says is unmaintained

What ChatAny actually is, and the maintenance notice at the top of its README

ChatAny is a TypeScript web application built on ChatGPT-Next-Web. Its README describes it as one-click access to your own ChatGPT plus many AI web services, and the feature list claims all original ChatGPT-Next-Web functionality, StabilityAI image models (Stable Image Ultra, Stable Image Core, Stable Diffusion 3), and a non-official Midjourney integration covering Imagine, Upscale, Variation, Zoom, Vary, Pan, Reroll, Describe and Blend, plus Vary Region, reference images, progress percentage and live image display.

The first line of the README is a notice that the project has stopped being maintained, pointing readers to a separate desktop client called AQBot. That notice is the single most important fact for anyone evaluating this repository. The last push to the repository was on 2026-04-02, and the most recent release listed is v3.5.0 from 2024-10-30. The repository is not archived, so the code remains readable and forkable, but the maintainers themselves are directing new users elsewhere.

Who is it for, then? Realistically, two groups: people who want a self-hosted chat plus drawing front end and accept that they are adopting an abandoned codebase, and people who already run ChatGPT-Next-Web and want to see how the Midjourney proxy wiring was added on top. It is not a good choice for anyone who needs a vendor relationship, a support channel, or a predictable upgrade path.

How the drawing integrations are wired: a front end plus an external Midjourney proxy

The architecture follows ChatGPT-Next-Web closely. The repository is a Next.js application (next ^14.1.1, react ^18.2.0) with a src-tauri directory for a Tauri desktop build, and the Dockerfile produces a standalone Next.js server that listens on port 3000. Chat traffic goes to whatever BASE_URL points at, with OPENAI_API_KEY as the credential. That part is inherited.

The drawing side is where the design gets interesting, and where the dependency sits. The README is explicit that the Midjourney API interfaces are provided by an open source project or an equivalent, and that before using ChatAny you need to build that service yourself or use a third-party relay platform's API. The named option is trueai-org/midjourney-proxy. ChatAny itself does not talk to Midjourney. It talks to a proxy, configured through two environment variables: MJ_PROXY_URL for the proxy's API address and MJ_PROXY_KEY for its API key.

That split is the whole trade-off. You get a polished front end for Imagine, Upscale, Variation and Vary Region, but the component that actually holds a Midjourney session lives outside this repository. If the proxy is down, misconfigured, or its session expires, the drawing UI has nothing to talk to. The README also lists third-party relay APIs and states plainly that the project makes no guarantee about them. StabilityAI, by contrast, is handled inside the application without a separate service.

The package.json reveals a few more mechanics worth knowing. A build step runs app/masks/build.ts before next build, so the mask editor assets used for Midjourney Vary Region are generated at build time rather than committed. The build script sets BUILD_MODE=standalone, which is what allows the Dockerfile to copy .next/standalone into the runner image.

Installing ChatAny with Docker and making a first drawing

The README gives a single docker run command as the shortest path. It publishes port 3000 and passes the OpenAI key, the API base URL, and the two Midjourney proxy variables. If you leave the Midjourney variables empty, the chat side still works and the drawing side will not have a backend.

docker run -d -p 3000:3000 \
   -e OPENAI_API_KEY="sk-xxx" \
   -e BASE_URL="https://api.openai.com" \
   -e MJ_PROXY_URL="" \
   -e MJ_PROXY_KEY="" \
   licoy/chatany:latest

After the container starts, the web interface is on http://localhost:3000. The README's usage section says that once deployed you click the drawing entry in the upper left and choose the drawing model you want to use. That is the entire documented first-use flow.

The repository also ships a docker-compose.yml with two services, chatgpt-next-web under the no-proxy profile and chatgpt-next-web-proxy under the proxy profile. The Compose file does not document a command line of its own, so the profile names are what you select when starting it.

The proxy service exists for deployments that need outbound traffic routed through PROXY_URL. The Dockerfile installs proxychains-ng and, when PROXY_URL is non-empty, parses the protocol, host and port out of it, writes a strict_chain proxychains configuration, and starts the server under proxychains. When PROXY_URL is empty the container just runs node server.js. That branch is worth reading before you rely on it, because it parses the URL by cutting on delimiters rather than using a URL parser.

For a source build, the README lists npm install, npm run build and npm run start, with npm run dev for development mode. The package.json actually defines these through yarn scripts, and the dev script runs the mask watcher alongside next dev.

The Midjourney proxy dependency is the main reason to look elsewhere

The clearest limitation is stated by the project itself: Midjourney support requires you to stand up trueai-org/midjourney-proxy or buy access from a relay platform. ChatAny contributes the interface, not the capability. If your reason for choosing ChatAny over plain ChatGPT-Next-Web is Midjourney, then most of the operational work happens in a repository you are not reading about here, and the README offers no deployment guidance for it beyond a link.

The second limitation is the maintenance notice. A front end that proxies API keys and accepts user input is exactly the kind of code where you want upstream fixes to keep arriving. The README says they will not. The repository is not archived, so issues and pull requests are not formally closed off, but the maintainers have published a redirect to a different project. Anyone deploying this should treat it as a frozen fork rather than a product.

There are smaller sharp edges. The CODE variable is described as optional and as the access password for the page; leaving it unset means an open instance. Docker deployments that need outbound proxying depend on the shell parsing in the Dockerfile CMD, which assumes a simple protocol://host:port shape for PROXY_URL. And the README does not document rollback, database migrations, or how to move an existing deployment to the successor project, so an upgrade path has to be worked out by the operator.

ChatGPT-Next-Web versus ChatAny: same base, different drawing layer

The honest comparison is with the project ChatAny is forked from. ChatGPT-Next-Web is the upstream, and the README states that ChatAny supports all of its original functionality. If you only need chat, deploying upstream gives you the same interface with a maintainer community that has not published a notice saying it stopped. The environment variables ChatAny inherits (OPENAI_API_KEY, BASE_URL, CODE, OPENAI_ORG_ID, HIDE_USER_API_KEY, DISABLE_GPT4, ENABLE_BALANCE_QUERY, DISABLE_FAST_LINK, OPENAI_SB, GOOGLE_API_KEY) are the upstream ones, which is a good sign for compatibility and a bad sign for differentiation.

What ChatAny adds is the drawing layer: the StabilityAI models and the Midjourney proxy client with Vary Region, reference images and live progress. That is a real addition, and it is the only reason to pick this fork. The difference in approach is not architectural, it is scope: upstream is a chat client, ChatAny is a chat client with an image generation console bolted on, and the bolt is a proxy you have to supply.

A second alternative is the successor the README points at, AQBot, described there as a lightweight cross-platform AI chat and AI gateway desktop client with conversation, web search, conversation compression, multiple models, multiple providers, gateway, knowledge base, memory and MCP. That is a desktop application with a different deployment model, so it is not a drop-in replacement for a web service you host for other people, but it is where the maintainers say the work continues.

Licence, upgrade cost and what a fork actually commits you to

ChatAny is MIT licensed, and package.json declares the license as mit. MIT is permissive: you can use, modify and redistribute the code, including commercially, provided the copyright notice and permission notice are preserved. It ships no warranty. That matters more than usual here, because the README states the project is no longer maintained, so there is no upstream party fixing anything. This is a description of the licence text, not legal advice; if you are deploying this commercially, read the LICENSE file and take your own counsel.

The upgrade cost is the practical question. There is no documented migration path from ChatAny to AQBot, and no documented rollback if a deployment goes wrong. Because the drawing feature depends on an external proxy, upgrading ChatAny would also mean tracking that proxy's API changes independently. The pragmatic posture for a fork like this is to pin the image tag rather than tracking licoy/chatany:latest, keep your configuration in the .env.template that the repository provides, and treat any future change as your own maintenance burden rather than something to wait for.

Editorial conclusion

Adopt ChatAny only if you want the ChatGPT-Next-Web interface plus StabilityAI and Midjourney drawing in one deployment, and you are willing to run code whose README declares the project stopped being maintained. Do not adopt it if you need upstream security fixes, a supported upgrade path, or a working Midjourney integration out of the box: the Midjourney calls go to a separate proxy you must build or buy yourself, and the README does not document rollback or migration. Before deploying, verify three things: that the licoy/chatany image tag you pull is the one you intend, that your Midjourney proxy answers MJ_PROXY_URL with MJ_PROXY_KEY, and that your CODE value is set, because the README describes it as optional and without it the page has no access password.

Frequently asked questions

Official sources

1. ChatAnyTeam/ChatAny on GitHub
2. Issues
3. License: MIT
4. README
5. Releases