What self-hosted project management actually costs to run

Wrote at May 16, 2026

Every self-hosted project management tool promises easy deployment. "One command and you're done." But what they don't mention is the stack that command spins up behind the scenes. PostgreSQL, Redis, RabbitMQ, S3-compatible storage. Each service needs memory, maintenance and monitoring. The real cost of self-hosting isn't the license. It's the infrastructure.

Self-hosted project management requirements refer to the hardware, software and services needed to run a project management tool on your own server. This includes the database engine, caching layer, message queue, object storage, RAM and CPU. These requirements vary widely between tools, from multi-service stacks needing 16 GB of RAM to single-container setups that run on 1 GB.

TL;DR: Most self-hosted project management tools need PostgreSQL, Redis and 4-16 GB of RAM. Eigenfocus runs on Docker with SQLite and needs around 1 GB. Before picking a tool, check what it actually takes to keep it running.

What do self-hosted project management requirements look like in practice?

When you self-host, you take responsibility for everything the tool needs to run. That means the application itself, plus every supporting service it depends on: the database, the cache, the message broker, the file storage.

Some tools keep this simple. One container, one database file. Others need a full production stack with four or five services running at the same time, each consuming memory and requiring its own configuration and updates.

The gap between "easy to install" and "easy to run" is where most people get surprised. A tool might install in five minutes but quietly require 8 GB of RAM and a PostgreSQL server that needs regular vacuuming, backups and version upgrades.

Let's look at what the popular options actually require.

How much infrastructure does Plane need?

Plane is one of the most popular self-hosted project management tools. It positions itself as a modern Jira alternative with a clean UI and strong feature set. But the infrastructure requirements are substantial.

Plane's self-hosted stack includes:

  • PostgreSQL 15.7+ for the primary database
  • Redis/Valkey for caching and session storage
  • RabbitMQ for asynchronous task processing (imports, exports, notifications)
  • MinIO or S3-compatible storage for file uploads and attachments
  • Multiple application containers (web, API, worker, beat scheduler)

For minimum deployments, Plane recommends 2 CPU cores and 4 GB of RAM. For production use, they recommend 4+ CPU cores and 16 GB of RAM.

That's a lot of moving parts. Each service needs to stay healthy, get updated and be backed up separately. PostgreSQL alone requires periodic maintenance: vacuuming, index tuning, major version upgrades that can break compatibility. Redis needs memory limits configured properly or it will consume everything available. RabbitMQ adds another failure point for background jobs.

If one service crashes at 2 AM, your project management goes down. You need to figure out which container failed and why.

What does OpenProject require to run?

OpenProject is the enterprise-focused option. It's been around for years and targets regulated industries. The infrastructure is simpler than Plane's but still requires a dedicated database server.

OpenProject needs:

  • PostgreSQL 17 (recommended, with required extensions: pgtrgm, btreegist, unaccent)
  • At least 4 GB of RAM for teams (2 GB minimum for very limited use)
  • SSD storage recommended for the database
  • Memcached for caching (in production setups)

OpenProject bundles PostgreSQL inside its Docker container for simple deployments, but this means you're running a full database server inside Docker. For production, they recommend an external PostgreSQL instance.

The RAM requirements grow with your team. Each web worker serves requests and even 5 users need at least 2 workers running simultaneously. Their documentation notes that Docker installations require more memory than native packages.

How does Huly's infrastructure compare?

Huly is a newer entrant that positions itself as a Linear and Jira alternative. Its self-hosted stack leans heavily on microservices.

Huly requires:

  • MongoDB for data storage
  • Elasticsearch for search indexing
  • MinIO for file and object storage
  • Nginx for reverse proxying
  • Multiple application containers (microservices architecture)
  • 8 GB of RAM recommended (4 GB minimum)

The stack is different from Plane's but equally complex. MongoDB needs its own backup strategy. Elasticsearch is notoriously memory-hungry and can consume 2-4 GB on its own. Add the application services and you're looking at a significant footprint.

What about Taiga?

Taiga takes a similar multi-service approach:

  • PostgreSQL for the database
  • Redis for caching
  • RabbitMQ for async tasks
  • Nginx for reverse proxying
  • At least 2 GB of RAM (more comfortable with 4 GB)

Taiga's overall footprint is lighter than Plane's, but it still requires three separate infrastructure services (PostgreSQL, Redis, RabbitMQ) beyond the application itself.

Self-hosted project management requirements compared

Here's what each tool actually needs to run:

Plane OpenProject Huly Taiga Eigenfocus
Database PostgreSQL 15.7+ PostgreSQL 17 MongoDB PostgreSQL SQLite
Cache/Queue Redis + RabbitMQ Memcached Elasticsearch Redis + RabbitMQ None
Object storage S3/MinIO Local/S3 MinIO Local Local
Minimum RAM 4 GB 2 GB 4 GB 2 GB ~512 MB
Recommended RAM 16 GB 4 GB 8 GB 4 GB 1 GB
Separate services 5+ 2-3 5+ 4+ 1
Deployment Docker Compose Docker or packages Docker Compose Docker Compose Docker

The pattern is clear. Most tools need a full database server, at least one caching or queuing service and several gigabytes of RAM before you even open the app.

Eigenfocus takes a different approach. It runs as a single Docker container with SQLite as the database. No PostgreSQL. No Redis. No message queue. Your project data lives in a single SQLite file on disk.

See how Eigenfocus pricing works.

Why do self-hosted project management requirements matter?

Infrastructure requirements affect three things directly: cost, maintenance and reliability.

Cost. A VPS with 16 GB of RAM costs roughly $50-80/month. A VPS with 1 GB costs $5-10/month. If you're self-hosting to save money compared to SaaS, the infrastructure cost can eat most of those savings.

