Open-source alternative to Netlify deploy previews

Open-source alternative to Netlify deploy previews: the short answer

If your team uses Netlify deploy previews and the credit-based billing now makes preview builds harder to forecast, or your data residency rules keep build output and preview traffic off third-party platforms, Coolify preview deployments can replace the feature on servers you control. Coolify builds pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket and serves each one at a per-request URL. Dokploy offers GitHub preview deployments as an alternative, with the license split covered elsewhere on this page. Both need wildcard DNS pointing at your server and a reverse proxy in front of the containers to route domains and issue HTTPS certificates.

The main trade-off is that the operator now owns everything Netlify handled for you. Your team provisions build capacity, sizes the server for concurrent preview builds, maintains the wildcard DNS record and certificates, and checks that closed or merged requests are removed. Coolify deletes previews when a request is closed or merged, so confirm that behavior on a test repository before you rely on it. Netlify's own previews draw from the credit balance that also covers production deploys, bandwidth and compute, so the cost question is different in each case.

There are two cost paths. You can run self-hosted Coolify, which is licensed under Apache-2.0 and is free to run on your own servers, and pay only for the infrastructure and the time to operate it. Or you can use Coolify Cloud, which runs the Coolify instance on managed infrastructure while your servers stay yours, for a published monthly fee. Ask any vendor or partner for a written quote that separates server, DNS, backup and operations costs, and confirm current prices on the vendor's pricing page.

Which Netlify deploy preview capabilities map to Coolify and Dokploy

This table compares the core deploy preview behaviors teams rely on in Netlify with what Coolify and Dokploy document for pull request previews. Read each row as a capability to confirm in your own environment, since the Netlify column is intentionally left to verification. The main takeaway is that Coolify documents Git provider coverage and wildcard DNS requirements clearly, while Dokploy's preview scope should be tested against your workflow before you rely on it.

Capability	Coolify	Dokploy
Per-pull-request URLs	Builds pull or merge requests at a default {{pr_id}}.{{domain}} URL, so each request gets its own hostname	GitHub previews from its preview deployments docs; confirm the URL pattern and naming in your version
Branch deploys	Documented for pull and merge requests; confirm whether plain branch deploys without a request are covered	Confirm whether non-PR branch deploys are supported separately from GitHub previews
Build on push	Builds start from the Git provider event tied to the request; confirm the trigger for your provider and app settings	Confirm that new commits to an open pull request rebuild the preview in your setup
Automatic removal on close or merge	Deletes preview deployments when the request is closed or merged	Confirm cleanup behavior when a pull request closes or merges before relying on it
Git provider support	GitHub (GitHub App or webhook), GitLab, Gitea and Bitbucket	GitHub documented; confirm support for other providers before planning
Required DNS	Wildcard DNS record pointing to the server is needed for the default hostname pattern	Confirm wildcard DNS and TLS requirements in the preview deployments docs
HTTPS on preview hosts	Proxy handles HTTPS automatically with Traefik or Caddy; confirm certificate issuance for wildcard hosts	Traefik routes traffic; confirm certificate handling for preview hostnames
Per-environment variables and Netlify deploy contexts	Confirm how preview-specific variables are scoped and whether they can differ from production	Confirm variable scoping per preview; Netlify deploy contexts and Deploy Previews comments have no verified equivalent here

Coolify or Dokploy for preview deployments: when each fits

Coolify is a good fit when your team wants preview deployments across several Git hosts and a fully open-source self-hosted edition. Its self-hosted edition is licensed under Apache-2.0, and its pricing page describes that edition as free with all features and no limitations or restrictions. Preview deployments build pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket, which covers most teams that move between hosts.

Git provider coverage: Previews work with GitHub, GitLab, Gitea and Bitbucket, so the same workflow applies if your source code lives on more than one host.
Default preview URLs: Each preview uses a {{pr_id}}.{{domain}} pattern by default, which requires a wildcard DNS record and a matching TLS setup on your proxy.
Proxy choice: Coolify runs one coolify-proxy container per server with Traefik by default or Caddy as the alternative, and both handle HTTPS automatically.
Hosted option: Coolify Cloud costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing. You still bring the servers, and the Coolify instance runs on Coolify's managed infrastructure.
Cleanup: Previews are deleted when the request is closed or merged, which keeps preview hosts from accumulating stale containers.

