A CapRover Alternative That Runs on Your Desktop, Not Your Server

CapRover and Shipown both deploy your apps to servers you own. CapRover is a free, open-source PaaS you install on a server: a web dashboard on port 3000 and a CLI drive a stack of Docker, nginx, Let's Encrypt and Docker Swarm, and your apps run as containers. Shipown is a desktop app for Windows and Linux that connects over SSH, installs no agent, runs Node apps directly under PM2 and static sites straight from Nginx, and deploys Dockerfile and Compose apps when you want containers.

CapRover suits developers who want a free self-hosted panel with one-click apps and a path to Swarm clusters. Shipown suits developers who want to keep the server free of a panel and drive deploys from their own machine. The CapRover facts below come from its own site and documentation, checked in October 2026.

What is CapRover?

CapRover describes itself as a "scalable, free, and self-hosted PaaS". It is a web panel installed on your server, with its dashboard on port 3000, plus a CLI that you install with npm install -g caprover and use to ship code with caprover deploy.

Its getting-started guide lists the prerequisites: Docker 25 or newer already installed, a public IP address, ports 80, 443 and 3000 open, and a wildcard DNS record for HTTPS (CapRover getting started). The docs also warn that 512 MB of RAM might not be enough. Under the dashboard, the stack is Docker, nginx, Let's Encrypt and Docker Swarm.

Node apps run in containers, built from templateId: node/24 in a captain-definition file or from a Dockerfile (CapRover captain-definition file). CapRover's strengths are one-click apps, Swarm clusters with load balancing (CapRover app scaling and clusters), automatic Let's Encrypt certificates, and deploys from the dashboard, the CLI, a webhook or git.

CapRover is free forever and licensed Apache 2.0. A paid Pro plan adds build notifications, login alerts, two-factor authentication and SLA email support. Its site does not mention AI features.

Why developers look for a CapRover alternative

CapRover gives you a lot for nothing: a dashboard, a CLI, one-click apps and certificates, all free. The reasons people look elsewhere are about its prerequisites and the stack it places between an app and the internet.

Docker first, then three open ports

CapRover installs onto a server that already runs Docker 25 or newer, with a public IP and ports 80, 443 and 3000 open. Ports 80 and 443 carry your sites. Port 3000 is the dashboard, a web login on a public address, which you then keep patched and protected like any other internet-facing service.

HTTPS depends on a wildcard DNS record

CapRover's HTTPS setup expects a wildcard DNS record pointing at the server. That works neatly when a domain or subdomain is dedicated to the server. When each app has its own unrelated domain, or the DNS zone is managed by someone else, the wildcard record is one more thing to arrange before HTTPS works.

Swarm and a container for every app

The stack includes Docker Swarm, and Node apps run in containers built from a template or a Dockerfile. Swarm is what lets CapRover scale an app across a load-balanced cluster. On a single small VPS running one Node app, it means an orchestrator and a container runtime sit between your code and the internet, and you debug through both.

Memory on small servers

CapRover's own documentation warns that 512 MB of RAM might not be enough. On the smallest VPS plans, the dashboard and its stack draw on the same memory your apps need.

How Shipown works differently

Docker is an option, not a prerequisite

Shipown needs a Linux server you can reach over SSH, and Docker does not have to be installed first. It inspects the server and reports what is missing; setup offers PM2 preparation, Docker installation, and a Domains & HTTPS installer for Nginx and Certbot, so you install only what your apps use. Node apps (Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify and plain Express) run directly under PM2, static sites from Vite, Astro or plain HTML are served straight from Nginx, and a Dockerfile or Compose file is deployed as containers when you want that. Ubuntu, Debian, the RHEL family and Alpine are handled. Start with connecting a server.

The tool needs SSH and nothing else

Shipown installs no agent, so there is no dashboard port to open and no web login on the server to protect. Your sites still use ports 80 and 443; the tool itself only uses SSH. Credentials stay on your computer: SSH keys, passphrases and environment values are held by the app's main process and never uploaded for licensing or telemetry. When you save a server, you choose whether its password is kept, encrypted by the operating system, or asked for once per session instead.

A certificate per domain, without a wildcard

Point a domain at an app and Shipown writes the Nginx virtual host, tests the configuration before reloading, and asks Certbot for a certificate for that domain. A configuration Nginx rejects is put back the way it was, and certificate expiry is shown in the app. Each domain needs only its own DNS record pointing at the server, so apps with unrelated domains can share one server without a wildcard record.

Releases, health checks and rollback

Each deploy lands in its own release directory and goes live only after the build and the health check pass. A failed deploy restores the previous release automatically, and rolling back later is picking an earlier release. A static site can be taken offline without being deleted. For containers, the previous container stays until the new one passes its health check, and retained images support rollback. Every progress line in the deploy window is real output from the build and the health check.

