Coolify vs Dokploy: when each one fits
A platform or infrastructure team that wants a self-hosted layer for apps, databases and previews on its own servers should start with licensing, because the two products draw the line in different places. Coolify suits teams that want a fully Apache-2.0 product with servers managed over SSH, and Coolify's pricing page describes the self-hosted edition as free forever with all features and no limitations. Dokploy suits teams that want Docker Swarm-based clustering and accept that its SSO with OIDC and SAML, SCIM, audit logs and custom roles sit in a source-available /proprietary directory under the Dokploy Source Available License 1.0, which permits production use only under a commercial agreement.
Four questions should drive the decision. First, does your identity and audit model depend on those proprietary components? If so, get a written answer from Dokploy on what production use requires before you build on them, and read Dokploy's license file with your legal team. Second, do you need Swarm? Dokploy clusters use Swarm managers and workers and need a Docker registry for image distribution, while Coolify manages each server over SSH and runs one coolify-proxy container per server. Third, how will you host previews and backups? Coolify builds previews from GitHub, GitLab, Gitea and Bitbucket at a wildcard URL and deletes them on close or merge, but its scheduled backups skip Redis, Dragonfly and KeyDB. Dokploy's backups go to S3 destinations configured in its settings, so confirm which databases your stack needs covered.
Fourth, do you plan to resell hosting? Dokploy's terms forbid commercial resale or redistribution of Dokploy as a service without explicit consent, so a managed-hosting business case needs that consent in writing before it is designed. Coolify's Apache-2.0 license carries no such restriction in the supplied facts, but confirm its terms with counsel for your own use case. Also check the hardware floors: Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, while Dokploy needs at least 2 GB RAM and 30 GB of disk.
Which platform fits which team situation
This table maps common team situations to the platform that fits better, the condition that drives the choice, and where the other option still works. Read each row against your own servers, identity requirements and licensing exposure, since the open-source boundary in Dokploy changes the answer for regulated and resale use cases.
| Situation | Better fit | Condition that decides it | Where the other platform is workable |
|---|---|---|---|
| Single team running internal apps on its own servers | Coolify | Team wants the full feature set under Apache-2.0 with no feature gating, and expects to use multiple build packs and databases. | Dokploy works well here if the team is comfortable with its Traefik and Swarm-based installer and does not need the proprietary features. |
| Regulated organization that needs SSO, SCIM and audit logs | Dokploy, only under a commercial agreement | SSO with OIDC or SAML, SCIM and audit logs sit in the proprietary directory and are licensed for production use only under a commercial agreement with Dokploy. | Coolify is the choice if SSO and audit logging are handled outside the platform, or if the organization can accept that Coolify's feature set is evaluated on its own terms; confirm current identity features with the vendor. |
| Team that wants Docker Swarm clustering | Dokploy | Dokploy's cluster model uses Docker Swarm manager and worker nodes, and the team accepts a Docker registry and vertical scaling first. | Coolify's multi-server deployments are workable for teams that want to manage several servers over SSH without Swarm, but confirm the clustering behavior you need in Coolify's multi-server documentation. |
| Team reselling hosted apps to its own customers | Neither without legal review; Coolify has fewer license restrictions | Dokploy's terms forbid commercial resale or redistribution of Dokploy as a service without explicit consent, and Coolify's license is Apache-2.0. | Dokploy can be used for resale only with written consent from the Dokploy team, so get that in writing before building a service on it. |
| Team wanting per-server managed billing | Coolify Cloud or Dokploy Hobby, depending on server count | Coolify Cloud charges $5 per month for 2 connected servers plus $3 per month for each additional server, and Dokploy Hobby is $4.50 per month per server for one server. | Self-hosting either platform avoids the managed fee but moves upgrades and control plane availability to your team; ask each vendor what is included. |
| Team that needs a broad database and backup set | Coolify | Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, with S3-compatible upload and retention rules. | Dokploy covers Postgres, MySQL, MariaDB, MongoDB and Redis with S3 backups, which suits teams whose stack does not need ClickHouse. |
| Team that wants preview deployments per pull request | Coolify | Coolify previews support GitHub, GitLab, Gitea and Bitbucket and need wildcard DNS for the default URL pattern. | Dokploy also offers preview deployments, so compare the Git providers and DNS setup against your workflow in its documentation. |
| Solo developer or small team on one small server | Either, based on the build method you prefer | Both need Linux and Docker; Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, while Dokploy needs at least 2 GB RAM and 30 GB of disk. | Pick the build method and dashboard that match your workflow, and size disk first because Dokploy's minimum is larger. |
How Coolify and Dokploy connect to your servers
Both platforms run your applications on Docker hosts you own, but they reach those hosts differently. Coolify manages each server over SSH with a proxy container per host, while Dokploy's installer builds a Docker Swarm and opens fixed ports. The cards below cover what that difference means for proxies, firewalls, node additions and where failures land.
SSH-managed servers in Coolify
Coolify connects to each server over SSH, prepares it to run Docker workloads and deploys from there. The access it needs is an SSH user with Docker rights, so the key handling, the user account and the allowed source addresses become part of your security review. Confirm which account Coolify uses, where its private key is stored, and whether your bastion or jump host policy allows that connection before you add the first server.
One proxy container per server
Coolify runs one coolify-proxy container on each server. Traefik is the default, Caddy is the alternative, and both obtain and renew HTTPS certificates automatically. The Custom (None) option hands routing and TLS entirely to you, which suits teams with an existing ingress layer but moves certificate renewal and routing rules into your runbook. Decide the proxy per server before go-live, and test it on a staging host first.
Swarm set up by the installer
Dokploy's installer sets up Docker Swarm, and its clusters use Swarm manager and worker nodes. Swarm is a different orchestration layer from the per-host Docker model that Coolify uses, so you need to understand manager quorum, node labels and the overlay network before you rely on it. Dokploy's docs recommend scaling vertically first because horizontal scaling needs more configuration. Confirm how many managers you will run and how they are placed across failure domains.
Fixed ports 80, 443 and 3000
Dokploy uses ports 80 and 443 for Traefik and port 3000 for its web interface. Those ports are predictable, so they are easy to document, but they are also the first ports an attacker scans. Coolify does not publish a fixed port list in the facts supplied here, so check its installation docs and your own host baseline before writing firewall rules. Restrict port 3000 to administrator networks wherever your design allows it.
Adding nodes and where failures land
In Coolify, a new server joins by SSH registration and carries its own proxy, so a failed host affects the applications placed on it. In Dokploy, a failed manager can affect cluster state, and the Swarm registry must reach every node to distribute images. Ask each vendor how a single host loss is recovered, what state lives on the control node, and whether an in-place backup of that state is documented. Test node loss in a non-production cluster before you commit.
Network design you must confirm
Before choosing either model, confirm three points in your own network: whether hosts accept inbound SSH from the control plane, whether the proxy ports are reachable from your load balancer or the internet, and whether your registry or image pull path is reachable from every node. Also confirm DNS, because both platforms rely on domains pointing at the right host. These answers depend on your segmentation, so write them down with your network team rather than assuming defaults.
Coolify vs Dokploy feature by feature
This table compares how Coolify and Dokploy handle build methods, databases and backups, S3 destinations, clustering, preview deployments and minimum hardware. Read each row against your own stack, since a gap in one column may matter only for your workload. Where a capability is not confirmed in the supplied facts, the cell says what to verify before you decide.
| Capability | Coolify | Dokploy |
|---|---|---|
| Build methods | Nixpacks, Railpack (beta), Static, Dockerfile and Docker Compose from Git, plus a Docker Image method that skips the build and pulls an existing image | Nixpacks (default), Railpack, Dockerfile, Heroku Buildpacks (Heroku 24 default), Paketo Buildpacks and Static sites served from NGINX |
| Buildpack choice | Nixpacks and Railpack only, no Heroku or Paketo buildpacks listed; confirm if you rely on Cloud Native Buildpacks | Includes Heroku and Paketo buildpacks, useful if your existing apps already build with them |
| Database engines | PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB and ClickHouse | Postgres, MySQL, MariaDB, MongoDB and Redis |
| Scheduled backup coverage | PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse; not Redis, Dragonfly or KeyDB | Automated backups to S3 destinations; confirm which engines are covered before relying on it |
| Backup format and retention | PostgreSQL uses pg_dump custom format, cron schedules, retention by count, days or size, and Import Backup for several dump types | Backups go to S3 destinations configured in settings; confirm format and retention options in your version |
| S3-compatible backup destinations | Backups can be uploaded to S3-compatible storage | Configured S3 destinations in settings; test your target endpoint before production use |
| Multi-server model | Connects to each server over SSH and prepares it for Docker workloads | Remote servers plus Docker Swarm manager and worker nodes; a Docker registry is needed to distribute images |
| Clustering guidance | Multi-server deployments managed per server; confirm cluster behavior against the multi-server docs for your layout | Vertical scaling recommended first, since horizontal scaling needs more configuration |
| Preview deployment providers | GitHub (App or webhook), GitLab, Gitea and Bitbucket | Confirm supported Git providers for previews in the current Dokploy preview docs before choosing |
| Preview URL pattern | Default {{pr_id}}.{{domain}}, which needs wildcard DNS; deleted when the request closes or merges | Confirm URL pattern and cleanup behavior in your version before relying on it |
| Minimum hardware | At least 2 CPU cores, 2 GB RAM and 10 GB free disk on Linux (amd64 or arm64) | At least 2 GB RAM and 30 GB disk, tested on Ubuntu 18.04 to 24.04, Debian 10 to 12, Fedora 40, CentOS 8 and 9 |
What each license allows and what is paid for
Coolify is licensed under Apache-2.0, and the self-hosted edition is free forever with all features and no limitations or restrictions, according to Coolify's pricing page. Your license cost for the software itself is zero, so the recurring spend sits in the servers you run, the time to operate them and any optional hosted service.
- Self-hosted edition: All features ship under the same Apache-2.0 license, so SSO, team features and multi-server deployment are not gated behind a paid tier.
- Coolify Cloud: The hosted control plane costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing. Your apps still run on servers you bring.
- What the cloud fee buys: Coolify runs the dashboard on its managed infrastructure, so you pay for control plane operation rather than for software features.
- What stays yours: Servers, backups storage, DNS, upgrades and on-call response remain your responsibility under either option.
- Cost drivers: Server count, annual versus monthly billing and how many servers you run in each environment.
Before committing, confirm with Coolify which features and support, if any, the hosted plan changes, and compare the cloud fee against the staff time you would spend running the dashboard yourself.
Dokploy's LICENSE.MD applies the Apache License 2.0 to all code outside /proprietary directories. The core platform, including its build types and deployment tooling, is therefore open source, but the enterprise controls live in a separate source-available component. Read the license at the file level rather than assuming the whole repository is Apache-2.0.
- Apache-2.0 core: Code outside the proprietary directories is Apache 2.0 licensed, which covers the platform's day-to-day deployment features.
- Dokploy Source Available License 1.0: Code inside /proprietary falls under this license, which allows production use only under a commercial agreement with Dokploy.
- Proprietary features: SSO with OIDC and SAML, SCIM, audit logs, custom roles and license key handling sit in that proprietary code, so they are source-available rather than Apache 2.0.
- Pricing tiers: Hobby is listed at $4.50 per month per server (1 server, 1 organization, 1 user), Startup from $15 per month with up to 3 servers and basic RBAC, and Enterprise, cloud or self-hosted, with SSO/SAML, SCIM, audit logs and an SLA at contact-sales pricing.
- Enterprise cost: Enterprise pricing is not published, so a quote follows from your server count, user count and support needs.
Before deploying, ask Dokploy in writing whether your production use of the proprietary components needs a commercial agreement and what the Enterprise terms include.
The identity and audit features that regulated teams often need are the ones Dokploy places behind its commercial terms. If your access review or audit trail requirements depend on SSO, SCIM or audit logs, those requirements can drive the licensing decision more than the core platform does.
- Identity controls: SSO with OIDC and SAML and SCIM provisioning appear in the Enterprise tier, and the Startup tier lists only basic RBAC.
- Audit logging: Audit logs are listed with the Enterprise tier and are part of the proprietary code.
- Custom roles: Custom roles are in the proprietary code, so fine-grained authorization depends on the commercial agreement.
- Support terms: An SLA is listed with Enterprise only, and the terms should be confirmed in writing.
- Self-hosted or cloud: Enterprise is offered in both forms, so confirm where the proprietary components run and who holds the license key.
Ask for the Enterprise contract terms, the list of proprietary modules covered and the license key handling before you design access controls around them.
Resale is the point where the two models differ most. Coolify's Apache-2.0 license grants the usual rights to use, modify and redistribute the code under its terms. Dokploy's TERMS_AND_CONDITIONS.md calls core free and open source but forbids commercial resale or redistribution of Dokploy as a service without explicit consent from the Dokploy team.
- Coolify: Apache-2.0 permits offering the software to others under the license terms, subject to the license conditions and trademark rules, so confirm specifics with counsel.
- Dokploy core: The Apache 2.0 code can be used under that license, but the terms prohibit commercial resale or redistribution as a service without consent.
- Dokploy proprietary code: Production use of /proprietary code requires a commercial agreement, which affects managed-service and internal platform offerings alike.
- Internal use: Running either platform for your own organization is a different question from selling hosted deployments to customers.
- Cost of consent: Any consent or commercial terms for resale are not published, so they belong in the quote.
Before you offer a hosted deployment service to customers, get written answers from both vendors and your legal team on the exact permitted use.
What drives the running cost of each platform
The running cost of Coolify and Dokploy splits into servers, staff time and, for Dokploy, licensing. Coolify's self-hosted edition is Apache-2.0 and its pricing page describes it as free forever with all features, so the license line is zero and the cost sits in the servers you run and the people who operate them. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk per server, while Dokploy needs at least 2 GB of RAM and 30 GB of disk. Those minimums set the floor for each node, and a larger disk footprint on Dokploy is a line item to check against your provisioning plan. Coolify Cloud is a separate recurring fee, $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. That fee covers the managed Coolify instance only, not the servers your apps run on.
Dokploy's cost is shaped by its open-core split. The Apache-2.0 core is free to run, but the /proprietary code that holds SSO with OIDC and SAML, SCIM, audit logs and custom roles is governed by the Dokploy Source Available License 1.0, which allows production use only under a commercial agreement. Dokploy's public Hobby and Startup tiers do not list SSO, SCIM or audit logs, and the Enterprise tier, cloud or self-hosted, is priced on contact. Before you compare totals, ask Dokploy in writing which tier includes SSO, SCIM and audit logs for your server count and user count, whether the agreement covers production use of the proprietary modules, whether it renews annually, and what support or SLA is included. Ask Coolify for the same written statement of what, if anything, it charges for your use case, since its self-hosted edition is unrestricted under Apache-2.0.
Staff time recurs for both platforms and grows with server count, backup scope and upgrade frequency. Set up a recurring time budget for backup verification, since Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse but not Redis, Dragonfly or KeyDB, and Dokploy's database backups go to S3 destinations you configure. Any database outside those lists needs a separate backup process, which adds recurring effort. Dokploy clusters on Docker Swarm also need a registry and extra configuration once you move past vertical scaling, which its docs recommend first. Ask your implementation partner for a fixed-scope estimate covering installation, backup design, restore testing, upgrade windows and documentation, and ask them to name which of those tasks recur each month and which happen once.
Moving apps and databases between the two platforms
This sequence moves applications and databases from one platform to the other while keeping the old environment running until each service is confirmed on the new one. The result is a documented cutover with a rollback path and a clear list of what you must rebuild by hand.
Inventory apps, build methods and dependencies
The platform team lists every application, its source (Git repository, Dockerfile, Compose file or prebuilt image), its build method, environment variables, persistent volumes, attached databases and the domains it serves. Coolify build packs (Nixpacks, Railpack, Static, Dockerfile, Docker Compose, Docker Image) and Dokploy build types (Nixpacks, Railpack, Dockerfile, Heroku Buildpacks, Paketo Buildpacks, Static) do not map one to one, so mark any app whose build method must change. Done when the inventory is reviewed by the application owners and each entry has a target build method on the new platform.
Export database backups from the source
The database owner takes a fresh backup from the source platform and stores it outside both platforms. On Coolify, scheduled PostgreSQL backups use the pg_dump custom format and can be uploaded to S3-compatible storage. Dokploy offers automated backups to S3 destinations configured in its settings. Confirm the backup format each platform produces for your database engine in the current documentation, and confirm that Redis, Dragonfly and KeyDB have a separate export path, since Coolify's scheduled backups do not cover them. Done when a backup file exists in storage you control and its checksum is recorded.
Rebuild databases and restore data on the target
Create the database service on the target platform and restore the backup into it. On Coolify, Import Backup accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps, which covers the custom-format file from the previous step. Dokploy's restore path should be confirmed against its database documentation before you rely on it. Run row counts and a sample of application queries against the restored copy. Done when the restored database matches the source counts and the application owners sign off on a test connection.
Recreate services, domains and proxy routing
Redeploy each application on the target platform using the build method chosen in the inventory, then re-enter environment variables and secrets from your own secret store, not from an export of the old platform. Attach each domain and confirm how TLS is issued. Coolify runs a coolify-proxy container on each server with Traefik or Caddy by default, and Dokploy routes through Traefik. Proxy rules, middlewares and custom headers are configured per platform and must be recreated. Done when each service answers on a staging hostname with the expected certificate and headers.
Reconfigure preview webhooks and wildcard DNS
If your teams use preview deployments, recreate the Git provider integration (GitHub App, webhook, GitLab, Gitea or Bitbucket) on the target platform and define the preview URL pattern. Coolify's default pattern uses {{pr_id}}.{{domain}} and needs wildcard DNS. Confirm the equivalent URL pattern and DNS requirement for Dokploy's preview deployments in its documentation. Open a test pull request and confirm the build, the generated URL and the automatic cleanup when the request closes. Done when one test preview has been created and removed on the new platform.
Cut over DNS and verify production traffic
Lower the TTL on production records well before the change window, using the lead time your DNS provider and resolvers require. At cutover, point the production records to the target platform, then run smoke tests, health checks and a transaction check against the database. Keep the source environment running and its databases read-only until the owners confirm stability. Done when the production checks pass, the error rate matches the baseline agreed in advance, and the rollback steps have been rehearsed.
Confirm what did not transfer
Work through a written list of items that do not move with a backup or a Git repository: the Docker Swarm topology and manager or worker placement used by Dokploy clusters, proxy configuration, user accounts, roles and permissions, API tokens, webhook secrets, scheduled backup jobs and retention rules, and SSO or SCIM settings. Confirm each item against the current Coolify and Dokploy documentation, since behavior changes between releases. Recreate each item deliberately and record who owns it. Done when every item on the list has an owner and a verified state on the target platform.
Decommission the source platform
After a monitored period agreed with the application owners, remove the old applications, databases and proxy containers, then revoke the source platform's SSH keys, API tokens and cloud credentials. Retain the final backups and the migration record under your retention policy. Before shutdown, check the source license terms for any obligations that continue after use, and confirm with the vendor whether any commercial agreement needs to be closed. Done when the source hosts no production workloads, its credentials are revoked, and the migration record is filed.
Where implementation projects usually run long
The most common source of overrun is not the installer but the work around it. For Coolify, the install itself is a single script on a supported Linux host with at least 2 CPU cores, 2 GB RAM and 10 GB free disk, and Coolify then connects to each managed server over SSH to prepare it for Docker workloads. For Dokploy, the installer sets up Docker Swarm, uses ports 80 and 443 for Traefik and port 3000 for the web interface, and needs at least 2 GB RAM and 30 GB disk. Before work starts, confirm the distribution and version against each vendor's supported list, confirm that the SSH keys and firewall rules for every server are agreed, and confirm that ports 80, 443 and 3000 are free on each Dokploy host. Wildcard DNS and TLS are the other early blockers: Coolify's preview URLs use a default {{pr_id}}.{{domain}} pattern that needs wildcard DNS, so the DNS zone owner should be in the kickoff.
Backups and restore testing are where projects most often slip. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so any cache that holds data you must keep needs a separate plan. Dokploy's database docs describe automated backups to S3 destinations configured in its settings, and that list does not include a restore procedure, so ask the vendor to confirm what restore paths exist for your database types. Build a restore test into the scope with a named owner, a target environment and a pass or fail criterion. Identity integration is the other frequent overrun. Dokploy's SSO with OIDC and SAML, SCIM and audit logs sit in source-available code under its proprietary license, so the identity work depends on a commercial agreement that should be signed before configuration begins.
Multi-server networking and clustering carry the largest unknowns. Dokploy clusters use Docker Swarm manager and worker nodes and need a Docker registry to distribute images, and its docs recommend vertical scaling first because horizontal scaling needs more configuration. Plan the registry, the node network and the failover test as separate deliverables rather than assuming they come with the install. Coolify's multi-server model connects each server directly over SSH, so the work there is mostly network reachability, key management and per-server proxy checks. Make the licensing decision before design, not after: Dokploy's terms forbid commercial resale or redistribution of Dokploy as a service without consent, and a late decision on whether you will offer hosted apps to others can force a rebuild. Ask DeployOpen or your vendor for a written scope that lists each of these items, the owner of each, and the evidence that proves it works.
Questions buyers ask before choosing Coolify or Dokploy
What does running Coolify or Dokploy cost each month?
Self-hosted Coolify has no license fee, because its Apache-2.0 edition is free forever with all features and no limitations, so your spend is servers, storage and staff time. Coolify Cloud adds a managed control plane at $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing. Dokploy's paid tiers are Hobby at $4.50 per month per server for one server and one user, and Startup from $15 per month for up to 3 servers with basic RBAC. Its Enterprise tier, cloud or self-hosted, is quoted through contact sales. On both managed plans, recurring cost grows with server count. Ask each vendor to confirm current pricing, and request a fixed-scope quote from DeployOpen, which does not publish prices.
How long does it take to deploy Coolify or Dokploy?
No duration for either platform is supplied here, so treat any single number you hear as unverified. Setup time mostly depends on how many servers you connect, whether Docker, DNS and TLS are already planned, and how many databases and backups you configure. Coolify installs with a single script on a supported Linux host with at least 2 CPU cores, 2 GB RAM and 10 GB of free disk. Dokploy needs at least 2 GB RAM and 30 GB of disk, and its installer sets up Docker Swarm, with Traefik on ports 80 and 443 and the web interface on port 3000. Ask for a timeline in writing. DeployOpen agrees scope, deliverables and timelines in writing before fixed-scope work starts.
Does Dokploy require a paid plan for SSO and audit logs?
Yes, SSO with OIDC and SAML, SCIM, audit logs and custom roles sit in Dokploy's proprietary directories, which fall under the Dokploy Source Available License 1.0 and are not licensed under Apache 2.0. Production use of that code requires a commercial agreement with Dokploy. The pricing page lists SSO/SAML, SCIM, audit logs and an SLA under Enterprise, which is quoted through contact sales, while Startup from $15 per month includes basic RBAC. The supplied pricing does not confirm whether Startup includes SSO, so ask Dokploy in writing before you assume it. Coolify's self-hosted edition is Apache-2.0 and its pricing page describes all features as free without limitations. Confirm feature availability for the version you plan to deploy.
Can my team resell hosted apps on Coolify or Dokploy?
Dokploy's terms call its core free and open source but state that commercial resale or redistribution of Dokploy as a service is forbidden without explicit consent from the Dokploy team. Its proprietary code also needs a commercial agreement for production use, so a hosting business should obtain that agreement before serving customers. Coolify's self-hosted edition is licensed under Apache-2.0, and its pricing page describes all features as available without restrictions. The supplied facts do not include a resale clause from Coolify, so confirm with Coolify how Apache-2.0 applies to your offering, including any use of its name or branding. Have your counsel review both license texts before you sell hosted apps.
What skills does my internal team need to run each one?
Both platforms assume a Linux host, Docker and administrative access, but the skills differ at the edges. Coolify connects to each server over SSH and runs a coolify-proxy container per server, with Traefik as the default, Caddy as the alternative, or Custom (None) when your team owns routing and certificates. Dokploy is built on Docker and Traefik, and if you cluster, your team must understand Swarm managers, workers and a Docker registry for image distribution. Dokploy's docs recommend vertical scaling first because horizontal scaling needs more configuration. On either platform, someone must patch hosts, manage DNS and wildcard records for previews, and test restores. Map these skills against your team before choosing.
Can a small team run Coolify or Dokploy without outside help?
A small team can run either platform alone if it already operates Linux servers and Docker and has a named owner for backups, upgrades and incident response. The harder work is ongoing: testing restores, applying upgrades, and keeping TLS, DNS and secrets correct after changes. Coolify's self-hosted edition has no license fee, so a team with the skills can start without vendor involvement. Dokploy's paid tiers add vendor terms for proprietary features, and its Enterprise tier includes an SLA. DeployOpen can plan, implement, customize, harden, back up, upgrade and document either platform inside your infrastructure, and offers ongoing support and upgrades as retainers. Put handover and skills transfer into the written scope.
How do database backups compare between Coolify and Dokploy?
Both platforms deploy common databases, but backup coverage differs in the supplied facts. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. Its PostgreSQL backups use the pg_dump custom format, can upload to S3-compatible storage, and run on cron schedules with retention by count, days or size. Dokploy deploys Postgres, MySQL, MariaDB, MongoDB and Redis and offers automated backups to S3 destinations set in its settings. Confirm retention behavior, restore steps and how Redis data should be protected in your environment. Schedule a restore test before go-live, because a backup that has not been restored is unproven.
How DeployOpen helps teams choose and implement either platform
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Coolify vs Dokploy, that means helping the team decide which platform fits its licensing, server layout and feature needs, then delivering the chosen one in its own cloud accounts, data centers or air-gapped networks.
How we scope
- Written scope names the servers, cloud accounts or networks where Coolify or Dokploy will run.
- Scope records which Dokploy features sit in source-available code and whether the team needs them.
- Scope lists the databases, backup targets and preview deployment Git providers the team will use.
How we build
- Installation covers host preparation, reverse proxy choice and wildcard DNS for preview deployments.
- Database backups are configured and tested against the engine types each platform actually supports.
- Build pack, multi-server or Swarm layouts are implemented only as far as the agreed written scope allows.
How we hand over
- Handover documents the configuration, backup restore steps and upgrade path for the chosen platform.
- Runbooks explain how to add servers, rotate credentials and remove preview deployments safely.
- Licensing notes record which code is Apache 2.0 and which terms apply to commercial use.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades, backup verification and periodic security testing of the platform.
- Clients can confirm support boundaries and quote details with DeployOpen against the written scope.