Maintenance. Every service in the stack needs updates. PostgreSQL major versions require careful migration. Redis, RabbitMQ and Elasticsearch all have their own upgrade paths and breaking changes. More services means more things that can go wrong during updates.

Reliability. A single-container deployment has one thing that can fail. A five-service deployment has five. When something breaks at night, you need to check logs across multiple containers to find the problem. Simpler stacks are easier to keep running.

How does Eigenfocus handle self-hosted project management requirements differently?

Eigenfocus uses SQLite instead of PostgreSQL. That single decision eliminates the need for a separate database server, which in turn removes the need for Redis (no external session store needed) and simplifies the entire stack.

What this means in practice:

  • One Docker container. Pull the image, run it. No Docker Compose file with six services.
  • SQLite database. Your data is a single file on disk. Back it up by copying it. Move it by copying it. No pg_dump, no restore scripts.
  • ~512 MB of RAM. The application runs comfortably with minimal resources. No separate processes consuming memory for caching or queuing.
  • No maintenance overhead. No PostgreSQL vacuuming, no Redis memory tuning, no RabbitMQ queue monitoring. Update the Docker image and you're done.

This doesn't mean Eigenfocus is a toy. It includes board, list, timeline and grid views, custom fields, custom statuses, time tracking, SSO and project templates. The difference is in the infrastructure philosophy: keep the deployment simple so you can focus on your work instead of maintaining your tools.

For a walkthrough of what you can do with the views, see our guide on when to use each project view.

What does backup look like for each tool?

This is where infrastructure complexity shows up most clearly.

PostgreSQL-based tools (Plane, OpenProject, Taiga):

  1. Run pg_dump to create a database backup
  2. Back up Redis data (if applicable)
  3. Back up file uploads separately (S3 or local storage)
  4. Store all three backups somewhere safe
  5. Test restore periodically (this step gets skipped more than it should)

MongoDB-based tools (Huly):

  1. Run mongodump to back up the database
  2. Back up Elasticsearch indices (or plan to rebuild them)
  3. Back up MinIO/file storage
  4. Store and test

SQLite-based tools (Eigenfocus):

  1. Copy the SQLite file
  2. Copy the uploads folder
  3. Done

The restore process mirrors this. With PostgreSQL, you need to create the database, set up extensions, restore the dump, verify integrity. With SQLite, you copy the file back and start the container.

For teams running multiple self-hosted services, the backup story matters. If your project management tool adds 30 minutes to your backup script, that complexity compounds over time.

Can SQLite handle a real team?

Yes. SQLite handles billions of transactions per day across millions of deployments worldwide. It's the most widely deployed database engine in existence. It runs in every smartphone, every browser and most embedded systems.

For project management, the workload is modest. Even a busy team generates hundreds of writes per day, not thousands per second. SQLite handles this without breaking a sweat. The practical limit for SQLite in a web application is concurrent write-heavy workloads with hundreds of simultaneous users. For project management with a normal team, you're nowhere near that limit.

The trade-off is horizontal scaling. If you need to split your database across multiple servers, PostgreSQL is the right choice. But most teams self-hosting project management don't need that. They need something that works, stays up and doesn't require a DBA.

How to set up your project workflow after deploying

Once your tool is running, the real work starts: setting up your actual workflow. If you're starting fresh, our guide on setting up a project workflow from scratch walks through the steps. Define your statuses, create your first views, add custom fields where they help.

The infrastructure should disappear into the background. You shouldn't be thinking about database maintenance when you're trying to plan a sprint.

If you're comparing total costs across tools, see our 3-year PM software cost comparison. And for more on how SQLite simplifies your data story, read about why your project data is a single file.

Frequently asked questions

How much RAM do I need for self-hosted project management?

It depends on the tool. Plane recommends 16 GB for production. OpenProject and Huly need 4-8 GB. Taiga works with 2-4 GB. Eigenfocus runs comfortably on about 1 GB because it uses SQLite instead of PostgreSQL, which eliminates the memory overhead of a separate database server and caching layer.

Do all self-hosted project management tools need PostgreSQL?

No, but most do. Plane, OpenProject and Taiga all require PostgreSQL. Huly uses MongoDB instead. Eigenfocus uses SQLite, which runs embedded in the application with no separate server. The choice of database has a big impact on infrastructure complexity, backup procedures and maintenance effort.

Can I run self-hosted project management on a Raspberry Pi or small VPS?

Tools with lighter requirements (1-2 GB RAM, no external database) can run on a Raspberry Pi or $5 VPS. This includes Eigenfocus and some task management tools like Vikunja. Heavier tools like Plane or Huly need at least a 4 GB VPS, which limits your hosting options and increases monthly cost.

What's the cheapest way to self-host project management?

The cheapest approach is a tool with minimal infrastructure requirements running on a small VPS. Eigenfocus needs about 1 GB of RAM and no external database, so it runs on VPS plans starting around $5-10/month. Tools requiring 4-16 GB RAM push monthly hosting costs to $30-80. The tool's license cost is separate from the infrastructure cost.

Is self-hosted project management worth the maintenance effort?

It depends on why you're self-hosting. If data ownership, privacy or regulatory compliance matters to your organization, self-hosting is worth it. The key is picking a tool with infrastructure requirements that match your team's capacity to maintain it. A single-container deployment with SQLite requires far less ongoing effort than a multi-service stack with PostgreSQL, Redis and RabbitMQ.

Pick a tool that matches your infrastructure capacity

Self-hosted project management is worth it when you need control over your data. But "self-hosted" doesn't have to mean "complex." Check the infrastructure requirements before you commit to a tool. The deployment might take five minutes. The maintenance lasts as long as you use it.

See pricing and get started

Explore how teams use Eigenfocus for self-hosted deployment or as a public-source alternative to closed-source tools.