Cloudron vs CasaOS vs Coolify on a VPS

What you are building

You are choosing a tool as much as installing one. Three panels promise to turn a bare VPS into a point-and-click app host: Cloudron, CasaOS, and Coolify. This guide puts each on the same fresh Ubuntu 24.04 box, installs a first app, then looks hard at the parts nobody screenshots: TLS, backups, updates, memory cost, and how hard it is to leave. By the end you will know which one fits, or whether the honest answer is "none of them, just use Docker Compose."

None of these is magic. Under all three is the same Docker Engine you could drive by hand. What a panel sells you, in cash or RAM or lock-in, is four chores done for you: one-click app installs, automatic TLS certificates, scheduled backups, and user management. If those four are worth real overhead to you, a panel earns its keep. If you run one or two services and like knowing exactly what is on your box, read the "Skip all three" section first and save yourself the trouble.

Shared prerequisites and the honest gotchas

All three assume a KVM VPS, not container virtualisation. Docker needs a real kernel, and Cloudron flatly rejects OpenVZ and LXC. Check with systemd-detect-virt: kvm or qemu is fine, openvz or lxc is not. On a KVM plan the command prints kvm, and on bare metal it prints none; either one means you are clear to continue.

Beyond that the numbers diverge, and this is the first thing that steers the choice.

• RAM. CasaOS runs happily on 1GB; it grew up on Raspberry Pi hardware and stays light. Coolify wants 2GB and two CPU cores as a floor, and about 600 MB of that is Coolify itself. Cloudron needs 2GB minimum and is genuinely happier at 4GB, because it runs a mail server and a database before you install a single app.
• A domain and DNS you control. Cloudron and Coolify both want a real domain with working DNS. Cloudron ideally wants API access to your DNS provider so it can create records and wildcard certificates itself. CasaOS will run on a bare IP, but then you get no TLS at all.
• Ports. All three need 80 and 443 open for HTTP and HTTPS. Coolify additionally serves its dashboard on 8000, and uses 6001 for its realtime channel and 6002 for the in-browser terminal. Keep port 22 open for SSH on every one of them.

Get DNS pointed at the box before you start. A panel that cannot resolve its own hostname cannot request a certificate, and you will spend the first hour debugging that instead of the software. Point an A record at the server IP, and for Coolify add a wildcard record (*.apps.example.com) so every deployed app gets its own subdomain.

Cloudron: the polished, opinionated appliance

What it is. Cloudron is a commercial platform that turns a whole server into a managed appliance. It runs its own reverse proxy, database, and mail stack, plus a curated App Store of packaged apps (Nextcloud, WordPress, Gitea, Mattermost, and more). It targets people who want their apps managed, with automatic updates, automatic certs, and automatic backups, and who will pay for that.

Install. It insists on a clean box and takes it over completely. Run this on a fresh Ubuntu 24.04 (Noble) server and nothing else:

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

The script installs Docker, nginx, a database and the mail stack, then reboots. When the box comes back, open https://<your-ip>, accept the temporary self-signed certificate, and finish setup in the browser: point it at your domain, choose your DNS provider, and it provisions its own dashboard at my.example.com.

Adding a first app. In the dashboard, open the App Store, click (say) Nextcloud, choose the subdomain files.example.com, and press Install. Cloudron creates the DNS record, requests the Let's Encrypt certificate, provisions the database, wires up single sign-on, and schedules a backup, all without you touching a config file. This is the whole pitch, and it delivers.

TLS and backups. The strongest of the three. Every app subdomain gets an automatic Let's Encrypt certificate, renewed for you. Backups are scheduled and built in, targeting a local directory, S3, or other remote storage, with per-app restore and even one-click cloning of an app to a new subdomain.

Cost and licensing, read this before you commit. Cloudron is a paid product with a capped free tier: the free plan allows two apps and five users. Install a third app and you hit a paywall; a paid subscription (Pro or Max, billed monthly or yearly, both with unlimited apps) unlocks more. That is the single most important fact about Cloudron. It is polished precisely because it is a business, and the free tier is closer to an extended trial than a home for a growing stack.

Failure mode, the clean-box rule. Try to install Cloudron on a server that already runs something and setup aborts before it changes anything:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

The cause is not fussiness for its own sake. Cloudron pins specific versions of nginx, Docker and Node and integrates them deeply, so it cannot coexist with your own copies. The fix is a fresh Ubuntu 24.04 image and nothing else: no web server, no Docker, not even a firewall you configured by hand. If you booted the wrong image, setup also refuses anything that is not Ubuntu 24.04 (Noble) on x86-64; ARM, LXC and OpenVZ are unsupported outright.

Second failure mode, wildcard certs need DNS API. Pick the "Manual" DNS option during setup instead of giving Cloudron an API token, and it cannot create records or a wildcard certificate for you. Each new app then makes you add a DNS record by hand before the certificate can be issued, and the dashboard sits waiting on that record. Give Cloudron API access to a supported DNS provider (Cloudflare, Route 53, DigitalOcean, and others) and the whole flow becomes one click.

CasaOS: the free home-lab dashboard

