# trueai-org/midjourney-proxy: A Self-Hosted Midjourney API in C#

> This GPL-3.0 C# service proxies Midjourney's Discord channel behind an HTTP API, with account pools, a management UI and optional face swap. It suits teams that already own Midjourney accounts and want their own endpoint.

**trueai-org/midjourney-proxy** — 🦄 The world's largest Midjourney drawing API, generating over 1 million drawings daily, supporting Discord Youchuan Midjourney 🐂！

- Repository: https://github.com/trueai-org/midjourney-proxy
- Website: https://ai.trueai.org
- Stars: 818 · Forks: 130
- Language: C#
- License: GPL-3.0
- Published: 2026-09-14 · Updated: 2026-09-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/trueai-org-midjourney-proxy

## What midjourney-proxy actually solves for self-hosters

Midjourney has no official public drawing API. You interact with it through Discord, which means a bot token, a channel, message parsing and rate limits. midjourney-proxy sits between your application and that Discord channel and exposes an HTTP surface instead. The README describes it as a project that proxies Midjourney's Discord channel so you can draw through an API, and it also covers Youchuan and the Midjourney website as drawing backends.

The intended user is someone who already holds one or more Midjourney subscriptions and wants to serve them to their own front end, their own customers, or an internal tool. The README points at a set of third-party clients that speak its protocol, including ChatAny, GoAmzAI, ChatGPT Web Midjourney Proxy, GoMaxAI and SparkAI. That client list is the clearest signal of the audience: people who want a ChatGPT-style web UI with Midjourney drawing attached, without writing the Discord layer themselves.

The project also runs a public instance. The README lists a management backend at ai.trueai.org, a free endpoint at ai.trueai.org/mj and Swagger docs at ai.trueai.org/swagger, all with no account or key required. That free tier is explicitly slow mode and backed by donated accounts. Treat it as a way to see the API shape, not as infrastructure.

## How the proxy talks to Discord and to your clients

The architecture is a pool of Discord accounts behind one HTTP API. Each configured account connects over the Discord gateway, and the README notes user-token connections use wss so the service can receive error messages and the full set of features. It also mentions zlib-stream compression for that gateway traffic, which is a Discord transport detail rather than something the project invented.

On top of the pool sits a task queue. The README lists account selection modes BestWaitIdle, Random, Weight and Polling, and says each account can have its own task queue plus settings for concurrency, queue size, maximum queue size and interval between tasks. The account pool is persisted and maintained dynamically, so restarts do not lose the roster.

Client requests arrive as Midjourney-style submissions. The README gives the default path shape as https://{BASE_URL}/mj/submit/imagine, with /mj-turbo/mj, /mj-relax/mj and /mj-fast/mj selecting speed modes, and plain /mj meaning no mode is forced. That path-based mode selection is a design choice worth noticing: it lets a client pick fast or relax per request without extra parameters, but it also means your routing and any reverse-proxy rules have to preserve those prefixes.

Storage is pluggable. The README lists a local database, MongoDB, Sqlite, MySQL/MariaDB, SqlServer and PostgreSQL, and suggests MongoDB once task data exceeds roughly 100,000 rows, with a default retention of about one million records and automatic data migration. Image storage is separate again: local disk, Alibaba Cloud OSS, Tencent Cloud storage, S3 and Cloudflare R2 are all listed.

## Installing midjourney-proxy with Docker and submitting a first imagine

The README's quick start is a Docker path with a one-shot upgrade script. It warns that the official image needs more memory and that a server should have at least 2GB, and it says the default port is 8086. The first command downloads the script and runs it; the script itself can be edited before running to change paths, ports and memory settings.

```bash
wget -O docker-upgrade.sh https://raw.githubusercontent.com/trueai-org/midjourney-proxy/main/scripts/docker-upgrade.sh && bash docker-upgrade.sh
```

After that, the README says later upgrades use the same script, invoked with sh. It notes the script is the recommended upgrade path and that file and path mappings must be correct, which is the usual place a self-hosted deployment breaks.

```bash
sh docker-upgrade.sh
```

Once the service is up, the README points to a management backend and a Swagger page for the API surface. On the public instance those are at ai.trueai.org and ai.trueai.org/swagger. For your own deployment they sit on the host and port you configured, 8086 by default. The README also says the embedded management UI is a separate project, trueai-org/midjourney-proxy-webui, and that it supports multiple languages, account CRUD, account synchronization, per-account concurrency queues, account settings and task queries.

For a first real call, the README's own path example is the contract: imagine submissions go to /mj/submit/imagine on your base URL. If you want fast mode for that request, the README says the prefix /mj-fast/mj selects it, /mj-relax/mj selects relax and /mj-turbo/mj selects turbo. The README does not print a full request body in the section available here, so read the Swagger page for the exact fields before wiring a client. Windows users get a separate path: the README says the Windows platform can be downloaded and started directly, with details in the linked documentation.

## Account banning, CloudFlare checks and the operational cost nobody budgets for

The honest limitation is that this project depends entirely on Discord accounts that Midjourney can suspend. The README addresses this directly in two features. The first is shared or sub-channel drawing: if an account is banned, the README says you can keep drawing by making the banned account's channel a sub-channel of a working account, saving a permanent invite link and a sub-channel link, with batch editing supported. That is a workaround, not immunity.

