TL;DR — CapRover is the most resource-efficient self-hosted PaaS and a solid pick for stable single-container deployments on constrained hardware. Skip it for PR preview environments: each app tracks exactly one branch with no per-PR branching concept, and
docker-compose.ymlsupport covers only six fields — everything else is silently dropped. Maintained in 2026 but in slow-burn mode.
What It Is
CapRover [2] (GitHub ⭐ 15k [1], Jun 2026) has been running since 2017 under the tagline “Heroku on Steroids.” It wraps Docker Swarm and Nginx into a web UI + CLI, automating SSL via Let’s Encrypt and serving apps on wildcard subdomains. Latest release: v1.14.2 (May 2026), with roughly quarterly cadence [1].
Installation & Requirements
Minimum to get started [3]:
- Ubuntu 22.04/24.04, Docker 25.x+ (avoid snap install)
- 1 GB RAM — 512 MB is insufficient for builds
- Ports open: 80, 443, 3000, 996, 7946, 4789, 2377
- Wildcard DNS record (
*.subdomain.yourdomain.com)
Bootstrap is one docker run command; the web UI comes up at http://SERVER_IP:3000 with password captain42. CLI finalizes setup with caprover serversetup [3]. Supports AMD64, ARM64, ARMv7 — runs fine in a Proxmox VM.
Deployment Methods
| Method | Notes |
|---|---|
caprover deploy CLI |
Only method that surfaces build errors inline |
| Dashboard tarball upload | For testing only |
| Git webhook | One repo + one branch per app; POST webhook triggers rebuild |
| Rollback | Rebuild any prior image version with one click |
Webhook setup: enter the repo URL + branch in app settings, copy the generated webhook URL into GitHub/GitLab Settings → Webhooks [4]. Every push to that branch triggers a rebuild. There is no concept of per-PR or dynamic branch environments — each CapRover app is permanently bound to one branch.
Docker Compose Support
CapRover has a built-in Compose parser, but it covers only six fields [10]:
image · environment · ports · volumes · depends_on · hostname
All other Compose directives are silently ignored [10]. Services get renamed to srv-captain--<name>, requiring connection string updates. Workarounds: run Docker Compose outside CapRover on the same host and join its captain-overlay-network, or convert to CapRover one-click templates [10].
The captain-definition file (the native format) is JSON, single-container only [5]:
{ "schemaVersion": 2, "dockerfilePath": "./Dockerfile" }
No multi-service orchestration, no network declarations.
Resource Footprint
At idle, CapRover is among the lightest options [6]:
| Platform | CPU idle | RAM idle | Containers |
|---|---|---|---|
| CapRover ⭐ 15k | ~1–2% | ~300–400 MB | 3–4 |
| Dokploy ⭐ 35k | ~0.8% | ~350 MB | 3–4 |
| Coolify ⭐ 57k | ~5–6% | ~500–700 MB | 6–8 |
On a 1–2 GB Proxmox VM, CapRover leaves the most headroom for your actual workloads. 100M+ Docker Hub pulls reflects its production deployment footprint [8].
Strengths
- Proven stability — 9 years in production with mature codebase [8]
- Docker Swarm clustering — add worker nodes from the UI; Nginx load-balances across them automatically [2]
- CLI-first workflow —
caprover deployis fast; rollback with one click [4] - Scheduled Docker cleanup — automatic image/container pruning, no manual cron needed [8]
- In-place upgrades from the web UI, minimal downtime [8]
- Completely free — no commercial tier or cloud upsell [7]
Weaknesses
- No native PR preview environments — creating per-PR apps requires scripting GitHub Actions + CapRover API calls [4]
- Broken Docker Compose support — six fields only; everything else silently dropped [10]
- Dated UI — functional but visually 2018; no database admin tools, no built-in alerting [7]
- Slow development — quarterly releases; community reports of Docker v29+ compatibility gaps [9]
- Single-tenant — no team or multi-user access management [8]
- No observability routing — NetData integration exists but no alerting pipeline [7]
PR Preview Environments
For per-PR preview URLs on CapRover, the minimum viable pattern:
- GitHub Action on
pull_request→ calls CapRover REST API to create a new app namedpr-{number} - Configures the app to track the PR branch via webhook
- Triggers a build via the same API
- Posts the
https://pr-{number}.yourdomain.comURL as a PR comment - Second Action on
pull_request closed→ deletes the app
This is scripted infrastructure, not a platform feature. Coolify ⭐ 57k and Dokploy ⭐ 35k have more native pathways to this workflow [6]. If PR previews are the primary requirement, CapRover is the wrong tool.
Decision Matrix
| Criterion | CapRover | Notes |
|---|---|---|
| RAM-constrained VM (1–2 GB) | ✓ | Best headroom of the three options |
| Single-container apps | ✓ | Native, fast, CLI-driven |
| Multi-service Compose stacks | ✗ | 6-field parser; use workarounds |
| PR preview environments | ✗ | Manual scripting only |
| Team access / multi-user | ✗ | Single-tenant |
| Docker Swarm clustering | ✓ | Built-in, better than Coolify’s multi-server |
| Database admin UI | ✗ | Not included |
| Development velocity | ⚠ | Quarterly releases, slowing since 2024 |