Server Requirements

CPU

CPU idles most of the time, but when it's needed — a build, a backup, a Docker image pull — it matters. Enough CPU makes the system feel responsive during those moments rather than grinding. 2 vCPU is sufficient for low traffic; 4 vCPU gives comfortable headroom so a larger task can run fast without impacting other services.

Memory

Memory is the real constraint. Each service runs as a Docker container with its own process — a knowledge base, a design tool, a git server, and an AI interface can collectively idle at 4–6 GB. 4 GB is the minimum to get started; 12 GB lets you run several services without pressure.

Given how easy Coolify makes it to spin up new services, you quickly arrive at 6-8 services within a few hours of clicking around — so starting with more than the minimum is a sensible default. And if services are actually under load, you'll want a buffer on top of that.

Disk

There are two distinct storage types, each suited to different concerns.

Block storage

Block storage works like a disk — a filesystem that processes read and write to directly. There are two kinds:

Ephemeral (OS disk) — tied to the instance. Holds the operating system and Docker tooling; 10–20 GB is enough. If the instance is terminated, this goes with it. Keep it small and separate from data.

Persistent volume — a separate block device attached to the instance. This is where Docker images, container volumes, and all service data live. Docker images alone can be 1–2 GB each; with 5–10 services you fill up fast. A persistent volume can be expanded independently and reattached to a new instance if needed — which is why keeping it separate from the OS disk matters.

Object storage

Object storage is different — you store and retrieve files via an API rather than a filesystem. Files are organized into buckets (OpenStack calls them containers). There is no disk to resize; capacity scales automatically and you pay for what you use.

This makes it the right fit for large binaries that accumulate over time: Nextcloud files, Penpot assets, database dumps, and backups. Offloading these keeps the persistent volume lean and avoids resizing it as data grows. Most providers offer S3-compatible object storage; Infomaniak's Swiss Storage is a values-aligned option.

Scaling, backups & extras

Before committing to a provider, check two things:

Scaling — can you resize the VM to a larger plan without rebuilding from scratch? Most providers support this, but not all do it cleanly. Ideally it's a one-click operation from the control panel with minimal downtime.

Backups — does the provider include automated VM snapshots, and how far back do they go? This is a safety net for infrastructure-level failures, separate from the application-level backups you manage yourself. Some providers include it in the plan; others charge extra.

Extras — some providers bundle capabilities worth factoring in: DDoS protection at the network level, an external firewall managed from the control panel (simpler than OS-level rules), and OpenStack API access for more advanced setups like additional networks, private object storage, or managing multiple servers programmatically.

Summary

Server size should match usage intent — don't over-provision, but don't cut corners either. A server running 3 services for a handful of users has very different needs than one running 10 services for an entire organisation.

Requirement	Minimum	Tested
OS	Debian 13 Trixie	Debian 13 Trixie
CPU	2 vCPU	4 vCPU
RAM	8 GB	12 GB
OS disk	20 GB	20 GB
Data disk	100 GB	250 GB
Estimated services	4–8	8–12