We get the same ticket every few weeks: a community manager migrating a Discord server or a Facebook Group into a real forum, asking us why their brand-new Discourse install is swapping itself into oblivion on a cut-rate shared VPS from some other host. Discourse is not WordPress. It runs as a Docker container that packs a full Rails app, Postgres, Redis, and a Sidekiq job queue inside it, and it will happily eat every megabyte of RAM you hand it. This is our sizing guide for discourse forum vps hosting, written from the rack side of things — what actually breaks, what tier to buy, and when to stop renting a VPS and start renting a box.
Why Discourse Is Not a Typical CMS Deploy
Most CMS platforms — Ghost, WordPress, a static site generator — run as a single lightweight process and idle at 100-300MB of RAM. Discourse ships as one Docker container, built and managed through Discourse's official `./launcher` script, but that single container supervises the entire stack internally: Postgres, Redis, the Sidekiq job queue, and the Rails app's Puma/Unicorn workers all run together inside it. It isn't a docker-compose setup with a separate container per service — it's one container doing the work of five, which is exactly why it needs so much more RAM than a typical single-process CMS. The asset precompilation step that runs during install (`./launcher bootstrap app`) and every upgrade (`./launcher rebuild app`) is genuinely CPU- and RAM-intensive — it's the step that OOM-kills half-provisioned VPS instances before the forum ever loads.
That's the core sizing lesson: Discourse's own documentation puts the floor at roughly 2GB RAM minimum just to get the installer through a clean build. Below that, you're not deploying a forum, you're watching the bootstrap process get killed mid-build.
Choosing the Right Discourse Forum VPS Hosting Tier
We size Discourse installs against community activity, not registered-user counts — a forum with 10,000 dormant accounts and 200 daily active members needs less horsepower than a scrappy 500-member community that's active all day. Here's how we map that against our own tiers on our VPS hosting plans:
| Community stage | Recommended tier | Specs | Notes |
|---|---|---|---|
| Small / early-stage (under ~500 members) | VPS II | 4GB RAM / 2 vCPU / 80GB NVMe — EUR6/mo | Clears Discourse's 2GB floor with headroom for Postgres + Sidekiq; fine for a first install or a Discord-to-Discourse pilot |
| Growing / active daily community | VPS III or IV | 8GB RAM / 2 vCPU / 120GB NVMe — EUR10-16/mo | Our default recommendation once a forum has real daily posting activity — the extra RAM goes straight to Postgres shared buffers and Redis, not just headroom |
| Large / media-heavy community | VPS V | 16GB RAM / 4 vCPU / 200GB NVMe — EUR30/mo | Needed once uploads (images, attachments) and full-text search indexing start competing with the app for memory |
| Very large / highest-traffic | VPS VI | 32GB RAM / 6 vCPU / 400GB NVMe — EUR58/mo | Top of our VPS line — past this, the conversation shifts to dedicated hardware (see below) |
Docker needs root access to run its container and networking layer cleanly, so root SSH is non-negotiable — every tier we sell ships with it by default, along with NVMe storage under every VM.
What Actually Consumes the RAM
If you're used to sizing a VPS for a CMS or a Node app, Discourse's memory map will surprise you:
- Postgres — Discourse tunes shared_buffers and work_mem aggressively out of the box; this is usually the single biggest consumer on a small install.
- Redis — backs sessions, caching, and the Sidekiq job queue; grows with concurrent active users.
- Sidekiq workers — process email digests, notification fan-out, and search reindexing; spikes hard during bulk imports or CSV migrations from Discord/Facebook exports.
- Puma/Unicorn app workers — the Rails app itself, spun up as multiple workers depending on CPU core count, which is why vCPU count matters as much as RAM once you're past the small tier.
- The asset build step — a temporary but very real RAM spike during install and every `./launcher rebuild app` upgrade; this is the step that kills undersized installs, not steady-state traffic.
Bandwidth, Uploads, and the Migration Itself
Communities moving off Discord or Facebook Groups tend to bring years of image and file uploads with them, and the initial import can be a genuinely large one-time transfer. Every VPS tier we sell runs on 1 Gbps unmetered symmetric bandwidth, so a multi-gigabyte Discourse import — or the ongoing traffic from an active image-heavy forum — doesn't run into a bandwidth cap partway through. Combined with hourly billing to the second, this also means you can spin up a larger tier just for the migration window and scale back down once the import job finishes, rather than committing to peak capacity for the life of the forum.
The Signal for Moving to Dedicated
We tell people to stop scaling VPS tiers and start looking at dedicated hardware when one of these shows up consistently, not just on a bad day:
- Sidekiq queue depth stays elevated during normal hours, not just during digest sends or reindex jobs
- Postgres query latency creeps up under concurrent active users even after tuning shared_buffers
- The forum has grown into a broader community platform — chat plugins, heavy attachment libraries, embedded media — that behaves more like a small SaaS product than a simple forum
- You're running Discourse alongside other production workloads (a companion app, a member portal) that shouldn't share a noisy-neighbor VM
At that point the calculation is less about squeezing another gigabyte out of a VPS tier and more about dedicated CPU cores, isolated I/O, and headroom that doesn't get contended by anything else. It's the same threshold we apply to any resource-heavy self-hosted app that outgrows a VPS — Discourse at scale is, operationally, a small application platform, not a static site.
How Noded Can Help
We run Discourse forums the same way we run everything else on our network: NVMe under every VM, root SSH so Docker behaves the way it's supposed to, and 1 Gbps unmetered bandwidth so an import job or a traffic spike from a new members-only launch doesn't hit a wall. If you're moving a community off Discord or Facebook Groups, our advice is to start on VPS III or IV, watch memory and Sidekiq queue depth for the first few weeks of real traffic, and scale up — or across to dedicated — from there. Every plan also ships with free DDoS protection, so a forum that gets linked from somewhere big doesn't take the rest of your infrastructure down with it. Our VPS hosting plans page has the full tier breakdown if you want the broader picture before picking one.
FAQ
How much RAM does Discourse actually need to run?
Discourse's official installer requires roughly 2GB RAM as a hard minimum to get through the Docker build and asset compilation step. In practice, for a real community with Postgres, Redis, and Sidekiq all running steady-state, we recommend starting at 4GB and moving to 8GB once the forum has daily active posting.
Can I self-host Discourse in Europe on a VPS instead of using their hosted plan?
Yes — Discourse's official Docker install works on any VPS with root SSH and Docker support. To self-host Discourse in Europe, you just need a tier that clears the RAM floor and enough NVMe storage for uploads and Postgres data; our VPS hosting plans cover the full range from a small pilot forum up to a media-heavy community.
What are the real Discourse VPS requirements beyond RAM?
Root SSH access (Discourse's launcher script needs it to manage its Docker container), NVMe storage for Postgres I/O performance, and at least 2 vCPUs once the forum has concurrent active users — the app workers, Sidekiq, and Postgres all compete for CPU time during busy periods, not just RAM.
Will a bulk import from Discord or Facebook Groups overload a small VPS?
It can, temporarily — imports spike Sidekiq job processing and Postgres write load well above normal daily traffic. Because our billing is hourly to the second, a practical approach is to run the import on a larger tier and scale back down to your steady-state tier once it's done.
When should a Discourse forum move from VPS to a dedicated server?
When Sidekiq queue depth or Postgres latency stay elevated during normal (not peak) hours even after tuning, or when the forum runs alongside other production workloads that shouldn't share a VM's resources. At that point, isolated CPU and I/O on a dedicated server is the more predictable fix than another VPS tier bump.