Skip to main content

Open-source alternatives guide

Coolify vs CapRover vs Dokploy 2026

Coolify v4, CapRover, and Dokploy compared in 2026. Self-hosted Heroku alternatives with one-click deploys, Docker support, and free tier replacements .

·OSSAlt Team
Share:

TL;DR

The self-hosted PaaS space has matured significantly in 2026. Coolify v4 leads with ~44K stars, the most polished UI, 280+ one-click templates, multi-server support, and active development. CapRover (~14K stars) is battle-tested with a large community. Dokploy is the new entrant (~12K stars, 2024) with a clean modern UI and growing fast. All three replace Heroku/Railway/Render for deploying web apps without managing individual Docker containers.

Key Takeaways

  • Coolify: Apache 2.0, ~44K stars — most features, best UI, multi-server, 280+ templates, Kubernetes support
  • CapRover: Apache 2.0, ~14K stars — mature, CLI-driven, largest template library (one-click-apps)
  • Dokploy: Apache 2.0, ~12K stars — newest, fastest-growing, clean UI, Traefik-based routing
  • All three: Free self-hosted, Docker Compose support, HTTPS auto, custom domains, metrics
  • Server requirements: 1GB RAM minimum for any (2GB recommended)
  • Migration from Heroku: Coolify has best compatibility with Heroku-style workflows

Feature Comparison

FeatureCoolify v4CapRoverDokploy
LicenseApache 2.0Apache 2.0Apache 2.0
GitHub Stars~44K~14K~12K
First release202120182024
UIModern (React)BootstrapModern (React/Next.js)
Multi-server✅ (Netdata nodes)
Docker Compose
Nixpacks/Buildpacks✅ (Nixpacks)
Dockerfile
Git integration✅ (GitHub/GitLab/Bitbucket)✅ (GitHub/GitLab)
One-click templates280+100+100+
Database management
Backup (S3)
CLILimited✅ (caprover CLI)✅ (dokploy CLI)
Kubernetes✅ (basic)
Real-time logs
Preview environments
RAM (idle)~400MB~200MB~300MB

Coolify v4: The Current Leader

Coolify v4 is a complete rewrite launched in 2024 with PHP + Livewire replacing the earlier Node.js codebase. It's become the de facto self-hosted Heroku for developers who want maximum features.

Install Coolify

# Official one-line install (Ubuntu/Debian):
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Or via Docker Compose:

# docker-compose.yml — minimal self-hosted Coolify
version: '3.8'

services:
  coolify:
    image: ghcr.io/coollabsio/coolify:latest
    volumes:
      - /data/coolify/source/.env:/var/www/html/.env
      - /var/run/docker.sock:/var/run/docker.sock
      - /data/coolify:/data/coolify
    ports:
      - "8000:8000"
      - "6001:6001"   # Soketi (WebSocket)
    environment:
      LARAVEL_SANCTUM_STATEFUL_DOMAINS: localhost
    restart: unless-stopped

Visit http://your-server:8000 → complete setup wizard.

Deploying an App

  1. New Resource → Application → Public/Private Git repository
  2. Enter repo URL: https://github.com/username/my-nextjs-app
  3. Coolify auto-detects: Next.js → uses Nixpacks build pack
  4. Set environment variables
  5. Click Deploy