The second is CloudFlare human verification. The README lists manual verification that locks the account when triggered, with verification through the GUI or an email notification, plus an automatic verifier that requires a verification server address and, per the README, only works on Windows deployments. That Windows-only constraint is a real deployment problem if the rest of your stack is Linux containers.

There is also a scheduling concern the README raises on its own: drawing continuously for 24 hours may trigger a warning, and it suggests resting 8 to 10 hours. It offers a work time range configuration with an example of 09:10-23:55, 13:00-08:10. A service that needs scheduled rest periods to stay in Midjourney's good graces is not a service you can promise 24/7 capacity on.

Finally, the README warns private deployments to disable demo mode, registration and guest access so the API is not abused. That is a direct statement that a misconfigured instance is an open drawing endpoint on your Midjourney subscription. It also lists IP rate limiting, IP range limiting, blacklists, whitelists and automatic blacklisting, plus a daily drawing cap after which new imagine tasks stop while variations and redraws continue.

## How it compares with building on the Midjourney Discord bot directly

The alternative most teams consider is talking to the Midjourney bot over Discord themselves: one bot token, one channel, your own message parser. The difference in approach is where the state lives. A direct integration keeps account state and task state in your code, so you control retries, queueing and persistence exactly. midjourney-proxy moves that state into a separate service with its own database, its own queue per account and its own account selection strategy.

That trade favors you when you have several accounts and want load spread across them without writing a scheduler, or when you want an existing client to work unchanged. It works against you when you have one account and a simple pipeline, because you now run a service, a database and a management UI to do what a few hundred lines of bot code could do. The README's own feature list is the evidence for that weight: Consul configuration center support, distributed deployment, elastic deployment and load balancing are all listed, and none of them are free operationally.

A second alternative is a commercial Midjourney API reseller. The README links several service providers and its own enterprise endpoints at huanwangai.com and api.huanwangai.com. The difference is who holds the accounts and the risk. A reseller absorbs bans and verification for you and charges for it; self-hosting keeps the accounts and the failure modes on your side, which is the entire point of this project.

## Licence, upgrade cadence and what running this costs you

The repository is GPL-3.0. That matters if you plan to distribute a product that links to or embeds this service, because GPL-3.0 carries source disclosure obligations for derivative works. Running it as a separate network service behind your own application is a different situation from shipping it inside a product, and the boundary is a legal question rather than a technical one. If your business depends on the answer, get it reviewed rather than deciding from a README.

The upgrade story is unusually concrete. The README calls the Docker upgrade script the recommended path and says future upgrades only need that script, and it lists online upgrade and online restart as features. There is also a migration feature that the README says can move accounts and tasks from mjplus or another service in one step.

Maintenance looks current: the last push was on 2026-09-10, and the most recent release listed is v11.11.1 on the same date, following v11.11.0 on 2026-09-01 and v11.10.4 on 2026-08-10. That is roughly a release every few weeks. The cost side is not just the server: you need Midjourney subscriptions for the accounts in the pool, at least 2GB of memory for the official image, and a storage decision. The README suggests MongoDB past about 100,000 task rows, so a busy instance adds a database to operate. If you also enable face swap for images and video, the README attaches a legal warning to both features, which is a reminder that the feature set extends past drawing.

## Conclusion

Adopt it if you already pay for Midjourney accounts and want your own HTTP endpoint with a management UI, account pooling and a Docker upgrade script you control. Do not adopt it if you want a hosted service with an SLA, or if GPL-3.0 obligations do not fit how you distribute your product. Before committing, verify three things against your own deployment: that your Discord accounts survive the login flow, that your task volume fits the storage backend you pick, and that the public demo endpoints stay reachable, since the README notes the free auto-login verifier is currently suspended after attacks.

## FAQ

### What is trueai-org/midjourney-proxy?

It is a C# service that proxies Midjourney's Discord channel and exposes an HTTP API for drawing, with support for Discord, Youchuan and Midjourney website drawing. The README describes it as a public welfare project with a free drawing API, and it also ships a management backend and Swagger docs.

### How do I deploy midjourney-proxy with Docker?

The README's quick start downloads scripts/docker-upgrade.sh with wget and runs it with bash, then uses the same script with sh for later upgrades. It notes the official image needs at least 2GB of memory and that the default port is 8086.

### Does midjourney-proxy need a Midjourney subscription?

The service proxies Midjourney's Discord channel using configured Discord accounts, so it depends on accounts that have access to Midjourney. The README also lists a free public endpoint backed by donated accounts in slow mode, but that is a demo rather than your own capacity.

### What happens if a Midjourney account gets banned?

The README describes a shared or sub-channel feature: you can make the banned account's channel a sub-channel of a working account, keep the permanent invite link and sub-channel link, and continue drawing. It is a mitigation, and the CloudFlare verification features exist for the related problem of human checks.

### Which database should I use for midjourney-proxy?

The README lists a local database, MongoDB, Sqlite, MySQL/MariaDB, SqlServer and PostgreSQL, and recommends MongoDB once task data exceeds about 100,000 rows, with a default retention around one million records and automatic data migration.

## Sources

- [License: GPL-3.0](https://github.com/trueai-org/midjourney-proxy/blob/main/LICENSE)
- [Project website](https://ai.trueai.org)
- [README](https://github.com/trueai-org/midjourney-proxy/blob/main/README.md)
- [Releases](https://github.com/trueai-org/midjourney-proxy/releases)
- [trueai-org/midjourney-proxy on GitHub](https://github.com/trueai-org/midjourney-proxy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trueai-org-midjourney-proxy