Which open-source option replaces Heroku Review Apps
If your team creates a disposable Heroku app for every GitHub pull request, that workflow depends on Heroku Pipelines, the GitHub integration and an app.json file, and every review app bills dynos and add-ons like a normal app. For most of that core workflow, Coolify preview deployments are the closest self-hosted replacement. Coolify builds pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket, and it deletes the preview when the request is closed or merged. Dokploy also offers preview deployments on servers you control, and its documentation is the next read if Dokploy is already on your shortlist for other reasons.
The main difference is the URL and the configuration model. Coolify's default preview URL follows the pattern {{pr_id}}.{{domain}}, so you need wildcard DNS pointing at your server before previews resolve. Heroku's docs say the predictable URL feature is not planned for Fir-generation apps, so teams on Fir should not assume their current review app naming will carry over. Heroku's automatic cleanup after 1, 2, 5, 14 or 30 days of inactivity also has no direct equivalent to match by default, so confirm how stale previews are removed in the platform you choose. Confirm your build path too, since Heroku review apps rely on app.json and Heroku buildpacks, while Coolify uses Nixpacks, Railpack, Dockerfiles or Docker Compose.
Before you commit, test one pull request end to end on a staging server. Check that wildcard DNS and TLS work for a preview URL, that the preview database is created and seeded the way your tests expect, and that closing a pull request removes the containers and data you no longer need. Ask your Heroku account team which review app features your current setup uses, and compare them with the preview documentation for the platform you select.
How Heroku Review Apps capabilities map to open-source options
This table maps each Heroku Review Apps capability to Coolify and Dokploy, with notes on what each platform covers and what to verify. Read it as a starting checklist: where a row says to confirm, test the behavior in your own environment before you plan a cutover. The main takeaway is that per-pull-request previews are supported in both, but cleanup rules, predictable URLs and preview databases need explicit checks.
| Capability | Coolify | Dokploy | Coverage notes |
|---|---|---|---|
| Disposable app per pull request with its own URL | Builds pull or merge requests at a default {{pr_id}}.{{domain}} URL | Preview deployments for pull requests from the Git provider | Confirm the URL pattern and TLS behavior on your domain before relying on it for reviewers |
| GitHub integration | Works through a GitHub App or a webhook | Connects to GitHub for preview builds | Pick the GitHub App path for simpler permissions; confirm webhook setup if your org restricts apps |
| app.json and Heroku Pipelines | No app.json or Pipelines equivalent; previews are configured per application | No app.json or Pipelines equivalent; previews are configured per application | Heroku promotion flows must be rebuilt as your own CI/CD steps; app.json env and addon definitions need manual translation |
| Automatic cleanup after inactivity | Deletes previews when the pull or merge request is closed or merged | Confirm whether cleanup is triggered only by pull request close or also by inactivity | Heroku offers 1, 2, 5, 14 or 30 days of inactivity; check whether your chosen platform matches this before expecting the same behavior |
| Wildcard DNS and predictable URLs | Needs a wildcard DNS record for the preview domain | Needs wildcard DNS and a configured preview domain | Heroku's predictable URL feature is not planned for Fir-generation apps, so plan URLs in the new platform from the start |
| Preview databases | Preview environments can use databases you define; confirm data seeding and isolation | Confirm whether preview deployments can provision their own database or share one | Heroku review apps copy add-ons, so plan seed data, anonymization and cost of each preview database |
| Build from Git | Git builds with Nixpacks, Railpack (beta), Static, Dockerfile or Docker Compose | Git builds with Nixpacks, Railpack, Dockerfile, Heroku Buildpacks, Paketo or Static | Dokploy supports Heroku buildpacks directly, which can ease migration of existing build steps |
Coolify or Dokploy: which preview model fits your team
Both Coolify and Dokploy can replace Heroku Review Apps with per-request preview environments on servers you control. The differences sit in licensing, release maturity, build options and how each tool handles enterprise features, so the choice depends on what your team must own and what it can run without a paid tier.
Coolify's preview model and Git hosts
Coolify builds pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket, and deletes each preview when the request closes or merges. Its default URL pattern is {{pr_id}}.{{domain}}, so wildcard DNS must point at the server before previews resolve. Confirm that your Git host and access method match the integration you plan to use, and test the wildcard record first.
Coolify licensing for the full product
Coolify is licensed under Apache-2.0, and its pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions. Previews are part of that edition, so the license does not gate the review-app workflow. Ask your legal team to confirm the license terms against the repository before you redistribute or embed the platform in a product.
Dokploy's open core boundary
Dokploy's LICENSE.MD applies Apache 2.0 outside /proprietary directories and the Dokploy Source Available License inside them. The proprietary code covers SSO with OIDC and SAML, SCIM, audit logs and custom roles, and that license allows production use only under a commercial agreement. If your review-app process depends on these controls, price them in before you choose Dokploy.
Coolify v4 release status
Coolify published its first stable release, v4.0.0, after a long beta, and its release notes preview a v5 aimed at scalability in the core while v4 stays supported. For a preview workflow that teams will rely on daily, the stable line gives a clearer upgrade path than a beta. Check the release notes for the version you install and plan upgrades on your own schedule.
Dokploy's Heroku buildpack support
Dokploy supports Heroku Buildpacks (Heroku 24 by default), Paketo Buildpacks, Nixpacks, Railpack and Dockerfiles, which eases a move from Heroku apps that already depend on buildpacks. Coolify's default Git build pack is Nixpacks, and its Railpack option is still in beta. If your apps need the exact Heroku buildpack behavior, test a current preview build in Dokploy before committing.
Previews on Docker Swarm and Traefik
Dokploy is built on Docker and Traefik, and its installer sets up Docker Swarm, with ports 80 and 443 for Traefik and port 3000 for the web interface. Dokploy's preview documentation covers its own preview flow, so confirm how wildcard routing and preview cleanup behave in your version. Teams that plan to add nodes later should also review its clustering notes, since Dokploy recommends vertical scaling first.
How preview deployments and wildcard DNS work together
A preview deployment starts when a pull or merge request is opened or updated. Coolify builds that request from GitHub (through a GitHub App or webhook), GitLab, Gitea or Bitbucket, then serves it at the default {{pr_id}}.{{domain}} address. The hostname is only reachable if DNS resolves it, so the first decision is to create a wildcard DNS record for the preview domain that points to the server running the proxy. Without that record, each new pull request gets a container that builds correctly but has no address a reviewer can open. Confirm with your DNS provider that the wildcard record sits on a zone you control and that it does not conflict with an existing record for the same subdomain level.
After the build, the proxy does the routing. In Coolify, the coolify-proxy container runs Traefik by default, or Caddy if you choose it, and it reads the hostname from each request and forwards it to the matching preview container. Dokploy uses Traefik as well, and its installer also sets up Docker Swarm, so preview services are routed through the Swarm network. HTTPS is handled by the proxy when you keep Traefik or Caddy, because both obtain certificates automatically. If you select Custom (None), the proxy no longer manages routing or TLS certificates, and you own that work. A wildcard certificate covering every preview subdomain is a common requirement, and whether your chosen proxy and certificate authority issue and renew wildcard certificates through the DNS challenge is something you must confirm in a test environment before relying on it.
Plan for the cost of this setup as well as the behavior. Wildcard DNS is usually cheap, but a wildcard certificate may need a DNS provider API token that the proxy can use, and that token is a credential to store and rotate. Previews also run on the same server as production unless you provision separately, so each open request consumes CPU, memory and disk. Coolify deletes a preview when its request is closed or merged, but it does not clean up data in preview databases on your behalf unless you verify that behavior in your version, so test teardown before you rely on it. Use a staging copy of the proxy configuration to check the full flow end to end.
What happens to the database in each preview
Every preview needs a decision about its data before the first pull request is opened. On Heroku, a review app is a disposable app, so any add-on it attaches is billed the same way as a normal app's add-on. Teams using Heroku Review Apps commonly point the preview at a copy of staging data or at a fresh database, and the cost of that choice shows up on the invoice. On a self-hosted platform, a Coolify preview deployment can either run its own database container or connect to a shared staging database. A dedicated container keeps each branch isolated and lets Coolify delete it with the preview, but every open pull request then adds a database process, memory and disk to the server. A shared database is cheaper and quicker to set up, but schema changes and test writes from one branch can affect every other preview and the staging team.
Backups are the gap to plan for before anyone relies on a preview database. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. If a preview depends on Redis for queues or sessions, treat its contents as disposable and confirm how your team restores it, or keep the cache out of any data that must survive. Confirm with your own tests whether a preview database created from a dump can be restored, and check the retention settings for any backup schedule you apply to preview data. Check whether preview databases should be backed up at all, since deleting a closed pull request also deletes its data unless you have exported it first.
Seeding preview data with masked or synthetic records is your decision and your effort. Coolify does not generate test data or mask production copies for you, so a team that restores a production dump into a preview has taken on the privacy obligations of that copy. Decide which data sets may enter a preview, who approves them, and whether a masking or synthetic data step runs before each deployment. Record that decision with the rest of your data handling controls so auditors can trace where personal data went.
Moving review app workflows to preview deployments
This sequence moves per-pull-request environments from Heroku Review Apps to Coolify or Dokploy preview deployments, with each step ending in a check your team can verify. The result is a tested preview workflow running on servers you control, before any Heroku review app settings are removed.
Inventory review app pipelines and postdeploy scripts
Start by listing every Heroku pipeline that has review apps enabled, along with the app.json file in each repository. Record which environment variables, add-ons and postdeploy scripts the review apps depend on, because these define what a preview must reproduce. Note the inactivity-based destroy setting for each pipeline so you know which cleanup behavior you are replacing. Owner: the platform or application lead, with input from the developers who maintain each repository. Done when you have a written list that maps each pipeline to its environment variables, add-ons, postdeploy commands and cleanup setting.
Install Coolify or Dokploy on a suitable server
Choose the platform based on the features your team needs, then provision a Linux server that meets its published minimums. Coolify requires at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and Dokploy requires at least 2 GB of RAM and 30 GB of disk, so size the server for your preview load as well as the production apps. Run the vendor's installer on a host you control, and confirm the dashboard loads over HTTPS. Owner: the infrastructure team. Done when the dashboard is reachable and the platform reports the server as healthy.
Connect the Git provider to the platform
Connect your Git host to the platform so it can receive pull request events. For Coolify, the supported providers include GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket. Grant access only to the repositories that need previews, and use a service account where your policy requires one. Owner: the platform engineer, with approval from the repository administrator. Done when a test pull request on a sample repository shows up as an event in the platform.
Configure wildcard DNS and TLS for previews
Create a wildcard DNS record that points to the preview server, so each pull request receives its own hostname under your preview domain. Coolify's default preview URL pattern needs this wildcard record. Then confirm that the reverse proxy issues certificates for those hostnames, since Coolify's Traefik or Caddy proxy handles HTTPS automatically, while a custom proxy leaves certificates to you. Owner: the network or DNS administrator. Done when a test hostname under the wildcard resolves and serves a valid certificate.
Translate app.json values into platform settings
Move each value from the app.json environment block into Coolify environment variables, or the equivalent Dokploy settings, and mark secrets so they are not shown in logs. Replace the postdeploy script with a documented step that the platform runs after the build, such as a migration or seed command. Keep the configuration in the repository where practical, so changes go through review. Owner: the application developer, reviewed by the platform engineer. Done when a preview deploys with the same configuration keys that the Heroku review app used, and every secret is held in the platform rather than the repository.
Define preview database seeding and cleanup
Decide how each preview gets its data. Options include a fresh database created by the platform for each preview, a shared non-production database with per-preview schemas, or a seed script run from the postdeploy step. Coolify deploys PostgreSQL, MySQL, MariaDB and MongoDB, among others, but its scheduled backups do not cover every engine, so do not rely on backups for preview data. Confirm that previews are removed when a pull request closes or merges. Owner: the application lead and the data owner. Done when a written seeding rule is agreed and a closed test pull request leaves no running preview or orphaned database.
Run parallel previews on a test repository
Before touching production repositories, run the new previews alongside Heroku Review Apps on a test repository. Open several pull requests, including one that changes the database schema, and compare each preview with its Heroku counterpart for build success, configuration, data and URL behavior. Record any differences, such as build packs that produce different output, and resolve them. Owner: the platform engineer and one developer from the team. Done when every test pull request produces a working preview that matches the expected behavior.
Remove Heroku review app settings after verification
After a pull request merged on a production repository has been verified through the new preview workflow, disable review apps in the Heroku pipeline and delete any remaining review apps. Keep the Heroku pipeline and its app.json available until the team confirms that no workflow still depends on them. Document the new preview process, including the URL pattern, seeding rule and cleanup behavior, in your team runbook. Owner: the platform lead. Done when the Heroku review app settings are off, no Heroku review apps remain, and the runbook is published.
What do teams ask before moving review apps off Heroku?
What does it cost to move review apps off Heroku?
The cost is a set of recurring server fees plus one-time engineering work, and the Heroku side is billed per dyno and add-on, so review apps multiply that bill with every open pull request. On the self-hosted side, the recurring items are the servers that run Coolify or Dokploy, DNS and any backup storage you buy, and the ongoing patching and upgrade time your team absorbs. The one-time items are translating app.json into Coolify settings, seeding preview databases and setting up wildcard DNS. Ask each vendor for current server and storage figures, since the prices that apply to your region and plan change over time. Coolify's self-hosted edition is listed as free, so its software cost is zero, but the servers and the engineering hours are not.
How long does a review app pilot take to set up?
The pilot length depends on how many apps use review apps, how complex their app.json files are, and how many add-ons or databases each preview needs. A single app with a web process and one Postgres database is a much smaller job than a set of services that depend on Redis, background workers and seeded data. Your team also needs to confirm the Git provider connection, wildcard DNS and TLS behavior in its own network before any preview is trusted. No duration is supplied for this work, so ask for a written scope with named deliverables and a timeline before work starts. DeployOpen works from fixed, written scopes, so the timeline follows from the inventory of apps and databases you agree on.
Can an in-house team move review apps without outside help?
Yes, a capable platform team can do it alone if it has time to learn the tooling and owns the result afterward. The work covers installing Coolify on a server, connecting the Git provider, creating the wildcard DNS record, mapping app.json settings and secrets, and deciding how preview databases get data. Teams that have run Docker and reverse proxies before usually find the Coolify setup manageable, while teams new to containers may spend much longer on build and networking issues. The harder part is operational: someone must patch the host, watch disk use from old previews and test restores. Outside help is most useful for a fixed-scope first pass, a review of the setup and documented runbooks your staff can follow.
What does the migration need from our side?
The work needs four things from your organization before it starts:
- Admin access to the GitHub, GitLab, Gitea or Bitbucket organization so the Coolify connection can be created
- Control of the DNS zone that will host the wildcard record for preview URLs
- A server in the region and data center you choose, with enough CPU, memory and disk for the previews you expect
- Named owners for secrets, database seed data and approval of who can open previews
Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on each server, and the previews themselves need more. Confirm your provider's access model and your data residency rules before you request the server.
Does Coolify Cloud reduce the server cost of review apps?
Coolify Cloud changes who runs the Coolify control plane, not where your apps run. According to Coolify's pricing page, it 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 rent or own, so you still pay for those hosts, and the Cloud fee is added on top of them. Self-hosting Coolify removes that fee but makes your team responsible for upgrading and backing up the Coolify instance. Compare both options against your server count, since the per-server fee grows as preview hosts are added, and ask Coolify to confirm current rates before you decide.
Can we keep predictable Heroku-style URLs for review apps?
Coolify's default preview URL pattern is built from the pull request number and your domain, so you get a predictable address per request, but it is not a copy of Heroku's naming. Heroku's own documentation says its predictable URL feature is not planned for Fir-generation apps, so teams on that platform cannot count on it either way. To keep URLs familiar, pick a domain scheme with your team, set the wildcard DNS record to match it, and update any links, OAuth callbacks and webhooks that expect the old names. Test the callback URLs in your identity provider before cutover, because a changed redirect URL is a common cause of failed logins in preview environments.
How do preview databases and cleanup work after migration?
Coolify deletes preview deployments when the pull or merge request is closed or merged, which removes the disposable app and its routing. Heroku can instead destroy review apps after 1, 2, 5, 14 or 30 days of inactivity, so teams should decide whether they want that kind of idle cleanup too. Preview databases need their own plan: Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB and MongoDB but not Redis, Dragonfly or KeyDB, so Redis-backed previews should be treated as disposable. Ask the implementation team to confirm how each preview database is seeded, how old data is removed, and how disk usage is watched on the preview hosts.
Running previews alongside Heroku and your CI
Preview environments rarely move in one step. Most teams keep Heroku serving production while Coolify or Dokploy builds previews for the same repositories, and the existing CI pipeline stays in charge of what gets merged. The four cards below cover the parts that break most often during that overlap: running both platforms, keeping the test gate, splitting DNS, and granting Git provider access.
Keep Heroku serving production
During the transition, Heroku stays the production target until each app is verified on the new platform. Heroku announced on February 6, 2026 that it is moving to a sustaining engineering model focused on stability, security, reliability and support, and that Enterprise Account contracts will no longer be offered to new customers. That is context for timing your plan around renewal dates, not a reason to move on a deadline. Keep Heroku Review Apps running for apps you have not yet migrated, and confirm with your account team what support and renewal terms apply to your contract.
Keep the CI pipeline as the test gate
Coolify and Dokploy build a preview for each pull or merge request, but they do not replace your test suite. Keep the existing CI jobs that run unit, integration and end-to-end tests as required status checks, and let the preview deployment be a target those jobs call, not the source of truth. Decide which pipeline runs first, since a preview that deploys before tests pass exposes its URL to anyone with the link. Confirm that the preview runner has access to the test database and secrets it needs without copying production credentials into it.
Split DNS during cutover
Preview hostnames follow the pattern {{pr_id}}.{{domain}} in Coolify, which requires a wildcard DNS record that points at the new server. Create that record on a subdomain that is not used by production, so Heroku and the new platform can coexist without touching live records. Keep the production hostname on Heroku until the cutover runbook says otherwise, and lower the TTL on that record ahead of the change. Document who can switch the record back, since a rollback is a DNS change as much as a deployment change.
Grant Git provider access deliberately
Preview builds need the platform to receive webhooks from GitHub (through a GitHub App or webhook), GitLab, Gitea or Bitbucket, and to read pull request metadata and source code. Grant the narrowest scope that supports this, ideally to selected repositories rather than the whole organization. Review which accounts own the app or token, because a departed employee's personal token can stop previews silently. Heroku's GitHub integration grants its own permissions, so remove or narrow them once the old review app flow is retired, and record who approved each change.
What changes in operations after the move
Moving review apps to Coolify moves operations work to your team. Heroku patched the platform, the dyno host and its runtime for you. On a Coolify server, you own the Linux host, the Docker engine and the coolify-proxy container that Coolify runs on each server, so you need a scheduled patch window for the operating system and Docker, and a way to confirm that restarts bring the proxy and preview apps back. Confirm with your Coolify version and your distribution's supported list before you upgrade, and keep a copy of the server's Coolify settings so a failed host can be rebuilt.
Preview builds consume disk fast. Every pull request builds an image, and the images, build caches and logs stay on the server until something removes them. Set an alert on free disk space and on the number of images per preview, and check the server's disk before you add more previews. Coolify's installation docs set a minimum of 10 GB of free disk, but that is a floor for the platform itself, not a sizing guide for a busy preview workload, so plan capacity from your own pull request volume and the size of your builds.
Rollback works differently from Heroku's release history. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files, so a bad migration in a preview database cannot be undone by redeploying an older image. Test preview cleanup on purpose: open a test pull request, close it, and confirm that the URL, container, volumes and any preview database are removed and that the disk use drops. Orphaned previews keep running on servers you pay for, so review that list each week.
How DeployOpen works on this
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For preview environments, that means turning Heroku Review Apps behavior into a written scope covering Coolify or Dokploy previews, wildcard DNS, preview databases and the pipeline that triggers them.
How we scope
- Inventory which Heroku pipelines, app.json files and review app settings your teams rely on today.
- Confirm the Git provider in use (GitHub, GitLab, Gitea or Bitbucket) and how pull request events should reach the platform.
- Agree in writing which preview database strategy applies, seeded data or sanitized copies, and who owns that data.
How we build
- Configure preview deployments on your chosen platform, including the default pull request URL pattern and cleanup on close or merge.
- Set up wildcard DNS and TLS for the preview domain, and test that routing and certificates work for new pull requests.
- Test the preview workflow end to end, including build failures, database provisioning and removal of stale previews.
How we hand over
- Document the preview configuration, DNS records, environment variables and the steps a developer follows to open a preview.
- Provide a runbook for the operator covering disk and resource limits, orphaned previews and manual cleanup steps.
- Walk through the setup with the engineers who will maintain it, against the fixed scope agreed at the start.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover platform version upgrades, reviewing preview resource use and reviewing changes to the Git provider integration.
- Ask any provider for a written quote tied to scope, and confirm what is included before work starts.
