How to Run Midjourney on a VPS: A No-GPU Deployment Guide

You can run midjourney on vps hardware for a few dollars a month. The confusion starts when people assume the server needs a GPU, a big power budget, or a data-center rack — because they picture the server generating images. It doesn't. A self-hosted platform submits prompts to Midjourney inside Discord, waits for the results, and hands them to you through your own API. That's orchestration, not inference, and it's why the whole stack fits on a modest cloud box.

This guide covers the VPS part specifically: what the server runs, how to size it, how to deploy it, and what you'll pay. The full self-host midjourney deployment guide covers the end-to-end walkthrough; here we go deep on the machine itself.

Run midjourney on vps: what the server actually does

The mental model that makes everything else click: your VPS is a traffic controller, not a paintbrush. Four pieces run on it:

• Backend + REST API — accepts prompt jobs, returns status, hands back images
• Queue + workers — workers submit jobs upstream to Discord and poll for completion
• Database — jobs, accounts, usage history
• Frontend + admin dashboard — the UI you and your team actually use

None of these need a GPU. The heavy lifting happens inside Midjourney's infrastructure; your server just manages the conversation. This is the same architecture we walk through in the how to build an AI image generation platform breakdown, and it's why a small VPS genuinely works.

Sizing the box: honest numbers

Here's the sizing reality based on what the stack actually consumes — a queue, a database, and some web processes. The numbers below are for a self-hosted platform like Nextjourney with a handful of Midjourney accounts behind it:

The disk is the sneaky one. Images aren't huge individually — mid hundreds of KB to a few MB — but at thousands of images a day they accumulate fast. Budget disk for what you'll cache, and offload finished results to object storage when you cross a few GB. Across this range, expect $20-50/month for a solid provider.

I'll be direct about the GPU question: if a vendor tells you their self-hosted Midjourney platform needs a GPU, they're either running a different kind of product or selling you hardware you don't need. Midjourney's weights are proprietary and not self-hostable; nobody outside Midjourney runs the model on their own hardware. Anyone claiming otherwise is describing a different model entirely.

Picking a VPS provider without overthinking it

Any mainstream provider with a decent reputation works. Focus on four things instead of brand loyalty: reliable networking to Discord (pick a region that routes cleanly to Discord's servers — the one thing you can't fully benchmark from a spec sheet), decent egress bandwidth (you're shipping images out constantly; providers with generous or unmetered egress like Hetzner, DigitalOcean, Vultr, or Linode beat ones that nickel-and-dime per GB), snapshots (restore the whole box in minutes — the cheapest disaster recovery you'll ever buy), and swap on a separate disk (on a 4 GB box, a 2 GB swapfile that doesn't thrash the main disk saves you from OOM kills during queue spikes).

Start with a 2 vCPU / 4 GB box from any of those providers, add the swapfile, and you're in business for under $25/month at most. Upgrade later — that's the entire advantage of renting compute over owning it.

Deploying with Docker Compose

The platform you license (in our case, Nextjourney's source code) ships as containers, so deployment is a single Compose file on a fresh Ubuntu or Debian VPS. The shape looks like this:

services:
  db:
    image: postgres:16
    volumes: ["pgdata:/var/lib/postgresql/data"]
    environment:
      POSTGRES_PASSWORD: "${DB_PASSWORD}"
  redis:
    image: redis:7-alpine
  backend:
    image: nextjourney-backend:latest
    depends_on: [db, redis]
    environment:
      DATABASE_URL: "postgres://nextjourney:${DB_PASSWORD}@db:5432/nextjourney"
      REDIS_URL: "redis://redis:6379"
  worker:
    image: nextjourney-worker:latest
    depends_on: [db, redis]
    environment:
      DATABASE_URL: "postgres://nextjourney:${DB_PASSWORD}@db:5432/nextjourney"
      MJ_ACCOUNTS: "${MJ_ACCOUNTS}"   # account credentials, mounted as secrets
  frontend:
    image: nextjourney-frontend:latest
    ports: ["127.0.0.1:3000:3000"]
  caddy:
    image: caddy:2
    ports: ["80:80", "443:443"]
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile"]
volumes:
  pgdata:

The two production details people skip:

• Frontend binds to loopback, not 0.0.0.0. Caddy terminates TLS on :443 and proxies to 127.0.0.1:3000. Your admin dashboard is never exposed raw to the internet.
• Account credentials come from environment/secrets, never the image or repo. If a worker container gets poked, you don't want Discord tokens sitting in a Docker layer. The midjourney account safety guide covers rotation and handling in depth.

One afternoon covers this whole deploy: DNS record, Compose up, Caddy issues the certificate automatically, and you have an HTTPS API. The rest API structure is the same whether it runs on your laptop or your VPS — which is the point of containerizing.

Backups and monitoring you shouldn't skip

A VPS is a rented computer; treat it accordingly.

• Snapshot weekly (and before every upgrade) — restores the whole box in minutes.
• pg_dump to off-site storage daily — the database holds your jobs, usage, and account mapping. Losing it is losing the platform's memory.
• Uptime check on the API endpoint — the async job model means a stuck queue can look like a healthy server. A synthetic check that submits a job and asserts it completes is worth more than a ping monitor.

The queue is the thing that breaks silently. If workers die, jobs pile up, and the API keeps answering 200 — nothing looks wrong until a customer asks where their image went. Monitor queue depth as a first-class metric, not an afterthought. The automate midjourney guide shows the production pipeline shape you want to replicate.

Scaling past one box

Single-VPS setups are fine into the thousands of images per day. When the box starts complaining — queue latency climbs, disk fills, workers contend — the scaling path is boring and predictable:

1. Move the database and Redis to managed instances — takes the persistence layer off the app server entirely.
2. Split workers onto a second VPS — workers are stateless (they read from the queue), so they scale horizontally for free. That's where the queue design pays off.
3. Add a CDN or object storage in front of image delivery — your app server stops being the download bottleneck.

You don't need Kubernetes for any of this. Two or three VPSes wired together with the same Compose stack will carry a serious production workload. When you've outgrown even that, the image generation architecture deep dive maps the multi-node design.

The monthly math

The recurring cost of running midjourney on vps hardware is small and flat:

Compare that with a reseller charging per image — the cheapest way to use midjourney post does the full math, and the punchline is that a flat monthly cost beats per-image pricing the moment you pass a few thousand images. You also stop depending on a vendor staying in business; the self-host vs API reseller comparison frames that trade-off properly.

The whole trick of running Midjourney on a VPS is remembering your server orchestrates instead of generating. Size for a queue and a database, not a GPU — and you'll spend less on infrastructure than most people spend on coffee.

Not affiliated with Midjourney or Discord.