Dooy/chatgpt-web-midjourney-proxy: One Vue Front End for ChatGPT and a Dozen Image, Video and Music APIs

What the project actually stitches together

This is a second development pass on Chanzhaoyu's chatgpt-web, with midjourney-proxy, Suno-API and Luma-API wired in as backends. The README states that plainly, and it matters more than any feature list, because it tells you where the boundaries are. The chat half is a ChatGPT front end: custom API key and base URL, model selection, context length, image upload for vision models, GPTs, TTS, Whisper and DALL-E 3. The generation half is a control panel for other people's services. Midjourney gets text-to-image, image prompting, U1 to U4 and V1 to V4 variations, inpainting, 1.5x and 2x zoom, 2x and 4x upscaling, panning in four directions, blend, seed retrieval and image-to-text. Around that sit Suno and udio for music, Luma, Runway, Pika and Kling for video, Viggle for dance, Flux and Ideogram for images.

The intended user is someone who already has API access to those services and wants a single interface instead of a dozen tabs. It is not aimed at people who want to type a prompt and get a picture without configuring anything.

How the front end talks to Midjourney and the video APIs

The architecture is a Vue 3 single-page app built with Vite, using naive-ui for components and pinia for state. It has no database of its own. Every generation request leaves the browser and hits an HTTP endpoint that you configure through environment variables: MJ_SERVER with MJ_API_SECRET for Midjourney, SUNO_SERVER with SUNO_KEY for music, LUMA_SERVER with LUMA_KEY for video. The README notes that both midjourney-proxy and midjourney-proxy-plus interfaces are supported, which is the practical detail that decides whether your existing proxy works unchanged.

Images are stored client-side. The README says localforage handles local storage of generated images, so the gallery lives in the browser rather than on the server. That keeps deployment simple and makes the gallery per-browser, which is either convenient or a problem depending on whether you expect to see the same history on your laptop and your phone. For server-side storage there is a separate uploader path, described below.

Installing it with Docker and running a first Midjourney prompt

The README offers three routes: a Vercel one-click deploy, a desktop build from the GitHub releases page, and Docker. The Docker command below is copied from the README. It maps container port 3002 to host port 6015 and expects a running midjourney-proxy, a Suno API and a Luma API to point at.

docker run --name chatgpt-web-midjourney-proxy  -d -p 6015:3002 \
-e OPENAI_API_KEY=sk-xxxxx \
-e OPENAI_API_BASE_URL=https://api.openai.com  \
-e MJ_SERVER=https://your-mj-server:6013  \
-e MJ_API_SECRET=your-mj-api-secret  \
-e LUMA_SERVER=https://your-luma-server:8000  \
-e LUMA_KEY=your-luma-key  \
-e SUNO_SERVER=https://your-suno-server:8000  \
-e SUNO_KEY=you-suno-key  ydlhero/chatgpt-web-midjourney-proxy

After the container starts, the README says to visit http://ip:6015. You should see the chat interface; the Midjourney, music and video menus appear in the navigation and will fail on request if the corresponding server variables are wrong or the backends are unreachable.

If you want uploads to land on the server instead of going through the front end, the README gives a second run with a mounted volume and API_UPLOADER enabled:

docker run --name chatgpt-web-midjourney-proxy  -d -p 6015:3002 \
-e OPENAI_API_KEY=sk-xxxxx \
-e OPENAI_API_BASE_URL=https://api.openai.com  \
-e MJ_SERVER=https://172.17.0.1:6013  \
-e API_UPLOADER=1  -v /data/uploads:/app/uploads \
-e MJ_API_SECRET=abc123456  ydlhero/chatgpt-web-midjourney-proxy

The README also documents the uploader contract: a POST to OPENAI_API_BASE_URL/v1/upload with a multipart file field, returning JSON with a url key. That is the interface any replacement uploader has to satisfy.