What it is. CasaOS, from IceWhale, is a free and open-source dashboard that sits on top of Docker and gives you a home screen, an app store, and a file manager. It grew out of the home-server world, so its instincts are home-lab: fast to set up, friendly UI, and light on ceremony. It targets tinkerers who want a nicer face on Docker without paying anyone.

Install. One line, and it does not demand a clean box:

curl -fsSL https://get.casaos.io | sudo bash

The installer adds a set of systemd services (casaos, casaos-gateway, casaos-app-management, and friends). Confirm the gateway came up before you open a browser:

systemctl status casaos-gateway

When it is running, the dashboard is at http://<your-ip> (plain HTTP, port 80). Create a local account and you are in.

Adding a first app. Open the App Store, pick an app, click Install. CasaOS writes a Docker Compose project behind the scenes and exposes the app on a host port, for example http://<your-ip>:8080. Its store carries the usual home-server line-up, so a Jellyfin media server on a VPS or a self-hosted Immich photo library is a couple of clicks away. You can also import any docker-compose.yaml you like, which is the real strength: the apps are ordinary containers, not a proprietary format.

TLS and backups, the weak spot. This is where "free" shows its edges. CasaOS serves everything over plain HTTP by default, including its own dashboard. There is no built-in Let's Encrypt, and no built-in scheduled backup. Your data lives in Docker volumes under /DATA, and backing it up is your job (a cron'd restic or tar).

Failure mode, no TLS, and it is silent. Nothing errors out. You install an app, open http://<your-ip>:8080, and it works, over an unencrypted connection your browser marks "Not Secure." Passwords and session cookies cross the wire in cleartext. Worse, CasaOS has had real remote-code-execution vulnerabilities in its dashboard (CVE-2023-37265 and CVE-2023-37266, an authentication bypass that chained into full host compromise), so exposing that HTTP port straight to the internet is a genuine risk, not a stylistic quibble. The fix is to never expose CasaOS directly. Put a reverse proxy in front that terminates TLS, such as nginx with a Let's Encrypt certificate from Certbot, Caddy, or a Cloudflare Tunnel, and forward to CasaOS on the local network only. Note that CasaOS already binds port 80, so your proxy and CasaOS will fight over it unless you move CasaOS to another port first.

Cost. Genuinely free, forever, no app cap. You pay in operations: you own TLS, backups, and hardening yourself.

Coolify: the self-hosted PaaS

What it is. Coolify is an open-source, self-hosted platform-as-a-service, in the mould of Heroku or Vercel on your own box. Its native unit is not "install this packaged app" but "deploy this Git repository": connect a repo, and Coolify builds it (via Nixpacks or your own Dockerfile) and ships it, redeploying on every push. It also has one-click databases and services. It targets developers who deploy their own code and want push-to-deploy without renting a PaaS.

Install.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

The script installs Docker and brings up Coolify's own stack of containers. Check they are healthy before you go further:

docker ps --format 'table {{.Names}}\t{{.Status}}'

You should see coolify, coolify-db, coolify-redis, coolify-realtime, and coolify-proxy all reporting Up. The dashboard is at http://<your-ip>:8000. Create your admin account immediately, because the registration page is open until the first account is made, and whoever reaches it first controls the server. Then set your instance domain and point a wildcard DNS record (*.example.com, or *.apps.example.com) at the box so Coolify can hand every deployed app its own subdomain.

Adding a first app. Connect a Git source (GitHub, GitLab, or a plain repo URL), pick a branch, set the domain, and deploy. Coolify's built-in Traefik proxy routes the subdomain and requests the certificate. For off-the-shelf software, the Services catalogue deploys things in a couple of clicks: the same n8n workflow-automation stack you might otherwise wire up by hand is one entry, and so is Uptime Kuma for status-page monitoring.

TLS and backups. Automatic per-app Let's Encrypt through the bundled Traefik, so every deployed subdomain gets a certificate. Backups are database-first: you can schedule Postgres and MySQL dumps to S3-compatible storage. Whole-instance backup (the Coolify configuration itself, which lives under /data/coolify) is more manual, so export and store that yourself.

Cost and licensing. The self-hosted edition is fully open-source and free, no app cap. There is an optional Coolify Cloud (paid) that hosts the control plane for you while your apps still run on your own servers, convenient but not required.

Failure mode, the app deploys but its domain will not load. The dashboard works fine on http://<ip>:8000, the build goes green, but the app's own URL returns a connection error or a Traefik 404 page not found. That points at the proxy or at DNS, not at your app. Two common causes. First, ports 80 or 443 were already taken when the proxy tried to start, so its container died with a Docker error:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Second, the wildcard DNS record is missing, so Traefik never receives a request for that hostname. If instead the whole server card in Coolify reads "Server is not reachable," that is a different fault: Coolify cannot talk to the server's Docker socket at all, usually a stopped Docker daemon or a broken SSH key. Read the real reason in the logs before you guess:

docker logs coolify-proxy --tail 100

