Comparison

How OpenBerth compares to other self-hosted deployment platforms.

Overview

OpenBerth occupies a specific niche: AI-native, single-server deployments with a developer sandbox. Other platforms make different trade-offs. This page gives an honest comparison so you can pick the right tool for your situation.

All of these platforms are open source and self-hosted. The differences are in workflow, complexity, and what they optimize for.

vs Dokku

Dokku is a mini Heroku — a mature, battle-tested PaaS powered by buildpacks and git-push deploys. It’s been around since 2013 and has a large community.

How Dokku deploys

You add a git remote and git push dokku main. Dokku detects the language via buildpacks (Cloud Native Buildpacks or Herokuish), builds the app, and routes traffic to it. Configuration is done via CLI commands like dokku config:set and dokku domains:add.

Key differences

• No AI/MCP integration — Dokku predates the AI tooling era. There’s no way for Claude, Cursor, or other AI tools to deploy directly.
• No dev mode — Dokku is production-only. There’s no sandbox with hot reload for iterating on code.
• Buildpack knowledge required — When builds fail, you need to understand buildpack internals (Procfiles, buildpack ordering, slug compilation).
• No built-in data API — You provision databases separately via plugins.

Where Dokku shines

• Proven git-push workflow that’s been refined over a decade
• Rich plugin ecosystem (databases, caching, monitoring)
• Excellent documentation and community support
• Very stable and predictable

vs Coolify

Coolify is a full-featured PaaS — often described as a self-hosted Vercel/Heroku/Netlify alternative. It manages applications, databases, and services through a polished web dashboard.

How Coolify deploys

You connect a Git repository (GitHub, GitLab, Bitbucket) through the web UI, configure build settings, and Coolify handles the rest. It supports Docker Compose, Dockerfiles, buildpacks, and Nixpacks. It can also deploy 280+ one-click services (PostgreSQL, Redis, MinIO, etc.).

Key differences

• Much heavier — Coolify itself requires significant resources (recommended 2 CPU / 2 GB RAM minimum just for the platform). OpenBerth’s server binary is a single ~20 MB Go executable.
• No AI/MCP integration — No way for AI tools to deploy or manage apps programmatically via MCP.
• No hot-reload dev mode — Coolify is oriented around production deployments, not iterative development.
• More complex setup — Coolify runs its own Docker Compose stack with a database, Redis, and several background workers.

Where Coolify shines

• 280+ one-click service templates (databases, caches, monitoring tools)
• Multi-server support and clustering
• Polished web dashboard for teams who prefer GUI management
• Git-based auto-deploy with webhook integration

vs CapRover

CapRover is a Docker Swarm-based PaaS manager. It provides a web dashboard for deploying and managing containerized apps across a cluster.

How CapRover deploys

You create an app in the web dashboard, then deploy via the caprover deploy CLI, the web UI file upload, or a Dockerfile/Captain Definition file. CapRover builds a Docker image and runs it in Docker Swarm.

Key differences

• Docker Swarm complexity — CapRover is built on Swarm, which adds clustering capability but also operational complexity even for single-server setups.
• No AI integration — No MCP support or AI-native workflows.
• No dev mode — Production deployments only, no sandbox or hot reload.
• Dockerfile knowledge often needed — While CapRover has some auto-detection, complex apps typically need a Captain Definition or Dockerfile.

Where CapRover shines

• Built-in clustering via Docker Swarm (add worker nodes from the UI)
• One-click app marketplace with common services
• Good web dashboard for managing multiple apps
• Lets you use Docker Compose and Swarm features directly

vs Kamal

Kamal is a deployment tool from 37signals (the makers of Basecamp and HEY). It deploys Docker containers to bare servers using SSH — no PaaS layer on the server.

How Kamal deploys

You write a config/deploy.yml file specifying your servers, Docker image, environment variables, and Traefik proxy settings. Then kamal deploy builds the Docker image locally (or in CI), pushes it to a registry, SSHs into your servers, and starts the new containers with zero-downtime rolling deploys.

Key differences

• Requires Dockerfiles — Kamal doesn’t detect frameworks or generate build scripts. You write and maintain your own Dockerfile.
• No web dashboard — Kamal is purely CLI-driven. No gallery, no browser UI.
• No AI integration — No MCP support. Designed for human DevOps workflows.
• No dev mode — Kamal is a production deployment tool, not a development environment.
• Needs a Docker registry — You need a registry (Docker Hub, GHCR, etc.) to push images before deploying.

Where Kamal shines

• Multi-server deployments with zero-downtime rolling deploys
• No server-side daemon — just Docker and SSH
• Maximum control over the deployment process
• Battle-tested by 37signals running HEY and Basecamp
• Blue-green accessory deploys and built-in secrets management

Feature matrix

A side-by-side look at capabilities. ✓ = built-in, ~ = partial or plugin-based, — = not available.

When to use what

There’s no single best platform — it depends on what you’re building and how you work.

You can also combine platforms. For example, use Coolify for your PostgreSQL database and OpenBerth for your application code — they can run on the same server or different ones.