An AI terminal for the server you deploy to

CapRover's site does not mention AI features. Shipown includes an AI terminal: with your own Anthropic, OpenAI or DeepSeek key, you describe what is wrong, such as a 502 from Nginx or a full disk, and the model proposes one shell command at a time, with its reason, for you to approve. Destructive commands are always held for confirmation, and requests go from your computer to the provider you chose. The guide to AI server management covers how to use this kind of tool safely.

Monitoring and server care

Each server has its own page in Shipown: CPU, memory, disk, network, uptime and load read from /proc, the busiest processes, the apps, the domains and the logs, next to a real terminal (live terminal and health). An SSH heartbeat reports an unreachable server once and its recovery once, in the live feed and as an OS notification when alerts are on. The same app covers cron, ufw or firewalld, swap, fail2ban, deploy users, and database backups for MySQL, MariaDB, PostgreSQL and MongoDB engines already on the server. All of it runs from the desktop app, so the app must be running and the PC awake.

CapRover vs Shipown: feature comparison

Pricing compared

As of October 2026, CapRover itself is free forever under the Apache 2.0 licence (CapRover). A paid Pro plan adds build notifications, login alerts, two-factor authentication and SLA email support; its current price is on CapRover's site.

Shipown is a free trial, then a paid licence for a fixed period that does not renew by itself; current prices are on the pricing page. On cost alone, CapRover is the cheaper choice: the tool is free and open source, and you pay only for the server.

When CapRover is the better choice

• You want a free, open-source tool and are happy for it to run on your server.
• You want one-click apps alongside your own code.
• You need to scale an app across a Docker Swarm cluster with load balancing.
• You want deploys from a webhook or git, or from a script with caprover deploy, without anyone opening a desktop app.
• You want a dashboard reachable from any browser, including on a Mac; Shipown has no macOS app yet.
• Your domains already sit under a wildcard record and your apps already ship as containers.
• You want the Pro plan's two-factor authentication, login alerts and SLA email support.
• You need a tool that keeps working when every developer's computer is off; Shipown's monitoring and alerts need the desktop app running and the PC awake.

When Shipown is the better choice

• You would rather not install Docker on every server or open a dashboard port.
• Your apps use unrelated domains and you want a certificate per domain without a wildcard record.
• You run Node apps and static sites and want them under PM2 and Nginx, with Docker only for the apps that need it.
• You want each release health-checked before it goes live, an automatic restore when a deploy fails, and rollback to an earlier release.
• Your VPS is small and you want its memory for your apps, with nothing of the deploy tool running on the server.
• You want an AI terminal on your own key that proposes one command at a time for approval.
• You also maintain the servers: firewall rules, fail2ban, cron, swap, deploy users and database backups.

Moving from CapRover to Shipown

Rebuild on a fresh server, check everything there, and move traffic with DNS last, so CapRover remains a working fallback until you switch it off. The Node.js deploy guide covers the PM2 and Nginx side in more detail.

1. List every app. For each one, note its captain-definition file or Dockerfile, its environment variables, the port it listens on, the directories or volumes it keeps data in, its domains, and any one-click apps it depends on, such as a database.
2. Archive persistent data. Use the commands below to copy each volume off the server, and dump each database with its engine's own tool (pg_dump, mysqldump or mariadb-dump, mongodump).
3. Prepare the new server. Connect it in Shipown; the connection is tested before it is saved. Install only what you need: PM2 for Node apps, Nginx and Certbot for domains, Docker for container apps.
4. Restore the data. Install each database engine on the new server, restore the dumps, and unpack the volume archives where the apps will read them.
5. Deploy each app. A Node app built from a Node template can run under PM2; make sure the server's Node.js version matches the one the app expects. Anything that needs its Dockerfile can keep it. Review the detected plan, add the environment variables, deploy and read the build log.
6. Point DNS, then add HTTPS. Lower the TTL a day ahead, point each domain's A or AAAA record at the new server, and request the certificate once it resolves there. The wildcard record is no longer needed for HTTPS.
7. Retire CapRover last. Keep it running until traffic, logs and backups are confirmed on the new server, schedule daily database backups in Shipown, and only then shut the old server down.

# On the CapRover server: list volumes, archive one, copy it across
docker volume ls
docker run --rm -v <volume>:/data -v "$PWD":/backup alpine tar czf /backup/<volume>.tgz -C /data .
scp <volume>.tgz <user>@<new-server>:~

# On the new server: unpack it where the app will read it
sudo mkdir -p /srv/<app>-data
sudo tar xzf ~/<volume>.tgz -C /srv/<app>-data