Run CapRover on a VPS for One-Click App Deploys

Most “simple” VPS deployments fail the same way. You end up hand-editing Nginx, babysitting TLS renewals, and trying to remember which container grabbed port 3000. If you run CapRover on a VPS, you get a self-hosted PaaS that centralizes routing, HTTPS, and repeatable deploys. Releases stop turning into late-night SSH archaeology.

This is a practical look at CapRover. You’ll see what it’s good at, where it’s a poor fit, what it can replace, and how to install it on a real VPS or dedicated server. The goal is sensible defaults for domains, HTTPS, backups, and updates.

Why CapRover is worth self-hosting

CapRover is a self-hosted platform-as-a-service built on Docker. You deploy through its web UI or CLI, and it creates services, maps routes, and proxies traffic for you.

It also includes a one-click catalog for common components (databases, caches, CMS tools). That’s useful for staging, internal tools, and quick prototypes.

If you run multiple small-to-medium apps—Node.js APIs, Laravel sites, Python services, static frontends—CapRover gives you one consistent target. You’ll notice the value the first time you roll back a bad image without touching reverse-proxy config.

• Good fit for: small teams, agencies, solo devs, SaaS prototypes, internal dashboards, multi-app VPS setups.
• Not a fit for: Kubernetes-scale multi-cluster setups, heavy compliance requirements that demand bespoke control, or workloads that need very custom networking.

Run CapRover on a VPS: what it replaces (and what it doesn’t)

CapRover can replace the usual pile of glue. Think custom Nginx vhosts, scattered docker-compose files, one-off Let’s Encrypt scripts, and “deployments” that amount to git pull on the server.

It’s closest in spirit to managed platforms like Heroku or Render, except you host the control plane yourself. In exchange for owning OS and Docker maintenance, you get predictable monthly cost, data locality, and fewer platform limits.

• CapRover vs Heroku/Render: you manage the server OS and Docker updates, but you avoid per-app pricing and keep deployments on your own box.
• CapRover vs Coolify: both aim at self-hosted PaaS workflows. Coolify emphasizes Git-based pipelines and broader integrations; CapRover emphasizes simple app routing and a mature “captain” workflow.
• CapRover vs “DIY Nginx + Compose”: DIY gives maximum control; CapRover reduces repetitive wiring and makes multi-app hosting less fragile.

If you already run Coolify, staying put may be the right move. You can compare approaches with HostMyCode’s guide: self-host Coolify on a VPS with Nginx and HTTPS.

Infrastructure checklist before you deploy

CapRover runs fine on a standard Linux VPS. Size for your workloads, not the dashboard.

• OS: Ubuntu Server LTS or Debian stable are common choices for 2026 production VPS hosting.
• CPU/RAM baseline: 2 vCPU / 4 GB RAM if you plan to run multiple apps and a database. For a couple of small services, 2 GB can work, but you’ll feel it during builds.
• Disk: NVMe storage is strongly preferred. Containers and image pulls punish slow disks.
• Network: open ports 80 and 443 to the public internet. Keep SSH restricted to your IP or a VPN.
• DNS: a domain you control, with at least one subdomain reserved for the CapRover UI.

If you want a baseline that won’t feel cramped the moment you add Redis and Postgres, start with a HostMyCode VPS.

If you don’t want to own patching and monitoring, managed VPS hosting is often the better production choice.

CapRover licensing and what you actually “own”

CapRover is open source and designed to be self-hosted. You run the admin UI and the reverse-proxy layer on your own server.

Your app definitions, environment variables, and deployment history live there too. Treat the CapRover host like a control plane.

Secure it the way you’d secure a CI runner or a secrets store.

Deploying CapRover with Docker (Compose-style, without the drama)

Most installs use a Docker command that starts CapRover’s “captain” container and provisions what it needs. Even without a formal Compose file, you can keep things Compose-like.

Store install inputs in a dedicated directory. Document them like infrastructure code.

On a fresh VPS, the flow usually looks like this:

1. Install Docker Engine and the Compose plugin.
2. Point DNS (wildcard recommended) at your VPS.
3. Run the CapRover installer and pick a root domain like apps.example.com.
4. Log in to the CapRover UI on a dedicated subdomain and set HTTPS.

Two details matter more than the rest:

• Wildcard DNS: *.apps.example.com → your VPS IP. This keeps “add a new app” from becoming a DNS chore.
• Clean firewalling: expose only 80/443 publicly; lock SSH down. If you need a refresher, see how to set up UFW on Ubuntu.

Domain and DNS: the part most deployments get wrong

CapRover is easiest to live with when you dedicate a subdomain to apps. A common pattern is:

• captain.apps.example.com for the admin UI
• api.apps.example.com, web.apps.example.com, etc. for services

DNS records to create:

• A record for captain.apps.example.com → VPS IPv4
• Wildcard A record for *.apps.example.com → VPS IPv4
• AAAA records if you serve IPv6 (recommended if your provider supports it end-to-end)

Keep TTL low (like 300 seconds) during initial setup. If you ever migrate the VPS, a low TTL makes the cutover routine.

This checklist is a solid reference: DNS cutover tutorial for zero-downtime migrations.

Reverse proxy and HTTPS: how CapRover handles it (and what you still must verify)

CapRover includes its own routing layer (built around Nginx). It can also request and renew Let’s Encrypt certificates for domains you attach to apps.

That’s the payoff: you stop writing vhost files by hand.

Even so, verify the basics at the server level:

