Comparison: Orca vs Coolify vs Dokploy vs Kubernetes
Choosing a container orchestrator comes down to how many nodes you run, how much operational complexity you’re willing to accept, and how much control you need over scheduling, networking, and secrets.
This page positions Orca in the landscape and explains when to pick it over the alternatives.
Docker Compose ──> Coolify / Dokploy ──> Orca ──> Kubernetes
(1 node) (1 node, GUI) (2-20) (20-10k)
Quick reference
| Feature | Coolify | Dokploy | Orca | Kubernetes |
|---|---|---|---|---|
| Target scale | 1 node | 1 node | 2-20 nodes | 20-10,000 nodes |
| Install | Docker image | Docker image | Single 47MB binary | Many components |
| Config format | GUI | GUI | TOML (on-screen) | YAML (multi-file) |
| State store | Postgres | Postgres | embedded redb (no etcd) | etcd cluster |
| Consensus | none | none | Raft (openraft) | Raft (etcd) |
| Multi-node | ❌ | ❌ | ✅ | ✅ |
| Auto-TLS | ✅ (Let’s Encrypt) | ✅ (Traefik) | ✅ (ACME built-in) | cert-manager addon |
| Reverse proxy | Traefik | Traefik | Built-in (hyper) | Ingress (addon) |
| WebSocket proxy | partial | partial | full | ingress-dependent |
| Secrets | GUI | GUI | AES-256 + ${secrets.X} templates | etcd + RBAC + Secrets API |
| Health checks | basic | basic | liveness + readiness + startup | Yes |
| Rolling updates | basic | basic | Yes + canary + drain | Yes |
| Wasm workloads | ❌ | ❌ | ✅ (wasmtime, WASI P2) | Krustlet (archived) |
| GPU scheduling | ❌ | ❌ | ✅ (NVIDIA + AMD ROCm) | Device plugins |
| AI ops | ❌ | ❌ | orca ask, alerts, auto-remediate | ❌ |
| GitOps | webhook | webhook | webhook + infra-repo auto-pull | ArgoCD / Flux |
| Self-update | Docker pull | Docker pull | orca update | cluster upgrade tooling |
| Config per service | GUI forms | GUI forms | ~10 lines TOML | ~50-100 lines YAML |
| External deps | Docker, Postgres | Docker, Postgres | Docker only | etcd, CoreDNS, CNI, kubelet, … |
| Learning curve | Low | Low | Low | High |
| Binary size | Docker image | Docker image | 47 MB | N/A (many components) |
When to pick Coolify or Dokploy
- You have one server, one team, and you like a web UI.
- You want to click-deploy WordPress, Ghost, Plausible, Supabase, etc.
- You don’t need multi-node HA.
- You don’t plan to scale beyond a single box.
Both tools are excellent for this niche. They give you push-to-deploy from GitHub, Let’s Encrypt certs, and a friendly GUI.
When to pick Orca
- You run 2 to 20 nodes (or plan to).
- You want config as code (TOML in git) over a GUI.
- You need Wasm workloads alongside containers.
- You want GPU scheduling with both NVIDIA and AMD support.
- You want AI operations —
orca ask "why is the API slow?". - You want a single binary with zero external dependencies (no etcd, no Postgres, no cert-manager).
- You need real multi-node clustering with Raft consensus.
- You care about auditable config that fits in a git diff.
- You value simplicity: 47 MB binary, 10-line service configs, systemd unit.
When to pick Kubernetes
- You run 50+ nodes or expect to.
- You need a massive ecosystem of operators, CNIs, service meshes.
- You have a platform team to operate the cluster.
- You need features Orca doesn’t have (yet): NetworkPolicies, PodDisruptionBudgets, CustomResourceDefinitions, Horizontal Pod Autoscalers, StatefulSets with complex volume strategies, multi-tenancy at enterprise scale.
Kubernetes is the right answer at scale. It just comes with a tax that most small-to-mid teams don’t need to pay.
Feature comparison: detailed
Config format
Coolify / Dokploy: GUI forms. Deploys are recorded in a database. Rolling back means clicking through history. Auditing means SQL queries.
Orca: TOML files in a git repo.
[[service]]
name = "api"
image = "myorg/api:latest"
port = 8080
domain = "api.example.com"
health = "/healthz"
[service.env]
DATABASE_URL = "${secrets.DB_URL}"
[service.resources]
memory = "512Mi"
cpu = 1.0
Kubernetes: Multiple YAML manifests (Deployment, Service, Ingress, ConfigMap, Secret) for the equivalent setup, usually generated by Helm.
Secrets
Coolify / Dokploy: Stored in the database, exposed via the GUI. Rotation is manual; auditing is limited.
Orca: ${secrets.X} template references in service.toml, resolved at
container creation time from an AES-256 encrypted local store. Templates
(not resolved values) are compared on reconcile so rotating a token
doesn’t trigger an unnecessary container restart.
Kubernetes: Secrets stored (base64-encoded) in etcd. Encryption at rest is opt-in. RBAC to control access. Integration with external secret stores (Vault, AWS Secrets Manager) requires operators.
Multi-node
Coolify / Dokploy: Single node only.
Orca: orca join <leader>:6880 --token <...> and the node is in the
cluster. Raft consensus via openraft, embedded redb storage, no external
state store. Services are pinned to nodes with
[service.placement] node = "gpu-box".
Kubernetes: kubeadm, kOps, or a managed offering. etcd quorum, API server, scheduler, controller manager, kubelet, kube-proxy, CNI plugin, CoreDNS — all must be healthy. Upgrades are multi-step.
GitOps
Coolify / Dokploy: Per-service webhooks. Push to a repo, CI builds an image, webhook triggers redeploy.
Orca: Same per-service webhooks plus an infra webhook — push
service.toml changes to your orca-infra repo and the master runs
git pull + orca deploy automatically. Entire cluster state is one git push
away.
Kubernetes: ArgoCD or Flux for GitOps. Powerful but adds another operator to maintain.
AI operations
Orca is the only option here. Works with any OpenAI-compatible API
(LiteLLM, Ollama, vLLM, OpenAI). Configure in cluster.toml:
[ai]
provider = "litellm"
endpoint = "https://llm.example.com"
model = "gpt-oss-120b"
api_key = "..."
Then:
orca ask "why is the API returning 503s?"— diagnoses issues with cluster context (services, logs, stats).- Conversational alerts — AI analyzes health every 60s and creates threaded conversations about anomalies.
- Smart import —
orca import compose docker-compose.ymlsuggests better service names and config improvements.
GPU workloads
Coolify / Dokploy: No GPU scheduling.
Orca: Declare GPUs in service.toml:
[service.resources.gpu]
count = 1
vendor = "nvidia" # or "amd"
vram_min = 8000 # MiB
The scheduler filters nodes by GPU availability. Docker passthrough
handles both NVIDIA (via --gpus / nvidia-container-toolkit) and AMD
(via /dev/kfd + /dev/dri device mounts with auto-detected GIDs).
Kubernetes: Device plugins. NVIDIA GPU Operator. AMD GPU Operator. Works well at scale but adds complexity.
Wasm workloads
Coolify / Dokploy: Containers only.
Orca: WebAssembly modules run natively via wasmtime alongside
containers. Cold start in ~5ms vs ~3s for containers. ~2 MB memory per
instance. Same service.toml format, different runtime:
[[service]]
name = "edge-handler"
runtime = "wasm"
module = "./dist/handler.wasm"
triggers = ["http:/api/hook"]
Kubernetes: Krustlet was the attempt. It’s archived. No production-ready Wasm story in mainstream K8s today.
The one-screen rule
Orca’s design goal: every service config fits on one terminal screen.
The same rule applies to cluster.toml, Cargo.toml dependencies, and
the architecture diagram.
If you spend more time managing the orchestrator than shipping features, you’ve picked the wrong tool. Coolify is great at the low end. Kubernetes is great at the high end. Orca fills the gap.
Migrating from Coolify
We migrated a real 20-service, 3-node production stack off Coolify onto
Orca. The step-by-step playbook lives in the
DevOps Guide.
Short version: inspect the source container, dump the DB, write the
service.toml, restore the DB, cut DNS over, tear down the old
containers after 24h.
Next steps
- Getting Started — install orca in 60 seconds
- Services — full service.toml reference
- Multi-Node — clustering, placement, GitOps
- AI Ops — configuring the AI assistant