Heroku alternative: when Dokploy fits and when Heroku still does
Heroku still fits when your team does not want to run servers. Managed dynos, Heroku Postgres and the rest of the add-on catalog remove patching, database backups and host capacity from your workload, and that is the main thing you pay for. Dokploy fits when your apps already run in Docker, when the servers must sit in a cloud account or data center you control, and when a per-server subscription is easier to justify than per-dyno billing. Dokploy's build options include Heroku Buildpacks (Heroku 24 by default), so many Procfile-based apps can move without a rewrite, but you should test each app's build before committing. Note that Dokploy's Hobby plan is listed at $4.50 per month per server, and the Startup plan is listed from $15 per month with up to 3 servers, both per the Dokploy pricing page. Confirm current prices there, since the cost that matters is your own servers, staff time and support.
Three decisions should settle the choice. First, decide whether SSO, SCIM or audit logs must be running in production. Dokploy's SSO with OIDC and SAML, SCIM, audit logs and custom roles live in the /proprietary directory under the Dokploy Source Available License, and that license allows production use only under a commercial agreement, so budget for the Enterprise tier if your access policy depends on them. Second, count your servers and decide whether you need clustering. Dokploy clusters use Docker Swarm and require a Docker registry, and its documentation recommends scaling vertically first. Third, name the owner of patching, operating system updates, database backups and restore tests. Dokploy's database docs describe automated backups to S3 destinations, but you still own the bucket, the retention policy and proof that a restore works. If no one on the team can take that on, Heroku or a managed alternative is the safer answer.
Which platform fits each buyer scenario
This table matches common buyer situations to the platform that usually fits better, and states the condition that makes each advantage matter. Read each row against your own constraints, since a single factor such as licensing or clustering can change the answer. The main takeaway is that Dokploy's strengths sit in self-managed control and Docker-based builds, while Heroku's strengths sit in managed operations and a single vendor for the runtime.
| Buyer scenario | Better fit | Why and when it matters |
|---|---|---|
| Small team, standard web apps, no server operations staff | Heroku | Heroku runs the platform, patching and the runtime for you. This matters when nobody on the team can own server updates, Docker upgrades and backups on a schedule. |
| Heroku buildpack apps moving to your own servers | Dokploy | Dokploy offers Heroku Buildpacks (Heroku 24 by default) as a build type, so many apps can keep their existing buildpack setup. Confirm that your buildpack stack and add-on dependencies build without changes before you commit. |
| Production need for SSO, SCIM or audit logs | Heroku or a paid Dokploy agreement | SSO with OIDC and SAML, SCIM, audit logs and custom roles sit in Dokploy's source-available proprietary code, which allows production use only under a commercial agreement. Ask Dokploy for written terms covering these features before relying on them. |
| Clustering across several servers | Heroku | Dokploy clusters use Docker Swarm and need a Docker registry to distribute images, and its docs recommend scaling vertically first. Choose Heroku when you need horizontal scaling without designing that cluster yourself. |
| Strict data location rules | Dokploy | Dokploy runs on servers you choose, so application data and database backups stay where your policy requires. Confirm where S3 backup destinations and the Docker registry store data before you rely on them for regulated workloads. |
| Teams already comfortable with Docker | Dokploy | Dokploy is built on Docker and Traefik, and its Dockerfile build type lets teams reuse their existing images. This matters most when operators already maintain Docker hosts and can troubleshoot them directly. |
| Teams staying on Heroku during the sustaining engineering period | Heroku | Heroku has said it is moving to a sustaining model focused on stability, security and support, not new features. Staying put is reasonable while your contract and needs hold, but plan the move on your own timeline and check renewal terms with Heroku. |
| Organization that needs a documented vendor support contract for the platform itself | Heroku | Heroku is a managed service with vendor-run operations. Dokploy offers paid tiers and an enterprise option with an SLA at contact-sales pricing, so compare the written support scope of each before deciding. |
Which Dokploy features are Apache 2.0 and which need a commercial agreement
The repository's LICENSE.MD applies the Apache License 2.0 to all code outside the /proprietary directories. That covers the core platform that builds and deploys applications, manages Docker and Traefik, and handles the general dashboard. Under Apache 2.0 you can read, modify, and run this code, and you can distribute it under the license's terms. Confirm the exact file boundaries for the version you deploy, because the license map is defined by directory paths in the repository.
- Deployment on your own servers: The core code that installs on your remote servers falls under Apache 2.0 when it sits outside the /proprietary directories.
- Modification: You can change core code for internal use under the terms of the Apache License 2.0.
- Databases and build types: Core features such as Postgres, MySQL, MariaDB, MongoDB and Redis deployments, plus Nixpacks and Heroku Buildpacks builds, sit in the core code area as described in Dokploy's documentation.
- Notices: Keep the license and notice files intact if you redistribute any part of the core code.
- Scope limit: Apache 2.0 does not grant rights to the proprietary directories, so a fork still inherits their restrictions.
Ask your engineers to map which files your deployment and any changes touch against the /proprietary paths before you rely on this split.
Code inside the /proprietary directories falls under the Dokploy Source Available License 1.0, not Apache 2.0. In the repository, this area includes SSO with OIDC and SAML, SCIM provisioning, audit logs, custom roles and license key handling. You can read this code, but the license permits production use only under a commercial agreement with Dokploy. Source availability does not make these features free to run in production.
- SSO and provisioning: OIDC and SAML single sign-on and SCIM are source-available, not Apache 2.0.
- Audit logs and roles: Audit logs and custom roles fall under the same license as SSO.
- License key handling: The code that validates license keys is in the proprietary area, so enterprise features depend on Dokploy's terms.
- Production use: Running these features in production needs a commercial agreement with Dokploy, according to the source-available license.
- Editions: Dokploy's pricing page lists Enterprise options with SSO/SAML, SCIM, audit logs and an SLA at contact-sales pricing, so ask which features your quote includes.
Before you plan around SSO, SCIM or audit logs, get the written commercial terms that cover your intended production use.
Dokploy's TERMS_AND_CONDITIONS.md calls Dokploy core free and open source, but it forbids commercial resale or redistribution of Dokploy as a service without explicit consent from the Dokploy team. This matters if you plan to host Dokploy for customers, offer managed deployments to clients, or bundle it into a paid platform. Running Dokploy for your own internal teams is a different use from reselling access to it. The copyright holder named in the license files is Dokploy Technology, Inc., which is the party to ask about consent and commercial terms.
- Internal use: Running Dokploy for your own staff and applications is the use the core terms describe as free.
- Resale: Offering Dokploy as a service to third parties requires explicit consent from Dokploy.
- Redistribution: Passing Dokploy to others as part of a product also requires consent under the terms.
- Copyright holder: Dokploy Technology, Inc. is named in the license files, so направ contract questions to that entity.
- Consulting work: If an implementation partner operates Dokploy for your organization, ask how that arrangement fits the terms.
Have counsel confirm what your intended use requires, including any managed service or client-facing deployment, before you commit.
Heroku vs Dokploy: capabilities side by side
This table compares Heroku with Dokploy across deployment model, build options, databases, clustering, previews, licensing and cost. Read the gap rows first, because they show where Dokploy will need your own work or a confirmed answer from the vendor.
| Capability | Heroku | Dokploy |
|---|---|---|
| Deployment model | Managed platform on Heroku's infrastructure, with apps running on dynos and Fir built on Kubernetes | Self-hosted on your own servers, installed on Docker with Traefik and a web interface on port 3000 |
| Build options | Fir builds apps only with Cloud Native Buildpacks | Nixpacks (default), Railpack, Dockerfile, Heroku Buildpacks, Paketo Buildpacks and static sites served from an NGINX container |
| Databases | Heroku Postgres and other add-ons, with breadth to confirm for your stack | Postgres, MySQL, MariaDB, MongoDB and Redis, deployed from the dashboard |
| Backups | Heroku Postgres backups, with retention and export limits to confirm in your plan | Automated backups to S3 destinations you configure in settings; confirm retention and restore steps for your database |
| Clustering | Managed scaling by dyno count and tier, handled by Heroku | Docker Swarm manager and worker nodes, with a Docker registry for images; vertical scaling is the documented first step |
| Preview deployments | Review Apps through Pipelines and app.json | Preview deployments are documented; confirm how preview databases are handled |
| Licensing | Proprietary managed service under Heroku terms | Core under Apache 2.0, with SSO, SCIM, audit logs and custom roles in source-available code that needs a commercial agreement for production use |
| Cost model | Per dyno, per database and per add-on, billed monthly | Open-source core at no license fee, plus your servers and staff; paid plans and enterprise pricing come from Dokploy |
| Support and patching | Included with the Heroku contract, with the sustaining model to confirm for your account | Your team or your partner handles upgrades, OS patching and backups unless you buy an enterprise agreement |
Where your data and access sit under each model
Heroku and Dokploy put different parties in charge of the servers, the images and the identity layer that run your apps. The cards below follow those control points so you can see which ones your team would own, which ones Salesforce would own, and what to confirm before you decide.
Servers and hosts you provide
Dokploy is installed on servers your organization provides, in the cloud accounts, data centers or private networks you choose. Its installer sets up Docker Swarm, so the manager and worker nodes become hosts your team patches, monitors and restricts. Any administrator with SSH or Docker access to those hosts can reach every app and database on them. Check who holds that access and how it is logged.
Image distribution through your registry
Dokploy clusters need a Docker registry to distribute images to Swarm nodes. That registry holds your application images, which can contain compiled code, configuration and sometimes secrets baked in at build time. Decide whether the registry is self-hosted, who can push and pull, and how images are scanned and retained. Heroku handles this step inside its own runtime, so the controls differ.
Heroku's managed runtime boundary
On Heroku, Salesforce operates the runtime, the dyno fleet, the build system and the add-on infrastructure. Your team controls the application code, config vars and access grants, but not the hosts or the physical location of the runtime. Confirm the region options for your plan, where Heroku Postgres backups are stored and how Heroku handles data directly with Heroku, because those terms govern your data and are not set by this page.
SSO and SCIM sit in source-available code
Dokploy's single sign-on with OIDC and SAML, SCIM user provisioning, audit logs and custom roles live in the proprietary directories of its repository. Those files fall under the Dokploy Source Available License, which allows production use only under a commercial agreement. If your identity policy requires SCIM deprovisioning or SAML for production, budget for the Enterprise tier and confirm its terms in writing before you build on it.
Controls and evidence, not audit reports
DeployOpen plans and implements the access controls, logging, backup procedures and change records that an assessment will examine, and prepares the evidence for them. Independent auditors and certification bodies issue any audit report or attestation. Neither Heroku nor Dokploy removes the need for your own compliance program, so ask Heroku which of its compliance reports cover the services you use, and map each control to an owner on your side.
Who holds the keys to backups
Dokploy offers automated database backups to S3 destinations you configure, so the backup copies, bucket policies, encryption keys and retention rules become yours to define. On Heroku, pg:backups snapshots are managed by the platform, and their storage location and retention are part of its terms. Write down where every backup copy lives, who can restore it and how long it is kept under each model.
What a Heroku vs Dokploy cost comparison actually includes
Heroku bills per resource, every month. Each dyno, instance or database is a line item that recurs, so the bill grows with the number of processes and data stores you run, not with the work your team does. Heroku's own pricing page lists those per-resource rates, and that is the figure to compare against, not a rate remembered from a past invoice. Dokploy's pricing works differently. Its published Hobby tier is $4.50 per month per server for one server, one organization and one user, and the Startup tier starts at $15 per month for up to 3 servers with basic RBAC. Enterprise, cloud or self-hosted, is quoted by contact sales and includes SSO/SAML, SCIM, audit logs and an SLA. Confirm with Dokploy whether those tier fees are the only licensing charge for the features you need, because SSO, SCIM and audit logs sit in the source-available enterprise code.
Dokploy's licence fee is the smallest line on the bill. You still pay the cloud or data center provider for each server, the disk and RAM that Dokploy requires (at least 2 GB of RAM and 30 GB of disk according to its installation docs), S3-compatible storage for database backups, and bandwidth. The largest recurring cost is usually operator time: patching the host OS, upgrading Docker and Dokploy, watching backup jobs and answering pages. Price that time in a written plan, with named roles and an on-call rota, rather than leaving it as an unpriced assumption.
Ask for a quote that separates one-time and recurring items. One-time costs are setup, migrating apps and databases, configuring the Traefik routes and TLS, hardening, and an initial restore test. Recurring costs are servers, storage, backup destinations, Dokploy tier or enterprise fees, retained support and on-call time. For each line, ask what drives it up, such as server count, database size, backup retention and the number of users who need SSO. Ask the provider to state which Dokploy features the quote assumes and whether an enterprise agreement is required for production use of the proprietary code.
What moving a Heroku app to Dokploy involves, step by step
The sequence takes one Heroku app from inventory to a verified production cutover on Dokploy, with the database restore and rollback paths tested before DNS moves. It produces a documented, reversible move that your team can repeat for each app.
Inventory dynos, add-ons, config vars and build types
The app owner and the platform engineer list every process type in the Procfile, each dyno size and count, every Heroku add-on with its plan, and every config var. For each app, record which build it uses today, whether it relies on Heroku buildpacks or a custom buildpack, and whether it has a Dockerfile. The output is a single inventory sheet per app that becomes the checklist for the rest of the move. Confirm each add-on against your own Heroku dashboard, because plan names and attachments differ between apps.
Provision servers that meet Dokploy's minimums
The infrastructure team provisions one or more servers in the environment you control, sized to at least the 2 GB of RAM and 30 GB of disk that Dokploy's installation documentation requires. Choose an operating system from the tested list in those docs, which covers Ubuntu, Debian, Fedora and CentOS releases. Confirm that inbound ports 80, 443 and 3000 can be opened as needed for Traefik and the web interface, and that your firewall and backup network policies apply to the new hosts. The step is done when Dokploy's installer completes and the dashboard loads over the expected address.
Choose the build type for each app
For each inventory entry, the developer picks a Dokploy build type: Nixpacks is the default, Railpack and a Dockerfile are alternatives, Heroku Buildpacks can reproduce the Heroku 24 stack, Paketo Buildpacks are available, and static sites can be served from an NGINX container. Apps with a Dockerfile are usually the simplest to move because the build is explicit. Record the chosen build type next to each app, and note any place where the Heroku build depended on a stack or buildpack version that does not match. The step is done when a test build of each app produces a running container image on Dokploy.
Dump and restore the database into Dokploy-managed Postgres
The database owner captures a logical dump from the Heroku database, using pg_dump or the Heroku backup tooling for the app, and stores it in a location your team controls. The owner then creates a PostgreSQL database in Dokploy, restores the dump into it, and runs row counts, schema comparisons and a sample of application queries against both sides. Confirm the Postgres version on each side and check extensions the application relies on. The step is done when the restored data matches the source on the agreed checks and the team has written down the restore command.
Recreate config vars and secrets in Dokploy
The developer copies each Heroku config var into the Dokploy application environment, marking credentials as secrets and rotating any value that has been shared outside the team or stored in chat or tickets. Connection strings for the new Dokploy database replace the Heroku ones, and third-party webhook and OAuth callback URLs are updated where they point at the app. The output is a reviewed list showing each variable, its new source and who approved it. The step is done when the staging app starts with no missing variable errors.
Run the app in staging against restored data
The team deploys the app to a staging environment on Dokploy, points it at the restored database and runs the existing test suite, smoke tests and any scheduled or background processes that replace Heroku one-off dynos. Scheduled jobs and workers need their own check, since Dokploy does not replicate Heroku Scheduler behavior by default. Load and error behavior are compared against the Heroku baseline you already have. The step is done when the agreed test list passes and the team signs off in writing.
Cut over DNS with a planned rollback
The operator lowers DNS time to live where your DNS provider allows it, schedules a freeze on writes to the Heroku database, takes a final dump, restores it into the Dokploy database, and then changes the records to point at Dokploy. The Heroku app stays running and unchanged until the team confirms production health. Rollback means pointing DNS back to Heroku and accepting that any writes made on Dokploy must be reconciled. The step is done when production traffic is served from Dokploy, monitoring is clean and the Heroku app is kept for the agreed window before decommissioning.
Test restore paths separately from deployments
After cutover, the operator tests each recovery path on its own. A rollback to an earlier application image in Dokploy can redeploy the container, but it does not restore the database or persistent files, so those need their own procedure. The team restores a database backup into a scratch environment, confirms that uploaded files can be recovered from their storage, and documents the time and steps each restore took. The step is done when each restore path has been run once and recorded in the runbook.
Questions buyers ask before switching from Heroku to Dokploy
How much does moving from Heroku to Dokploy cost?
The software cost is low, but the total depends on the servers, people and services you add. Dokploy's pricing page lists Hobby at $4.50 per month per server for one server, one organization and one user, Startup from $15 per month for up to three servers with basic RBAC, and Enterprise at contact-sales pricing. The cost components are:
- Servers you rent from a cloud or data center provider, which recur monthly
- S3-compatible storage for database backups, which recurs with volume
- Staff time for migration, testing, patching and on-call, which is one-time for the move and recurring after it
- Optional fixed-scope implementation or retainer support from DeployOpen
The main drivers are app count, database size, build types, backup targets and the skills already on staff. Ask any provider for a written quote that itemizes each line.
How long does a Heroku to Dokploy migration take?
The timeline depends on scope, and no standard duration applies to every team. The factors that move it most are the number of apps, the number and size of databases, how many apps use Heroku-specific features such as add-ons or Procfile process types, and how many domains must be cut over. Staff availability and the number of test cycles also matter. Build a test environment on a Dokploy server first, migrate one low-risk app, then move the rest in waves. A fixed-scope agreement sets deliverables and dates in writing before work starts, so ask for a timeline tied to your inventory of apps and databases.
What does the migration need from our own team?
Your team must make several decisions and provide access that only your organization can grant. Expect to provide:
- Access to the cloud accounts or servers where Dokploy will run, and to the Heroku apps, config vars and databases
- Decisions on backup targets, retention periods and who can restore data
- Ownership of DNS records and the cutover window for each domain
- A named owner for on-call alerts, patching and incident response after cutover
If these owners are not named before work starts, the migration tends to stall at the first DNS or backup decision. Confirm each responsibility in the written scope.
Can our team migrate to Dokploy without outside help?
A team with Linux, Docker, DNS and database backup experience can often do the work alone, but it must own every operational task afterward. Dokploy's installation documentation covers setup on supported Ubuntu, Debian, Fedora and CentOS releases, and it needs at least 2 GB of RAM and 30 GB of disk. The harder parts are restore testing, Docker Swarm cluster operation, image registry management and security hardening. Teams without those skills usually bring in help for the design, the first migration and the runbooks, then keep the platform in house. DeployOpen offers fixed-scope implementation, hardening and documentation, plus retainers for ongoing support, so you can choose how much help you need.
Are SSO and audit logs available in production, and under what license?
SSO with OIDC and SAML, SCIM provisioning, audit logs and custom roles are in Dokploy's proprietary code, not under Apache 2.0. Dokploy's proprietary license text is the Dokploy Source Available License 1.0, which allows production use only under a commercial agreement with Dokploy. Core code outside the proprietary directories remains Apache 2.0. Dokploy's pricing lists SSO/SAML, SCIM, audit logs and an SLA under its Enterprise tier, priced by contact sales. Before you depend on these features, get the commercial terms in writing and confirm the scope covers your production servers. Your legal team should review the license text as well.
Do Heroku buildpack apps build unchanged on Dokploy?
Many apps build with little change, but no app should be assumed to build unchanged until it passes a test build. Dokploy supports Heroku Buildpacks, with Heroku 24 as the default, alongside Nixpacks (its default), Railpack, Dockerfiles, Paketo Buildpacks and static sites served from an NGINX container. Check each app's buildpack list, stack version, Procfile process types, runtime pins and any add-on environment variables that Heroku injected automatically. Apps on Heroku's Fir platform build only with Cloud Native Buildpacks, so confirm which build path each app uses before you choose a Dokploy build type. Build each app in a staging environment and compare the image and runtime behavior with production.
Does Dokploy handle database backups for us?
Dokploy automates backups for the databases it deploys, but it does not replace a backup and recovery plan. Dokploy's database documentation covers PostgreSQL, MySQL, MariaDB, MongoDB and Redis, with automated backups to S3 destinations you configure in its settings. You still need to decide which databases and volumes are covered, how long backups are kept, where copies are stored off site, and how often restores are tested. Confirm the exact scope of each backup job and run a restore into a separate server before cutover. Application files stored on disk or in volumes need their own backup plan.
What server and clustering limits should we plan for?
Plan for a single server first, then add nodes only when the workload requires it. Dokploy needs at least 2 GB of RAM and 30 GB of disk, and its installation documentation lists tested operating systems including Ubuntu 18.04 to 24.04, Debian 10 to 12, Fedora 40 and CentOS 8 and 9. Multi-server deployments use Docker Swarm manager and worker nodes and need a Docker registry to distribute images. Dokploy's cluster documentation recommends vertical scaling first because horizontal scaling needs more configuration. Ask your provider to size the first environment from your app inventory, peak memory use and database load, and to document how the registry and Swarm nodes are secured.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Heroku vs Dokploy, we start with a written scope that fits your apps, databases, licensing position and compliance obligations.
How we scope
- We inventory your Heroku apps, process types, add-ons, config vars and data stores before recommending a target.
- We confirm which Dokploy features you need, including whether SSO, SCIM or audit logs require a commercial agreement under the source-available terms.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.
How we build
- We install and configure Dokploy on servers you provide, including Docker, Traefik and the web interface, against the vendor's supported operating systems.
- We rebuild each app with the build type that fits it, testing Heroku buildpacks, Nixpacks or Dockerfiles against your existing releases.
- We configure database backups to your S3-compatible destination and test restores before cutover, rather than assuming the backup job works.
How we hand over
- You receive runbooks covering deployments, rollbacks, database restores, secret handling and server patching.
- We document the license position for every Dokploy component in use, so your legal and procurement teams can review it.
- We walk your platform and operations staff through the environment and the staged DNS cutover plan with you.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We can track Dokploy releases, test upgrades in staging and schedule them with your change process.
- Quotes follow from the written scope, so ask us to itemize server, labor, licensing and retainer costs separately.