• Port 80 reachable from the internet for HTTP-01 challenges (unless you’re doing DNS-01 outside of CapRover).
• Port 443 reachable and not intercepted by another service.
• No legacy Nginx/Apache instance already binding to 80/443.

If routing gets weird, the symptom often looks like a generic upstream failure. This diagnostic guide still applies even if the “upstream” is a container: Nginx 502 Bad Gateway fixes on Ubuntu VPS.

For deeper TLS issues (ACME challenges, renewal failures, mixed content), keep this one close: TLS setup guide (2026): Let’s Encrypt on a VPS.

Operational habits that keep CapRover stable

CapRover shrinks the per-app busywork, but you still operate a server. The basics matter, and they matter consistently.

• Patch cadence: keep the OS updated on a schedule, not “when you remember.”
• SSH hygiene: key-based login, no password auth, and restricted IPs if possible.
• Resource caps: set memory limits per app so one bad deploy doesn’t take down every service.
• Separate data from containers: always use volumes for persistent data (databases, uploads).

On Ubuntu, automatic security updates are a reasonable baseline for many VPS setups. For practical settings and gotchas, read automated security updates on Ubuntu.

Backups: what to back up (and what you can recreate)

CapRover is rebuildable. Your data and configuration memory are not.

In practice, backups fall into three buckets:

• CapRover state: configuration, app definitions, and platform metadata.
• App data: volumes for databases, uploads, and persistent services.
• Off-box copy: a backup that exists even if the VPS disk dies.

Concrete backup approach that works well on a VPS:

• Identify Docker volumes tied to critical apps (Postgres, MariaDB, Redis with AOF, file uploads).
• Nightly job to snapshot volume contents (or dump databases) to /var/backups.
• Sync encrypted backups to object storage or a separate backup VPS.

For database-backed apps, prefer logical dumps so you can restore into a fresh container. For MariaDB/MySQL, this guide is a good template: MariaDB install + secure backups on Ubuntu.

Quick reality check: test a restore quarterly. A backup you’ve never restored is just stored hope.

Updating CapRover with minimal downtime

CapRover updates are usually painless. Still, treat them like any other control-plane update.

• Back up first: platform state plus critical volumes.
• Update during a quiet window: even if your apps keep running, control operations can pause briefly.
• Watch disk usage: Docker image layers pile up; prune safely after verifying the update.

On the app side, “minimal downtime” usually comes from a few repeatable habits:

• Use health checks so CapRover knows when a new container is actually ready.
• Keep builds out of production if they’re heavy; build images in CI and deploy by tag.
• Pin dependencies for repeatable builds, then update intentionally.

How CapRover fits into a HostMyCode stack

CapRover makes sense on a VPS because it lets you host multiple apps without turning the box into a hand-tuned snowflake. That fits a common HostMyCode setup: a few production services, a staging copy, and some internal tooling.

• Start on a HostMyCode VPS for predictable resources and clean isolation.
• Move to dedicated servers if you run CPU-heavy builds, many apps, or need strict performance isolation.
• Add a real domain strategy with domains and consistent subdomain patterns, so deployments don’t become DNS archaeology.

Pitfalls you can avoid on day one

A few problems show up again and again:

• Running CapRover on the same host as “legacy” Nginx/Apache binding to 80/443. Pick one entrypoint. CapRover expects to own those ports.
• No wildcard DNS. You can add domains one-by-one, but it’s tedious and error-prone. Wildcard DNS makes app onboarding fast.
• Under-sizing RAM. Docker builds, Node bundlers, and PHP composer installs can spike memory. If you’re tight on RAM, you’ll see random build failures.
• Backups that ignore volumes. Your containers are replaceable; your data isn’t.
• Exposing the admin UI broadly. Restrict access (VPN, allowlist, strong credentials). The dashboard is a high-value target.

Summary: a calmer way to run multiple apps on one server

CapRover is a practical middle ground if you’re tired of maintaining a growing collection of Nginx snippets and TLS workarounds. You keep the simplicity of a single VPS, but gain repeatable deployments, centralized routing, and built-in HTTPS management.

If you want the experience to stay boring (in a good way), nail three things early: a clean domain plan, real backups, and a steady update cadence.

If you want CapRover on infrastructure sized for multiple apps and steady container workloads, start with a HostMyCode VPS. For production where you’d rather hand off patching and baseline monitoring, managed VPS hosting is the more comfortable long-term choice.

FAQ

Do I need a wildcard domain to run CapRover?

No, but you’ll want one. Wildcard DNS (*.apps.example.com) lets you add new apps without touching DNS every time, which is a big part of the PaaS workflow.

Can I run CapRover alongside an existing Nginx or Apache web server?

Not cleanly on the same ports. CapRover expects to control 80/443. If you must keep an existing web server, place CapRover on a separate VPS or put an external reverse proxy in front and route carefully.

What should I back up for CapRover?

Back up CapRover’s configuration/state and every Docker volume that stores persistent data (databases, uploads, app storage). Keep at least one encrypted offsite copy.

How much downtime should I expect during updates?

App uptime depends on how you deploy (health checks, rolling behavior, image pull time). CapRover platform updates are usually brief, but plan a maintenance window and back up first.

Is CapRover a replacement for Kubernetes?

No. It’s a simpler deployment layer for VPS and single-server (or small multi-server) setups. If you need multi-cluster scheduling and complex service discovery, Kubernetes is a different tool with a different operating cost.