Fix it from the Proxy page: press Restart Proxy, or reset the proxy configuration to default and start it again, then wait about two minutes for it to settle. Keep port 8000 reachable from your own IP only (or re-open it temporarily when the proxy misbehaves) rather than leaving it open to the world — it serves the dashboard over plain HTTP, and Coolify's own docs say ports 8000, 6001 and 6002 can be closed once the dashboard is served through its own domain.

Resource overhead on the same VPS

Measured at idle on the same 4GB box, before deploying any real workload. Check yours with free -m and docker stats --no-stream rather than trusting any single number, because the total moves with your app mix.

• CasaOS is the lightest. The panel is a small set of Go services; expect roughly 150 to 300 MB of overhead on top of whatever containers you run.
• Coolify runs several support containers of its own (the app, a Postgres, a Redis, a realtime service, and Traefik), so it sits around 600 MB to 1 GB idle before you deploy anything.
• Cloudron is heaviest at rest, because it runs its own nginx, database, mail stack and monitoring whether or not you use them; budget 1 to 1.5 GB idle. That is why it asks for 2GB minimum and breathes easier at 4GB.

On a small 2GB VPS, CasaOS leaves the most room for real apps and Cloudron leaves the least. If your plan is 2GB and you want Cloudron with its mail server running, plan to upgrade the box.

Updates, backups, and lock-in compared

Updates. Cloudron updates the platform and every app for you on a schedule it has tested: the least effort and the most hand-holding. Coolify updates itself from its own dashboard with one button. CasaOS updates the panel through its install script or apt, but the apps you installed are yours to pull and restart.

Lock-in, the part that bites in year two. CasaOS is the least locked-in: its apps are ordinary Compose projects, so you can copy the docker-compose.yaml and the volumes under /DATA to any other host and carry on. Coolify sits in the middle: your deploys are your own Dockerfiles and repos, but their configuration lives in Coolify's database, so moving hosts means re-creating the projects on the other side. Cloudron is the most locked-in: apps are Cloudron-packaged, and while your data leaves cleanly through its excellent backups, the packaging does not, so you re-deploy on the destination platform. Portable data, non-portable plumbing.

Which one should you pick

Short version, then the exit ramp. Pick Cloudron if you want the least hands-on server of the three, will run several packaged apps, and will pay a yearly fee for managed TLS, backups and updates. Pick CasaOS if this is a home lab behind your own network or a reverse proxy, you want a friendly face on Docker, and you refuse to pay anything. Pick Coolify if you deploy your own code from Git and want push-to-deploy with automatic TLS, without the price of a hosted PaaS. If none of those three describes you, the next section is the honest answer.

Skip all three if...

Be honest about your scale. If you run only one or two apps, or you want to understand and control exactly what is on your box, skip the panels. The overhead and the lock-in are not worth it for a small, stable stack. The DIY path is a reverse proxy in front of your own Compose files: Traefik with automatic TLS in front of several Docker Compose apps gives you the one-click-equivalent HTTPS with none of the panel weight, and you back up with a cron'd restic job you actually understand.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

For a single flagship app the case is even clearer: a Nextcloud install on Docker with TLS and its own backup routine is one Compose file and one certificate. Standing up an entire appliance to run it would be all cost and no benefit. If you are still deciding what to run before you decide how, the guide to what is worth self-hosting in 2026 is the better starting point.

FAQ

Do I even need a self-hosting panel?

Only if you value the four things a panel automates, across several apps: one-click installs, automatic TLS, scheduled backups, and user management. For one or two services, plain Docker Compose behind Traefik does the same TLS job with far less overhead and zero lock-in. Panels pay off when you run many apps and your time is worth more than the RAM they cost.

Which panel is best for a beginner?

For a home lab where nothing is exposed to the hostile internet, CasaOS is the gentlest start: one command and a friendly UI, with no bill to pay. But you must put a TLS-terminating reverse proxy in front before exposing anything, because it ships plain HTTP. If you want managed TLS and backups handled for you and will pay for it, Cloudron is the most hand-holding, within its two-app free limit.

Is Cloudron free?

Partly. The free tier allows two apps and five users, which is fine for trying it or for a very small setup. Beyond that Cloudron is a paid subscription, billed monthly or yearly, with unlimited apps on the paid tiers. It is a commercial product with a capped free plan, not free software, so budget for it if your stack will grow.

Can I run these panels next to my existing apps?

Cloudron: no. It requires a clean Ubuntu box and aborts if nginx, Docker or Node are already installed, because it manages the whole machine. CasaOS and Coolify are friendlier, since they install their own Docker stack and can share a box in principle, but both want ports 80 and 443, so they collide with any web server or proxy you already run. On a box that already hosts things, a panel is usually the wrong tool; reach for Traefik and Compose instead.

How do I move off a panel later?

Plan your exit before you need it. From CasaOS, copy the app's docker-compose.yaml and its /DATA volumes to the new host and start them again. From Coolify, export each project's configuration and point it at the same repos on the destination. From Cloudron, restore data from its backups into freshly installed apps on the new platform, because the Cloudron packaging does not travel, only the data does. In every case, test the restore on a throwaway box before you tear down the old one.