Confirm the wildcard DNS and certificate approach with your security team before enabling previews on production-adjacent servers, since preview hostnames are publicly resolvable by default. Also check that your Git provider integration (GitHub App versus webhook) matches your access policy.

How preview URLs, wildcard DNS and the proxy fit together

A preview starts with a Git provider event. When a pull or merge request opens or updates, the provider's webhook (or the GitHub App) tells Coolify to build that revision. Coolify then starts the app container and gives it a generated hostname built from the pattern {{pr_id}}.{{domain}}. The reverse proxy in front of the server, Traefik by default or Caddy as the alternative in Coolify, or Traefik in Dokploy, matches the incoming Host header to that container and terminates HTTPS. Because the proxy makes the routing decision from the hostname alone, every preview needs its own name that resolves to your server, and the proxy needs a certificate for that name. Confirm in the Coolify preview deployment docs and the proxy overview which domain pattern and certificate method your version uses before you rely on it.

Wildcard DNS is what makes the generated names resolve. A single * record for the preview domain pointing at the server answers every pr_id subdomain, so you do not create a DNS record per request. Without it, the browser cannot find the server for a preview URL, the build may still succeed, and the request in the pull request comment will look broken even though the container is running. Two details need a decision before rollout: whether the preview domain is a subdomain you fully control, and how your DNS provider handles wildcard records for the names you use elsewhere. Check also that the proxy can obtain certificates for many hostnames under the chosen issuance method, since HTTP-based validation for each new name depends on port 80 reaching the server. Ask your provider whether certificate issuance for wildcard names needs DNS validation, and test one preview end to end before opening the workflow to every repository.

Plan for the proxy and the wildcard DNS as shared infrastructure rather than per-app settings. Each server runs one coolify-proxy container, so a misconfigured router or an expired certificate affects every preview and production app on that host. Record which proxy you chose, where its configuration lives, and who rotates credentials for the DNS provider. In a Dokploy cluster, the same routing questions apply to Traefik on the manager node, and its docs recommend checking the cluster layout before you add domains. Keep the preview domain separate from production domains where you can, so a preview cannot be mistaken for a live site and so cleanup of old previews does not touch production names.

Preview limits to plan for before cutover

Preview deployments move testing from a managed service to servers you run, so capacity, DNS, cleanup and data handling become your responsibility. The cards below cover the checks to complete before you switch pull request traffic away from Netlify deploy previews.

Server capacity shared by builds and previews

Every preview build and running preview container draws on the same CPU, memory and disk as production apps on the server. A burst of open pull requests can slow production deploys, so size servers for peak concurrent previews, not only for the main branch. Ask Coolify or Dokploy support whether previews can be pinned to a separate server, and confirm how your team will be alerted when a server runs short.

DNS and wildcard certificate setup

Coolify's default preview URL pattern, {{pr_id}}.{{domain}}, depends on a wildcard DNS record pointing at your server. Confirm that your DNS provider supports the record, that the proxy can obtain certificates for the wildcard name, and that your certificate authority and challenge method work from inside your network. Test one preview end to end before cutover, because a missing record looks like an application failure.

Leftover previews after a missed close event

Coolify removes preview deployments when a pull or merge request is closed or merged, but that cleanup depends on the webhook or GitHub App delivering the event. A missed event, a revoked token or a webhook pointing at an old address can leave containers and routes running. Schedule a periodic check that compares running preview containers with open requests, and confirm with the vendor how cleanup behaves after a failed delivery.

Secrets and database copies in previews

Netlify previews usually use environment variables scoped to deploy contexts, and preview apps often point at a shared test database. On your own servers, a preview that copies production secrets or data expands the blast radius of a single pull request. Define a separate secret set for previews, use seeded or anonymized databases, and confirm that preview containers cannot reach production services on the same network.

Build cache and disk growth

Each preview build creates images, layers and build caches that accumulate on disk until something removes them. Because Coolify requires at least 10 GB of free disk and Dokploy requires at least 30 GB, a server with heavy preview traffic can fill its disk unless you set image and cache pruning. Confirm the pruning schedule with the vendor, monitor free space on each server, and decide how old images are retained.

Feature parity with Netlify deploy contexts

