Kamal VPS Requirements: RAM, CPU & Storage Guide

Kamal is a deployment tool that runs on your own machine or CI runner, not on the server. So “Kamal VPS requirements” is really a question about the machine Kamal deploys to: it has to run your application containers, kamal-proxy, any accessories you declared, and a few days of old images kept for rollback.

Kamal’s own resource cost on the host is zero. Size everything else.

What Consumes Resources on the Host

After kamal setup, the server runs three things:

• kamal-proxy, a small Go HTTP proxy holding ports 80 and 443
• your app containers, one set per role in config/deploy.yml
• accessories — Postgres, Redis, or whatever else you declared

Only the middle two matter for sizing. kamal-proxy is a single static binary and its footprint disappears next to any real application.

RAM

The figure that catches people out is not steady-state memory, it is the deploy overlap. Kamal boots the new container while the old one is still serving traffic, and only stops the old one after the new one passes its health check. Peak memory is therefore your normal usage plus roughly one more copy of the app container.

• Practical minimum: 2 GB, for a small app with no separate database
• Comfortable: 4 GB, which covers a typical web app plus Postgres and the deploy overlap
• Add swap on 4 GB hosts. A host that starts swapping mid-deploy can get slow enough to miss the health-check window, and the deploy then rolls back for what looks like no reason.

If you run Postgres as a Kamal accessory rather than as a managed service, size for it explicitly — it, not Kamal, will be the largest consumer on the box.

CPU

Two vCPUs is the sensible floor, for a reason that has nothing to do with steady-state load: during a deploy the host is simultaneously pulling an image, starting a container, running health checks, and serving traffic from the old container. On a single vCPU that contention stretches the deploy window.

• Minimum: 1 vCPU, workable for a low-traffic app if you accept slower deploys
• Recommended: 2 vCPUs
• Building images on the VPS itself is the one case that genuinely needs more. If your laptop is arm64 and the VPS is your only amd64 machine, a build will use every core you give it.

Storage

This is where Kamal’s behaviour actually changes the numbers. Kamal keeps old containers and images on the server so kamal rollback can restart a previous version without pulling from the registry, and prunes them after three days by default.

So the disk has to hold:

• Your application’s own data and volumes
• The current image plus roughly three days of previous versions
• Shared base layers, which are stored once no matter how many versions you keep

A 1 GB image deployed a few times a day is fine on 40 GB NVMe. A 3 GB image on a 25 GB disk fills the disk within a week. The failure mode is worth knowing: a full disk breaks the next deploy, not the one that filled it, so the cause and the symptom are days apart.

If you deploy often, kamal prune all clears the backlog on demand rather than waiting for the three-day window.

VPS Provider Options and Pricing

For a comprehensive look at options, check the full VPS comparison.

DigitalOcean is the easiest entry point, because Kamal deliberately does not manage the host beyond Docker — firewall rules, swap, and unattended upgrades are still yours, and DigitalOcean’s documentation covers all three. Hetzner gives you more RAM and disk per euro if you are comfortable doing that setup yourself.

Practical Deployment Tips

• Give the server only ports 22, 80, and 443. kamal-proxy terminates TLS itself, so nothing else needs to be reachable.
• Check kamal app containers before relying on a rollback; the target has to still be on disk.
• Watch free disk with the same alerting you use for memory. It is the failure that arrives quietly.
• Deploying a second app to the same host is supported in Kamal 2 — kamal-proxy routes by hostname — but that doubles the container count and the image history, so size the disk for both.

Conclusion

For most single-app deployments, 2 vCPUs, 4 GB RAM, and 40 GB of SSD or NVMe leaves room for the app, its database, the deploy overlap, and three days of rollback images. Push the disk higher before you push the RAM higher: memory pressure announces itself, while image accumulation does not. For more options, explore our full VPS comparison to find the best match for your deployment.