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 .
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
| Feature | Coolify v4 | CapRover | Dokploy |
|---|---|---|---|
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| GitHub Stars | ~44K | ~14K | ~12K |
| First release | 2021 | 2018 | 2024 |
| UI | Modern (React) | Bootstrap | Modern (React/Next.js) |
| Multi-server | ✅ | ✅ (Netdata nodes) | ✅ |
| Docker Compose | ✅ | ✅ | ✅ |
| Nixpacks/Buildpacks | ✅ (Nixpacks) | ❌ | ❌ |
| Dockerfile | ✅ | ✅ | ✅ |
| Git integration | ✅ (GitHub/GitLab/Bitbucket) | ✅ | ✅ (GitHub/GitLab) |
| One-click templates | 280+ | 100+ | 100+ |
| Database management | ✅ | ✅ | ✅ |
| Backup (S3) | ✅ | ✅ | ✅ |
| CLI | Limited | ✅ (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
- New Resource → Application → Public/Private Git repository
- Enter repo URL:
https://github.com/username/my-nextjs-app - Coolify auto-detects: Next.js → uses Nixpacks build pack
- Set environment variables
- 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:
- Application → Configuration → Previews
- Enable "Build PR Previews"
- 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
- Projects → Create Project (logical grouping)
- Add Service → Application
- Select source: GitHub/GitLab/Bitbucket or Docker image
- Set branch, build command, start command
- Configure domain + HTTPS
- 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
.envfile (not hardcoded in compose) - Container restart policy set to
unless-stoppedoralways - 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.