Netlify deploy contexts, branch deploys and deploy-specific environment rules do not map one to one onto preview deployments. Check which branch and pull request triggers you rely on, whether previews need their own build variables, and how access to a preview URL is restricted. List each Netlify behavior your team uses and mark it as covered, rebuilt or dropped before the cutover date.

Moving preview workflows from Netlify to self-hosted previews

This sequence moves Netlify deploy previews onto Coolify or Dokploy in a controlled order, so every branch keeps a working review link before Netlify previews are retired. It ends with a documented preview setup your team can operate without Netlify.

Inventory current Netlify deploy contexts
Export the list of branches and deploy contexts that Netlify builds today, including branch deploys, deploy previews opened from pull requests, and any production branch settings. The platform team or the site owner does this in the Netlify project settings, and the output is a table with one row per project, context, and the review link developers use. Done means every project that creates previews is listed, with the build command and publish directory noted for each, so nothing is missed at cutover.
Provision a server that meets the minimums
Choose a Linux host that meets the published minimums for the platform you select. For Coolify, the installation docs call for at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on a supported distribution. For Dokploy, the installation docs call for at least 2 GB RAM and 30 GB of disk. Preview builds consume CPU, memory and disk, so ask your team to size up from the minimum for the number of concurrent pull requests you expect. Done means the host passes the installer's checks and the platform's web interface loads.
Create wildcard DNS for preview hostnames
Create a wildcard DNS record that points a subdomain you control at the server, so each preview gets its own hostname. Coolify's default preview URL pattern uses a pull or merge request identifier followed by the domain, which depends on this wildcard record. The DNS owner confirms the record resolves for a made-up name under that subdomain. Done means a test hostname resolves to the server's address, and you have confirmed with your DNS provider that wildcard records are permitted for that zone.
Connect the Git provider to the platform
Connect the repository host your team uses. Coolify supports GitHub through a GitHub App or a webhook, and also GitLab, Gitea and Bitbucket for preview builds from pull or merge requests. Dokploy documents GitHub-based previews. Use a service account or app identity owned by the team, not a personal token, and limit it to the repositories that need previews. Done means the platform lists the repositories and can read their branches.
Configure preview settings for each project
For each Netlify project from the inventory, create the application on the self-hosted platform from its Git repository and choose the build pack that matches the old build, such as Static, Nixpacks, Dockerfile or buildpacks. Enable preview deployments for pull or merge requests, set the domain template, and set the build command and output directory that Netlify used. Record environment variables in the platform's secret storage and mark the ones that should not be shared with previews. Done means a test pull request produces a preview URL that loads the same content Netlify would have built.
Run one preview alongside Netlify
Pick a single low-risk project and open a real pull request while Netlify still builds its own preview. Compare the two preview URLs for the page content, assets, redirects and environment-specific behavior. Note any differences in build output, missing rewrites or headers that Netlify handled for you. Keep the Netlify preview active during this trial so reviewers can fall back to it. Done means the team has a written list of differences and each one has an owner and a fix or an accepted exception.
Verify preview cleanup on merge and close
Close a test pull request and merge another, then confirm the platform removes the matching preview container and its routing. Coolify deletes previews when the request is closed or merged, and the team should check that this behaves as expected in its own setup. Also check disk usage on the server after several test cycles, and set a cleanup or pruning routine for images that the platform does not remove. Done means the test preview is gone from the platform and the server's disk usage holds steady across repeated runs.
Cut over review links and retire Netlify previews
Update the links in pull request templates, chat channels, QA checklists and stakeholder notes so they point to the self-hosted preview hostnames. Disable Netlify deploy previews and branch deploys for each migrated project only after the team has used the new links for a full review cycle without issues. Keep the Netlify project available for rollback until the owner signs off. For the full site rebuild, redirect translation and form handling, continue with the Migrate from Netlify to Coolify page. Done means no open pull request links to a Netlify preview, and each project's Netlify preview setting is recorded as off.

Keeping Netlify for production while previews run on your servers

A hybrid setup lets a team keep Netlify for production traffic and CDN delivery while preview builds run on a self-hosted Coolify or Dokploy server. The four patterns below separate the decisions: which side owns production, how previews are triggered, where preview data lives, and when the migration can finish.

Netlify keeps production and the CDN

