You've decided to self-host instead of renting per-image access from a reseller. Good call, but "self host midjourney" sounds simple and isn't — there's a server to pick, code to install, accounts to connect, and a queue to keep alive. This guide walks through the whole deployment so you know exactly what you're signing up for before you buy anything.
The short version: to self host midjourney you deploy a platform that talks to Discord on your behalf, connect your own Midjourney accounts, and call your own API. It's a few hours of work, and the recurring cost is a VPS plus your Midjourney subscriptions — no per-image fees. Here's the full path.
Nextjourney is not affiliated with Midjourney or Discord. There is no official Midjourney API — Midjourney has no public API, so every integration, including this one, automates Discord user accounts. That operates outside Discord's Terms of Service, and it applies equally to resellers and self-hosted platforms.
Self host midjourney: what you're actually deploying
A self-hosted image generation platform is four pieces of software running on your own server:
- Backend — receives API requests, manages a job queue, and talks to Discord on your behalf.
- Frontend — the UI your users (or you) see to submit prompts and browse results.
- REST API — the interface your application calls to generate images programmatically.
- Admin dashboard — where you manage accounts, API keys, and usage.
The important mental shift: your server does not generate images. Midjourney does, inside Discord. Your server orchestrates — it submits prompts, waits for results, and hands them back through your API. That's why you don't need a GPU, and it's why the whole thing runs on a small VPS.
Hardware and prerequisites
The platform itself is lightweight. Realistic minimum:
| Requirement | Minimum | Comfortable |
|---|---|---|
| CPU | 1 vCPU | 2 vCPU |
| RAM | 2 GB | 4 GB |
| Storage | 20 GB SSD | 40 GB SSD |
| OS | Ubuntu 22.04 / Debian 12 | Same |
| Docker | Docker Engine + Compose | Same |
You'll also want a domain pointing at the server if you want HTTPS on your API — which you do, because browsers and mobile apps will refuse plain HTTP. A $5-10/year domain is fine. No GPU, no special networking, no bare-metal server. A $20-50/month VPS handles normal workloads comfortably.
The deployment, step by step
The install is a Docker Compose flow — the standard way to run this kind of stack. One command brings up the backend, frontend, and admin dashboard together.
# 1. Pull the source code onto the server
cd /opt && git clone <your-source-repo> nextjourney && cd nextjourney
# 2. Configure environment variables
cp .env.example .env
# edit .env: set DOMAIN, database credentials, JWT secret, API keys
# 3. Start the stack
docker compose up -d
# 4. Verify containers are healthy
docker compose ps
After that, the API and dashboard are live. Set up a reverse proxy (Caddy or Nginx) to terminate TLS and forward traffic to the app's port, then point your domain's A record at the server. Caddy is the low-friction option — it auto-provisions certificates:
yourdomain.com {
reverse_proxy localhost:8080
}
That's the entire install. Most of the time goes into configuration, not deployment.
Connect your Midjourney accounts
The platform needs access to Midjourney accounts to generate images. You log into each account in the admin dashboard once, the platform stores the session, and from then on it routes jobs through that account.
Two practical rules for keeping accounts alive:
- Don't hammer one account. Midjourney has rate limits, and aggressive parallel jobs from a single account are the fastest way to get it flagged. Keep concurrency per account low.
- Rotate across accounts. More accounts = more parallel capacity. A platform with multi-account support spreads the queue across them automatically; you just add accounts and set per-account limits.
If you plan to run this for clients, you'll also want per-client isolation — separate account pools per tenant, usage limits, and branded access. That's the difference between a personal setup and a business one.
First request: prove it works
Once the stack is up and an account is connected, fire your first request:
curl -X POST https://yourdomain.com/api/generate \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"prompt": "a red fox in snow, golden hour, photorealistic"}'
You get back a job ID, then poll for the result:
curl https://yourdomain.com/api/jobs/JOB_ID \
-H "Authorization: Bearer YOUR_API_KEY"
The exact endpoint names ship in the included API docs — the shape above is the standard pattern (submit → poll → fetch). A good platform also supports webhooks so you don't have to poll.
What it costs to run
The honest cost picture, per month, for a small setup:
| Line item | Cost |
|---|---|
| VPS (2 vCPU / 4 GB) | $20-50/month |
| Midjourney Standard ($30) × 2 accounts | $60/month |
| One-time platform license | $399 (self-install) or $1,499 (agency) |
| Recurring total | ~$80-110/month |
Compare that with a reseller charging $0.02/image: at 10,000 images a month that's $200 — every month, forever. The self-host vs API reseller comparison works the breakeven math in detail; the short version is that ownership wins once you're past prototype scale. And unlike a reseller, the code keeps running if any vendor shuts down — you own it.
Ready to self-host?
Full source code — backend, frontend, REST API, admin dashboard. One-time license from $399, no recurring platform fees.
See pricingCommon deployment mistakes to skip
Three things trip people up on the first deploy:
- Skipping the reverse proxy. The API works without TLS, but production integrations will fail on mixed content. Configure HTTPS before wiring up your app.
- One account for everything. A single Midjourney account caps your parallelism and is a single point of failure. Add accounts as you scale — the platform's queue handles the distribution.
- No monitoring. Set a basic uptime check on the API and keep an eye on the queue. Image generation is asynchronous; a stuck queue looks like a healthy server.
Run it, generate a few hundred images through it, and you'll know within a week whether the setup matches your workload. That's the real test — not the install, which is the easy part.