Coolify handles:

  • Building (Nixpacks, Dockerfile, or Docker Compose)
  • Running via Docker
  • SSL via Traefik (Let's Encrypt)
  • Custom domain routing
  • Rolling deploys (zero downtime)

One-Click Services

Install databases and services with one click:

Resources → Add New Resource → Service
→ PostgreSQL 16, Redis, MongoDB, MinIO, Nextcloud, n8n, Plausible, Gitea, ...

280+ templates including every major OSS app.

Preview Environments

For pull requests, Coolify can auto-deploy a preview environment:

  1. Application → Configuration → Previews
  2. Enable "Build PR Previews"
  3. Each PR gets a unique URL: pr-42.yourdomain.com

This requires GitHub App integration.


CapRover: Battle-Tested and CLI-First

CapRover was one of the first self-hosted PaaS platforms and has the most mature CLI and captain-definition file format.

Install CapRover

# Single node install:
docker run -p 80:80 -p 443:443 -p 3000:3000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /captain:/captain \
  caprover/caprover

# Visit: https://captain.yourdomain.com:3000
# Default password: captain42

Deploy with CLI

npm install -g caprover

# Login:
caprover login
# Server URL: https://captain.yourdomain.com
# Password: your-password

# Deploy from current directory:
caprover deploy

CapRover uses captain-definition files:

{
  "schemaVersion": 2,
  "dockerfileLines": [
    "FROM node:20-alpine",
    "WORKDIR /app",
    "COPY package*.json .",
    "RUN npm ci --production",
    "COPY . .",
    "CMD [\"node\", \"server.js\"]"
  ]
}

Or reference a Dockerfile:

{
  "schemaVersion": 2,
  "dockerfilePath": "./Dockerfile"
}

CapRover One-Click Apps

Captain → Apps → One-Click Apps → Browse 100+ apps

Categories: databases, CMS, DevOps, productivity, etc.


Dokploy: The Modern Newcomer

Dokploy launched in 2024 and has grown quickly with a clean, modern UI. Built with Next.js, it feels more like a modern SaaS product than a self-hosted tool.

Install Dokploy

# One-line install:
curl -sSL https://dokploy.com/install.sh | sh

Visit http://your-server:3000 → create admin account.

Dokploy Architecture

Dokploy uses Traefik for routing (same as Coolify) and supports:

  • Applications: Git-based deploys with Dockerfile or Compose
  • Compose: Direct Docker Compose file deployment
  • Services: Managed databases (Postgres, MySQL, MongoDB, Redis, MariaDB)
  • Monitoring: Built-in metrics (CPU, RAM, disk, network per service)

Deploying Apps in Dokploy

  1. Projects → Create Project (logical grouping)
  2. Add Service → Application
  3. Select source: GitHub/GitLab/Bitbucket or Docker image
  4. Set branch, build command, start command
  5. Configure domain + HTTPS
  6. Deploy

Dokploy vs Coolify Decision

Choose Dokploy if:

  • You want the newest, most actively developing PaaS
  • You prefer a modern React/Next.js admin UI
  • Your team finds Coolify's PHP/Livewire UI less intuitive
  • You want Traefik-based routing

Choose Coolify if:

  • You need Nixpacks (auto-detect buildpacks)
  • You want 280+ one-click templates
  • Preview environments are important
  • You're migrating from Heroku-style workflows

Deployment Examples

Deploy a Next.js App (Coolify)

# Coolify detects this automatically via Nixpacks
# No configuration needed for standard Next.js apps

# Custom environment variables in Coolify UI:
DATABASE_URL=postgresql://user:pass@localhost/myapp
NEXTAUTH_SECRET=your-secret
NEXTAUTH_URL=https://app.yourdomain.com

Deploy a Docker Compose App (Any Platform)

All three platforms support deploying Docker Compose files directly:

# docker-compose.app.yml — deploy this to CapRover/Coolify/Dokploy
version: '3.8'

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf

  api:
    build: ./api
    environment:
      DATABASE_URL: "${DATABASE_URL}"
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  pg_data:

Decision Guide

Choose Coolify if:
  → You want the most features and polish
  → Preview environments are important
  → You need Nixpacks (auto-detect Node.js, Python, Go, etc.)
  → You're migrating from Heroku or Railway
  → Multi-server management in one dashboard

Choose CapRover if:
  → Your team is already familiar with it
  → CLI-first workflow is preferred
  → You want the most battle-tested platform
  → Simple, lower-resource-usage admin

Choose Dokploy if:
  → You want the most modern UI
  → Just getting started (newest features, active development)
  → You prefer Traefik routing over Nginx
  → You like the clean project-based organization

Skip all three if:
  → You're managing 1-2 simple apps (raw Docker Compose is fine)
  → You need Kubernetes at scale (use K3s + ArgoCD instead)
  → Your team has existing Docker/Kubernetes expertise

Compare all self-hosted PaaS options at OSSAlt.com/alternatives/heroku.

See open source alternatives to Coolify on OSSAlt.

Choosing a Deployment Platform

Before selecting a self-hosting stack, decide whether you want to manage Docker Compose files manually or use a platform that abstracts deployment, SSL, and domain management.

Manual Docker Compose gives you maximum control. You manage nginx or Traefik configuration, Let's Encrypt certificate renewal, and compose file versions yourself. This is the right approach if you want to understand every layer of your infrastructure or have highly custom requirements.

Managed PaaS platforms like Coolify or Dokploy deploy Docker Compose applications with SSL, custom domains, and rolling deployments through a web UI. You lose some control but gain significant operational simplicity — especially for multi-service deployments where managing compose files across servers becomes complex.

Server sizing: Self-hosted services have widely varying resource requirements. Most lightweight services (Uptime Kuma, AdGuard Home, Vaultwarden) run comfortably on a $5-6/month VPS with 1GB RAM. Medium services (Nextcloud, Gitea, n8n) need 2-4GB RAM. AI services with local model inference need 16-32GB RAM and ideally a GPU.

Networking and DNS: Point your domain to your server's public IP before deploying. Use Cloudflare as your DNS provider — it provides DDoS protection, free SSL termination at the edge, and the ability to hide your server's real IP. Enable Cloudflare's proxy mode for public-facing services; disable it for services that need direct TCP connections (like game servers or custom protocols).

Monitoring your stack: Use Uptime Kuma to monitor all services from a single dashboard with alerting to your preferred notification channel.

Network Security and Hardening

Self-hosted services exposed to the internet require baseline hardening. The default Docker networking model exposes container ports directly — without additional configuration, any open port is accessible from anywhere.

Firewall configuration: Use ufw (Uncomplicated Firewall) on Ubuntu/Debian or firewalld on RHEL-based systems. Allow only ports 22 (SSH), 80 (HTTP redirect), and 443 (HTTPS). Block all other inbound ports. Docker bypasses ufw's OUTPUT rules by default — install the ufw-docker package or configure Docker's iptables integration to prevent containers from opening ports that bypass your firewall rules.

SSH hardening: Disable password authentication and root login in /etc/ssh/sshd_config. Use key-based authentication only. Consider changing the default SSH port (22) to a non-standard port to reduce brute-force noise in your logs.

Fail2ban: Install fail2ban to automatically ban IPs that make repeated failed authentication attempts. Configure jails for SSH, Nginx, and any application-level authentication endpoints.

TLS/SSL: Use Let's Encrypt certificates via Certbot or Traefik's automatic ACME integration. Never expose services over HTTP in production. Configure HSTS headers to prevent protocol downgrade attacks. Check your SSL configuration with SSL Labs' server test — aim for an A or A+ rating.

Container isolation: Avoid running containers as root. Add user: "1000:1000" to your docker-compose.yml service definitions where the application supports non-root execution. Use read-only volumes (volumes: - /host/path:/container/path:ro) for configuration files the container only needs to read.

Secrets management: Never put passwords and API keys directly in docker-compose.yml files committed to version control. Use Docker secrets, environment files (.env), or a secrets manager like Vault for sensitive configuration. Add .env to your .gitignore before your first commit.

Production Deployment Checklist

Before treating any self-hosted service as production-ready, work through this checklist. Each item represents a class of failure that will eventually affect your service if left unaddressed.

Infrastructure

  • Server OS is running latest security patches (apt upgrade / dnf upgrade)
  • Firewall configured: only ports 22, 80, 443 open
  • SSH key-only authentication (password auth disabled)
  • Docker and Docker Compose are current stable versions
  • Swap space configured (at minimum equal to RAM for <4GB servers)

Application

  • Docker image version pinned (not latest) in docker-compose.yml
  • Data directories backed by named volumes (not bind mounts to ephemeral paths)
  • Environment variables stored in .env file (not hardcoded in compose)
  • Container restart policy set to unless-stopped or always
  • Health check configured in Compose or Dockerfile

Networking

  • SSL certificate issued and auto-renewal configured
  • HTTP requests redirect to HTTPS
  • Domain points to server IP (verify with dig +short your.domain)
  • Reverse proxy (Nginx/Traefik) handles SSL termination

Monitoring and Backup

  • Uptime monitoring configured with alerting
  • Automated daily backup of Docker volumes to remote storage
  • Backup tested with a successful restore drill
  • Log retention configured (no unbounded log accumulation)

Access Control

  • Default admin credentials changed
  • Email confirmation configured if the app supports it
  • User registration disabled if the service is private
  • Authentication middleware added if the service lacks native login

Conclusion

The decision to self-host is ultimately a question of constraints and priorities. Data ownership, cost control, and customization are legitimate reasons to run your own infrastructure. Operational complexity, reliability guarantees, and time cost are legitimate reasons not to.

The practical path forward is incremental. Start with the service where self-hosting provides the most clear value — usually the one with the highest SaaS cost or the most sensitive data. Build your operational foundation (monitoring, backup, SSL) correctly for that first service, then evaluate whether to expand.

Self-hosting done well is not significantly more complex than using SaaS. The tools available in 2026 — containerization, automated certificate management, hosted monitoring services, and S3-compatible backup storage — have reduced the operational overhead to something manageable for any developer comfortable with the command line. What it requires is discipline: consistent updates, tested backups, and monitoring that alerts before users do.

The self-hosted PaaS category exists to solve a specific problem: the operational overhead of managing multiple Docker Compose services across one or more servers exceeds what a small team wants to spend. These platforms — Coolify, CapRover, Dokploy — abstract SSL certificate management, proxy configuration, deployment webhooks, and multi-server orchestration behind a web UI. The right choice depends on whether you want active commercial backing (Coolify), maximum simplicity (CapRover), or the newest feature set (Dokploy). All three are significantly better than managing Compose files manually across multiple servers.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)

Step-by-step: infrastructure setup, data migration, backups, and security for 15+ common SaaS replacements. Used by 300+ developers.

Join 300+ self-hosters. Unsubscribe in one click.