Leave the production site, its custom domain and Netlify's CDN in place, and point only the pull or merge request previews at Coolify. This keeps the production deploy path unchanged while the team tests the self-hosted build. Confirm that the Netlify build for the main branch keeps running and that its deploy credits are still consumed, because a team running out of credits can see projects paused. Check which environment variables and redirect rules each side reads, so previews match production behavior.

Previews on Coolify, production moves later

Run previews on Coolify first, then move production once the team has verified build output, redirects and headers. Use the build pack that matches the site, such as Static, Nixpacks or Dockerfile, and compare the output against the current Netlify deploy. Keep a dated checklist of what must match before cutover. The migration can stay partial for as long as the team needs, but each preview build runs on servers the team operates, so capacity planning must include it.

Shared Git provider webhooks

A repository can send webhook events to Netlify and to Coolify at the same time, but the exact behavior depends on the Git provider and must be tested. Coolify supports GitHub through a GitHub App or webhook, GitLab, Gitea and Bitbucket. Confirm that a pull request opens one Netlify preview and one Coolify preview, that a closed request triggers cleanup on both sides, and that duplicate status checks do not block merges. Record the result for each provider in use.

Separating preview and production data

Preview builds must never write to production databases, object storage buckets or third-party services. Give Coolify previews their own database, backup target and credentials, and avoid copying production data into them unless the team has an approved masking step. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse but not Redis, Dragonfly or KeyDB, so check which preview data needs recovery. Restrict who can read preview secrets in the Coolify interface.

Questions buyers ask about self-hosted Netlify previews

What does it cost to run deploy previews on self-hosted servers?

Running previews on your own servers costs the servers themselves, the DNS and TLS setup, and the people who operate them, so the bill is mostly recurring infrastructure plus one-time setup labor. Coolify's own software is licensed under Apache-2.0 and its self-hosted edition is free forever with all features, according to Coolify's pricing page, so the software line is zero. Coolify Cloud, by contrast, charges $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, and you still bring your own servers. Ask any provider for a quote that separates one-time setup from monthly server, storage, DNS and support fees.

How long does it take to set up preview deployments?

The duration depends on how many servers are involved, how fast your DNS and certificate process is, and whether your repository host is already connected. Preview deployments need a wildcard DNS record that points a subdomain pattern at your server, such as {{pr_id}}.{{domain}} in Coolify's default, so DNS access and change approval often set the pace. Server sizing matters too: Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and each preview build consumes resources on the same host. Ask for a written timeline tied to a defined scope, and confirm which DNS provider and repository host you use before work starts.

Can our internal team set up previews without outside help?

Yes, if your team already runs Linux servers, Docker and DNS, because Coolify connects to each server over SSH, prepares it for Docker workloads and deploys from a Git repository, and its installer is a single script. The harder parts are the ones that Netlify previously hid: wildcard DNS, TLS, build capacity, cleanup rules and backups of anything the previews depend on. Coolify's own guide for teams coming from managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files. Teams without that experience usually benefit from a short internal skills review before committing to a design.

What does a fixed-scope consulting engagement cover for previews?

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. For previews, a typical written scope would cover the server layout, the wildcard DNS and certificate design, connection to your repository host, preview limits and cleanup rules, and runbooks for your team. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so ask for a quote that lists each deliverable and what is excluded.

Is Coolify Cloud or self-hosted Coolify the better fit?

It depends on who must operate the control plane and where the data must sit. Self-hosted Coolify runs entirely on your servers under Apache-2.0, so the control plane stays in your environment, while Coolify Cloud runs the Coolify instance on Coolify's managed infrastructure and you bring your own servers. Choose self-hosted if preview builds, source code and environment variables must stay inside your network or an air-gapped setup, and choose Coolify Cloud only if your data residency and vendor review allow that control plane. Confirm both options against your security policy before you decide.

Do previews clean up after a merge, and what if they do not?

Coolify deletes preview deployments when the pull or merge request is closed or merged, which is the default cleanup path. When cleanup fails, the usual causes are a missed webhook or GitHub App event, a request closed while the webhook endpoint was unreachable, or a build that stalled, so previews keep consuming disk, memory and DNS-resolved routes. Check the cleanup path during testing by closing a test request and confirming the container, images and route disappear. Add a scheduled sweep and disk alerts so orphaned previews are caught, and confirm how your chosen platform handles preview limits.

