CapRover: a self-hosted PaaS that hides Docker and nginx behind a web GUI

What CapRover replaces, and for whom

The README frames the target user narrowly: a web developer who does not want to spend days setting up a server, build tools, code transfer, an SSL certificate and repeated nginx edits. It also names the cost argument directly, comparing a 250 USD per month Heroku instance with a 5 USD Hetzner server of similar memory. That is the pitch. CapRover is a control plane you install on a machine you own, and it manages the pieces you would otherwise wire by hand.

The supported workload list is broad and concrete: NodeJS, Python, PHP, ASP.NET, Ruby, MariaDB, MySQL, MongoDB, Postgres and WordPress. Databases are installed by selecting from a dropdown, which is the clearest statement of the intended audience. Someone who is comfortable writing a Dockerfile, an nginx server block and a certbot renewal hook is not the user this project is optimising for, even though they can still use it.

The README also makes a lock-in claim worth reading carefully: remove CapRover and your apps keep working. That is a design commitment, not a marketing line, and it follows from the architecture described below. Containers keep running under Docker Swarm whether or not the CapRover control container is present.

Docker Swarm, nginx and Let's Encrypt as the substrate

CapRover does not implement containerisation or TLS itself. The README states that it uses Docker Swarm underneath for containerisation and clustering, nginx underneath for load balancing, and Let's Encrypt underneath for free SSL. The repository's package.json confirms the shape of the control plane: dockerode for the Docker API, express for the HTTP layer, ssh2 for remote access, simple-git for repository operations, and tar for archive handling. The nginx configuration is generated from a template, and the README describes that template as fully customizable.

So the data flow is: you give CapRover a source (a git URL, a CLI upload, or a built image), it produces a Swarm service, and a generated nginx server block routes the domain to that service and terminates TLS with a Let's Encrypt certificate. The control plane is a Node process talking to the Docker socket. That is the whole architecture, and it explains both the strengths and the limits. Anything Docker Swarm cannot express, CapRover cannot express either.

The practical consequence is that the abstraction is thin in a good way. When something goes wrong, the underlying objects are still standard Swarm services and standard nginx config, inspectable with normal Docker tooling. The trade-off is that CapRover's own state and Swarm's state can drift, and the README does not describe any reconciliation mechanism for that.

Installing CapRover and deploying a first app

The README points to https://CapRover.com/ under "Getting Started" for the install steps, and describes the required server knowledge as "Knowledge of Copy & Paste". The repository itself does not carry the install command in the README text, so treat the website as the authoritative source for the current one-liner rather than any snippet you find elsewhere.

Once the server is up, the CLI is the automation path and the web GUI is the convenience path. The CLI is distributed as an npm package named caprover, which is what the README means by "CLI for automation and scripting". After installing it globally, you log the CLI into your server and deploy from the directory containing your app:

npm install -g caprover
caprover login
caprover deploy

The login step prompts for your CapRover server address and the password you set in the dashboard, then stores a token locally. The deploy step asks which app to target and how to send the code, and the README's own framing of the workflow is that you send code to the server and it builds there. What you should see after a successful deploy is the app listed in the dashboard with a running container and, if you attached a domain, an HTTPS endpoint.

For a first real use, the smallest useful test is a database rather than an app. The README states that MariaDB, MySQL, MongoDB and Postgres install by selecting from a dropdown and clicking install. That gives you a running service with generated credentials shown in the panel, without writing a compose file. Point a test app at it before you put anything real in it.

Where the abstraction leaks

The README's strongest claim, that no Docker or nginx knowledge is required, holds until it does not. Customising the nginx template is explicitly supported, which means the moment your routing needs diverge from the generated default, you are editing nginx configuration, and the no-knowledge promise is void. The same applies to Docker: the README advertises Swarm for clustering, but clustering brings scheduling, networking and volume questions that a dropdown cannot answer.

The bigger gap is operational. The README does not document rollback. There is no described mechanism for reverting a deploy to a previous build, no versioned release history in the panel, and no stated blue-green or canary path. For a tool aimed at people replacing Heroku, that is a notable omission, because Heroku's release and rollback model is part of what people are paying for. If your deployment process requires a tested revert, you are building that yourself on top of git tags and redeploys.

The third limitation is scope. CapRover manages one server well and a Swarm cluster adequately, but it is not a multi-tenant platform. The README does not describe team permissions, per-user isolation or audit logging. Running it as shared infrastructure for several unrelated teams means sharing one admin credential, and nothing in the repository suggests otherwise.

CapRover vs Dokku, Coolify and plain Docker

The most common comparison is with Dokku, and the difference is in the interface and the substrate. Dokku is a git-push buildpack-style platform driven from the command line; CapRover pairs a CLI with a web GUI and runs on Docker Swarm rather than a single-node Docker daemon. That Swarm choice is what makes the clustering story possible, and it is also what makes CapRover heavier to reason about than Dokku when something misbehaves.

Coolify and Dokploy occupy the same self-hosted PaaS space with their own control panels. Neither is described in the CapRover README, so the honest difference to state is the one CapRover documents about itself: Docker Swarm under the hood, nginx for load balancing with a customizable template, Let's Encrypt for certificates, and a stated no-lock-in property where removing CapRover leaves apps running.

Against plain Docker, the comparison is simpler. CapRover is Docker plus a scheduler, a reverse proxy, certificate automation and a UI. If you already run a reverse proxy and a certificate renewal job you trust, CapRover mostly adds a panel. The README's own framing, that it is for someone who prefers writing showResults(getUserList()) over apt-get install libstdc++6, tells you which side of that line it is on.

Maintenance, releases and licence status

The repository is not archived, and the last push was on 2026-09-21. Releases are frequent and versioned: v1.15.4 on 2026-08-30, v1.15.3 on 2026-08-20 and v1.15.2 on 2026-08-15. That cadence matters for upgrade planning, because a control plane that talks to the Docker socket is security-sensitive, and a project shipping patch releases every couple of weeks means you will be applying updates rather than setting and forgetting.

The upgrade cost is not documented in the README. There is a CHANGELOG.md at the repository root and a release/ directory, which is where you would look before upgrading, but the README itself gives no migration guidance or compatibility matrix. Budget for reading the changelog before each version bump rather than assuming in-place upgrades are inert.

On licensing, the repository reports NOASSERTION, and there is both a LICENSE file and a TERMS_AND_CONDITIONS.md at the root. NOASSERTION means GitHub could not map the licence to a recognised identifier, not that no licence exists. Read both files before you depend on CapRover commercially. This is not legal advice, and the terms file existing alongside the licence is itself a signal that the two need reading together.

Editorial conclusion

Adopt CapRover if you run a single small server and want dropdown database installs, automatic HTTPS and git-push deploys without learning Docker or nginx. Do not adopt it if you need documented rollback, per-service resource policy or a Kubernetes-style API surface; the README does not describe any of those. Before committing, verify the CapRover CLI version against your server, confirm the default password path on first login, and check the LICENSE and TERMS_AND_CONDITIONS.md files, since the repository reports NOASSERTION rather than a named licence.

Frequently asked questions

Official sources

1. caprover/caprover on GitHub
2. Issues
3. Project website
4. README
5. Releases