Deploy your applications with CapRover on a VPS

Deploying on a bare VPS means manually configuring Nginx, TLS certificates, Docker and restarts on every release. CapRover removes that friction: it relies on Docker Swarm to orchestrate your containers, generates Let's Encrypt certificates, and offers deployment via git push or a pre-built Docker image. Its One-Click Apps catalog covers WordPress, PostgreSQL, Redis, MongoDB, Ghost and over a hundred other services, each in its own container. Where Heroku or Render charge per dyno or per compute hour, CapRover runs on your VPS at your fixed monthly server cost — the natural option for developers and agencies who want PaaS productivity without the variable bill.

CapRover reserves RAM for Docker Swarm and its build engine. A VPS with 2 GB of RAM and 1 vCPU is enough for personal projects and a few small apps; move up to 4 GB of RAM and 2 vCPU as soon as you host several apps with their databases. Plan for at least 30 GB of SSD, since each Docker build consumes temporary disk space. A wildcard domain is strongly recommended — for example *.apps.mydomain.com — so that CapRover generates subdomains on the fly for each app. Ports 80, 443 and 3000 (admin panel) must be open. Since version 1.14, CapRover requires Docker with a minimum API version of 1.43; version 1.14.1 fixed a compatibility issue introduced by Docker v29 which raised that minimum to 1.44. Check your version with docker version | grep API before any upgrade.

CapRover exposes a build webhook per application, accessible in the Deployment tab of each app. This webhook triggers a full deployment on each HTTP POST call. To integrate with GitHub Actions, store three secrets in your repository: CAPROVER_SERVER (your instance URL), APP_NAME (the CapRover app name) and APP_TOKEN (the deployment token shown in the Deployment tab). An official action is available on the GitHub Marketplace (caprover/deploy-from-github): it handles building the deployment tar and sending it to CapRover in a single step. A minimal job example: after npm run build producing a dist/ folder, create an archive containing dist/ and your captain-definition, then call the action with your three secrets. The webhook + GitHub Actions combination replaces the local CLI for teams: a push to main triggers an automatic deployment, no server access key is shared among developers.

CapRover runs natively on Docker Swarm: adding capacity is done from the panel without reconfiguring your apps. In the Cluster menu, enter the IP of the new node, the associated root SSH key and the IP of your primary node as seen from the new node. CapRover installs Docker on the target and joins it to the Swarm. One important constraint: cluster mode requires a default Docker registry, because the primary node must push built images to worker nodes. CapRover offers to deploy one automatically. Another constraint to know: apps with a Persistent Directory enabled can only run on a single node (Docker Swarm does not share file volumes between hosts). To scale a stateful app, use an external database or an object storage service.

CapRover offers a native backup from the panel: Settings → Export Backup. The produced archive contains the configuration of all your apps, environment variables and Nginx settings. It does not contain the data from persistent volumes. To back up a PostgreSQL database hosted via One-Click, the recommended approach is a cron-scheduled pg_dump archived to external storage. Docker volumes are accessible under /var/lib/docker/volumes/; a copy of these folders, with the database stopped, is a low-level backup. Always test restoration on a staging VPS before relying on a backup in production.

Here are the error messages actually encountered in GitHub issues and CapRover forums, with their causes and fixes.