Does self-hosting reproduce Netlify's Deploy Preview comments?

Not as a built-in feature, so confirm this with the vendor before you rely on it. Netlify posts a comment with a preview link on each pull request, and Coolify's preview deployments build pull or merge requests at a predictable URL, but the comment workflow and status reporting depend on the provider integration and on what your repository host supports. Where a comment or status check is needed, plan it as a CI step or a small integration that posts the preview URL back to the request. Ask the provider exactly which events, status checks and comments the GitHub, GitLab, Gitea or Bitbucket integration sends.

What should we ask a vendor in a quote for self-hosted previews?

Ask for a quote that ties each price to a written deliverable, so you can compare options without guessing. Request the server count and sizing, the DNS and certificate design, the repository integration, the preview limits and cleanup method, the backup approach for any databases previews touch, and the handover documentation. Also ask which costs are one-time and which recur, what support and upgrade retainers cost, what is excluded, and how changes to scope are priced. Finally, ask for the exact licenses of every component, because some self-hosted tools are open core, and confirm the vendor's policy on production use of paid features.

What to confirm with Coolify, Dokploy and your Git provider first

Start with the provider question, because it decides which platform can replace your previews at all. Coolify's preview deployments are documented for GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket. The Dokploy preview documentation is the place to confirm whether it handles GitLab or Bitbucket pull and merge requests or only GitHub, and whether it expects a GitHub App or a webhook. Do not assume parity between the two. For the GitHub App, check the permissions Coolify requests in its docs and compare them with what your security team will accept, especially read access to repository contents and write access to pull request status. Confirm in a test repository exactly which events trigger a build and which trigger cleanup.

Next, test the behavior that the documentation tends to leave out. Confirm how a preview build fetches private dependencies, such as a private npm registry, a private Go module proxy or a Composer repository, and where the credentials live. A build that works from a developer laptop can fail on the server if the token is not configured as a build-time secret. Ask whether preview environments can read the same environment variables as production, and whether that is what you want. Also confirm the resource limits per preview: the number of concurrent previews, the CPU and memory each container may use, and what happens when a branch with a slow build is pushed repeatedly. Set these limits on the proof-of-concept server before you rely on them, because a busy repository can exhaust a small host quickly.

Finally, confirm the certificate and DNS model. Coolify's default {{pr_id}}.{{domain}} pattern needs wildcard DNS, and you should verify how the Traefik or Caddy proxy obtains certificates for many preview hosts, whether through a wildcard certificate with a DNS challenge or per-host issuance, and what rate limits your certificate authority applies. Confirm the same questions for Dokploy's Traefik setup. Record the answers in a short written test plan: which provider, which platform version, which permissions, which limits and which certificate method. Run the plan on a server that matches your production sizing, then decide. Vendor docs and a working proof of concept give you the answers that this page cannot.

How DeployOpen scopes and delivers preview replacement

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including the preview deployment workflow that Netlify deploy previews provide today. The work starts with a written, fixed scope that defines which Git provider, DNS zone and servers are involved before any configuration begins.

How we scope

Confirm which Git provider (GitHub, GitLab, Gitea or Bitbucket) and which pull or merge request events should trigger previews.
Agree the wildcard DNS zone, certificate approach and the server or servers that will host preview containers.
Document preview limits, cleanup rules on merge or close, and which Netlify features are in and out of scope.

How we build

Configure preview deployments in Coolify or Dokploy, including build pack choice and the default preview URL pattern.
Test preview creation, update on new commits, and automatic removal on merge or close against your own sample repositories.
Harden the host, proxy and access controls for preview environments before they receive traffic from pull requests.

How we hand over

Deliver written runbooks covering preview setup, DNS records, cleanup behavior and troubleshooting steps for developers.
Provide a record of configuration, test results and the decisions made during scoping for your architecture and audit files.
Walk your platform and development teams through daily use, so they can add a new repository or change a preview rule themselves.

How we support

Support is available as a retainer for upgrades, patching, backup checks and changes to preview rules after handover.
Retainers can also cover continuous security testing of the preview environment, including exposed preview endpoints.
Ask for the support scope, response expectations and upgrade handling in the written proposal before work starts.

Open-source alternative to Netlify deploy previews