Plane is an open-source project management platform in the same category as Jira and Linear. Its self-hosted Community Edition is heavier than its interface suggests, and sizing a VPS by guesswork is the most common way a Plane install fails.
The Documented Requirements
Plane’s own self-hosting documentation states:
| Resource | Requirement |
|---|---|
| CPU | 2 cores (x64/AMD64 or AArch64/ARM64) |
| RAM | 4 GB minimum, 8 GB recommended for production |
| OS | Ubuntu, Debian, CentOS, Amazon Linux 2 or 2023 |
| Runtime | Docker Engine 20.10+, Docker Compose v2 |
| Network | Ports 80 and 443, plus a resolving domain |
Why the 4 GB Floor Is Real
Plane is not one process. The Community Edition compose stack starts thirteen containers:
- Application:
web,admin,spaceandlivefrontends, plus the Djangoapi - Background:
worker,beat-workerandmigrator - Data:
postgres:15.7-alpine,valkey/valkey:7.2.11-alpine,rabbitmq:3.13.6-management-alpine,minio/minio - Edge: the
proxycontainer that owns ports 80 and 443
Thirteen containers idling consume most of 4 GB before a single issue is created. This is why 1 GB and 2 GB plans do not work - not because Plane is inefficient, but because you are running a database, a message broker, a cache and an object store alongside the app itself.
RAM: Sizing by Team Size
| Scenario | RAM | Notes |
|---|---|---|
| Evaluation or a 2-5 person team | 4 GB | The documented minimum; workable but with little headroom |
| 5-30 people using Plane daily | 8 GB | The documented production recommendation |
| Large Jira migration in progress | 8 GB+ | Bulk imports are memory-hungry, though only briefly |
If you are between sizes, take the larger one. Plane’s failure mode on insufficient memory is the kernel killing a container mid-request, which looks like random errors rather than an obvious out-of-memory message.
CPU: Two Cores Is Genuinely Enough
Issue tracking is bursty. Someone opens a board, the API answers, and the server goes quiet again. Two vCPU handles that comfortably for a normal team.
Four cores earn their keep in one specific case: importing an existing backlog. During a bulk import the Django API, the Celery worker and PostgreSQL all compete, and the job finishes materially faster with more cores. That is a one-off, so it is rarely worth paying for permanently - unless the plan with 4 cores also happens to be the plan with 8 GB, which at Contabo it is.
Storage: Watch MinIO, Not Postgres
The database stays small. Issues, comments and activity records are text, and even a busy team’s Postgres volume grows slowly.
Attachments are the variable. Every screenshot and document uploaded to an issue lands in the MinIO volume, and teams that paste screenshots liberally will outgrow a 40 GB disk long before the database matters.
Start at 40 GB, monitor the MinIO volume, and prefer NVMe or SSD - PostgreSQL’s performance is I/O-bound and the difference is noticeable on board views that aggregate a lot of issues.
VPS Plans That Match These Requirements
| Provider | Plan | vCPU / RAM / Disk | Price | Verdict | Link |
|---|---|---|---|---|---|
| Contabo | Cloud VPS 4 | 4 / 8 GB / 100 GB SSD | 5.50 EUR/mo net | Meets the 8 GB production recommendation | Contabo |
| Hetzner Cloud | CX23 | 2 / 4 GB / 40 GB NVMe | 5.49 EUR/mo net | Meets the minimum; CX33 at 8.49 for 8 GB | Hetzner |
| DigitalOcean | Basic 4 GB | 2 / 4 GB / 80 GB SSD | 24 USD/mo | Meets the minimum; best snapshot tooling | DigitalOcean |
| Vultr | Regular 4 GB | 2 / 4 GB / 80 GB SSD | 20 USD/mo | Meets the minimum; widest region choice | Vultr |
| Linode | Linode 4 GB | 2 / 4 GB / 80 GB SSD | 24 USD/mo | Meets the minimum; predictable performance | Linode |
Every provider’s 1 GB entry plan is excluded on purpose. Those plans sit below Plane’s documented minimum and no amount of tuning changes that.
A Note on Building From Source
The docker-compose.yml in Plane’s GitHub repository builds each service from its Dockerfile rather than pulling published images. Compiling the Next.js frontends needs considerably more memory than running them does, and the build will thrash or fail outright on a 4 GB VPS.
The supported path pulls prebuilt images:
curl -fsSL https://prime.plane.so/install/ | sh -Size the server for running Plane, not for building it.
Planning for Growth
- Monitor with
docker statsbefore deciding to resize; it shows which container is actually under pressure. - Snapshot the VPS before every version upgrade - the
migratorcontainer applies schema changes on start. - Back up the PostgreSQL volume and the MinIO volume together. Either one alone restores an incomplete instance.
- Most providers resize memory in place, so starting at 4 GB and moving to 8 GB later is a reboot rather than a migration.
For a broader look at plans across providers, see our full VPS comparison.
Community references worth following: the awesome-selfhosted list and the r/selfhosted subreddit.
Frequently asked questions
How much RAM does a self-hosted Plane instance really need?
The official minimum is 4 GB and the documented production recommendation is 8 GB. The Community Edition runs thirteen containers, including PostgreSQL, Valkey, RabbitMQ and MinIO, and those alone occupy most of 4 GB before anyone signs in. Use 4 GB for a small team or a trial, and 8 GB once Plane is the tracker your team opens every morning.
How many CPU cores does Plane require?
Two cores is the documented minimum, on either x64/AMD64 or AArch64/ARM64. Two is adequate for day-to-day issue tracking because the load is bursty rather than sustained. Four cores are worth having if you plan to import a large backlog from Jira, since the Django API and the background workers compete for CPU during bulk operations.
How much disk space should I allocate for Plane?
Start at 40 GB and plan for growth. The PostgreSQL database itself stays modest, but MinIO stores every file attachment uploaded to an issue, and that volume is what fills a disk. Screenshots and documents attached to tickets accumulate steadily, so watch the MinIO volume rather than the database when deciding whether to resize.