For a source build, package.json shows the script names. The Dockerfile installs pnpm 10.33.2 globally and runs pnpm install followed by pnpm run build for the front end, and a separate build inside /service for the backend, with the final image exposing 3002 and starting pnpm run prod.

Where it stops being the right tool

The dependency chain is the main limitation, and the README does not hide it. Docker deployment lists requirements: midjourney-proxy or trueai's proxy, Suno-API, and Luma-API. Without those, the Midjourney, music and video sections are empty shells. The chat side is more forgiving because any OpenAI-compatible endpoint works through OPENAI_API_BASE_URL, but the generation side is not.

Authentication is uneven across deployment targets. AUTH_SECRET_KEY, the access password, is marked as available for Docker and other deployments but not for Vercel. The same table marks API_UPLOADER, HIDE_SERVER and the brute-force counters AUTH_SECRET_ERROR_COUNT and AUTH_SECRET_ERROR_TIME as unavailable on Vercel. If you deploy to Vercel and need a password gate, you are relying on something else in front of the app. The README also warns twice, in the context of passing settings through URL fragments, that this method should use your own domain for security reasons.

There is also a maintenance surface that is easy to underestimate. Each integrated service has its own API shape, and the project tracks several of them in one codebase. Version 2.26.5 landed on 2026-05-08 and 2.26.6 on 2026-09-14, so the release rhythm is not uniform across the year. The last push was on 2026-09-16 and the repository is not archived.

Compared with running the proxies directly

The obvious alternative is to use the upstream projects on their own: novicezk's midjourney-proxy exposes an HTTP API and, depending on the fork, its own admin panel, and Suno-API and Luma-API do the same for their services. That approach gives you raw endpoints and no unified UI. You would generate images by calling the API or through whatever minimal interface the proxy ships, and you would keep chat separate.

This project's difference is aggregation and presentation. It puts Midjourney operations behind buttons (variation, zoom, pan, inpaint), renders Suno with lyric and style adjustment, and keeps the chat, gallery and generation views in one Vue app that also builds as a PWA and a Tauri desktop binary. The cost of that convenience is an extra moving part: the front end depends on the proxy, and when the proxy changes its response shape, the UI is the thing that breaks. If your team is comfortable with curl and a proxy's own panel, the aggregation buys you less than it costs.

Licence, upgrades and what a fork owes upstream

The repository is MIT licensed, and the README repeats that the project is free, published only on GitHub, and will not run paid services, account sales or discussion groups. MIT means you can fork, rebrand and deploy commercially, provided you keep the licence notice. It does not grant you rights to the upstream services: midjourney-proxy, Suno-API, Luma-API and the model providers have their own terms, and your use of Midjourney through a proxy is governed by those, not by this repository's licence.

Upgrade cost is mostly configuration drift. The env table in the README is long and has grown with each integration, so a deployment configured a year ago may be missing variables such as VISION_MODEL, CUSTOM_VISION_MODELS, MENU_DISABLE or UPLOAD_TYPE. The container image tag in the README is ydlhero/chatgpt-web-midjourney-proxy with no version pin, so a pull can move you across releases. If you need reproducibility, pin the image digest yourself; the README does not document a rollback procedure.

Editorial conclusion

Adopt it if you already run midjourney-proxy or a relay that exposes the same endpoints, and you want one browser UI for chat, image, video and music generation. Do not adopt it if you expect a self-contained product: without MJ_SERVER, SUNO_SERVER and LUMA_SERVER the corresponding menus have nothing to talk to. Before committing, verify that your relay implements the midjourney-proxy interface, decide whether you need AUTH_SECRET_KEY (it is unavailable on Vercel deployments), and check whether the built-in localforage image store is enough for your gallery or whether you need API_UPLOADER with a mounted volume.

Frequently asked questions

Official sources

1. Dooy/chatgpt-web-midjourney-proxy on GitHub
2. License: MIT
3. Project website
4. README
5. Releases