Open-source alternative to Vercel preview deployments: the short answer
If your team relies on Vercel's per-branch preview deployments and needs the builds and preview URLs to stay on infrastructure you control, the two self-hosted options to evaluate are Coolify and Dokploy. Coolify builds previews for pull or merge requests from GitHub, GitLab, Gitea and Bitbucket, while Dokploy's preview deployments are GitHub-based and capped at three per app by default. That difference alone can decide the shortlist for a team whose source control is not on GitHub.
Both tools build a preview from a pull request, run it as a container on your own server and route a generated subdomain to it through their reverse proxy. Coolify's default preview URL pattern uses {{pr_id}}.{{domain}} and needs wildcard DNS pointing at the server, and it deletes the preview when the request is closed or merged. Confirm the exact preview settings, the Git provider connection method (GitHub App or webhook) and the DNS records against the current Coolify and Dokploy documentation before you commit, because these details change between releases.
Two decisions sit outside the build pipeline and need their own planning. The first is preview access control: Vercel's preview protection relies on its own SSO layer, so you must decide how self-hosted previews are restricted, whether through basic authentication at the proxy, an identity-aware gateway or a VPN, and test that unauthenticated visitors cannot reach them. The second is DNS and certificates: wildcard records, certificate issuance for generated subdomains and the operator's responsibility for renewals all move to your team.
Which Vercel preview capabilities map to Coolify and Dokploy
This table compares the preview deployment behaviors teams rely on in Vercel with what Coolify and Dokploy document today. Read each row as a checklist: where both platforms are confirmed, the cell says so, and where a limit or unknown applies, the cell says what to verify in your own environment before you commit to a cutover.
| Capability | Coolify | Dokploy |
|---|---|---|
| Per-branch or per-request preview builds | Builds pull or merge requests from connected repositories as preview deployments | Creates preview deployments from GitHub pull requests |
| Git provider support | GitHub (via GitHub App or webhook), GitLab, Gitea and Bitbucket | GitHub; confirm other providers in current docs before planning |
| Preview URL pattern and DNS | Default {{pr_id}}.{{domain}} pattern that requires wildcard DNS | Confirm the URL pattern and wildcard DNS setup in the current preview documentation |
| Automatic removal on merge or close | Deletes preview deployments when the pull or merge request is closed or merged | Confirm cleanup behavior for closed pull requests in your version |
| Preview count limits | No preview cap stated in the supplied documentation; test resource use under your expected branch volume | Default cap of three previews per application; confirm whether this is configurable in your release |
| Build types for previews | Nixpacks, Railpack (beta), Static, Dockerfile, Docker Compose or Docker Image | Nixpacks (default), Railpack, Dockerfile, Heroku Buildpacks, Paketo Buildpacks or Static |
| Protecting preview URLs without Vercel SSO | Confirm access controls for preview URLs (such as basic auth, IP allowlists or proxy-level authentication) in your proxy and app settings | Confirm access controls for preview URLs in your version; enterprise SSO features sit in the source-available code |
Coolify, Dokploy and building previews yourself: when each fits
Each option below turns a Git branch or pull request into a running test URL, but they differ in who writes the code, how access is controlled and what you maintain. Read the licensing and access control notes before you commit, because the preview feature itself is only part of the decision.
Coolify for broad Git provider support
Coolify builds pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket, so teams that do not use GitHub can keep one preview workflow. Previews deploy at a default {{pr_id}}.{{domain}} address, which requires wildcard DNS on your domain, and Coolify removes them when the request closes or merges. Confirm that your Git provider integration and webhook setup work with your network and firewall rules, and that preview URLs are reachable only by the people who should see them, since preview access control is set in your own configuration. Coolify is licensed under Apache-2.0 and its self-hosted edition is free, so the recurring cost is the servers and the operator time.
Dokploy for GitHub previews
Dokploy provides preview deployments for GitHub repositories and is built on Docker, Traefik and Docker Swarm. The default limit is three previews per application, so a team with many open pull requests should confirm whether that cap fits its review pattern or whether a higher limit needs a paid agreement. The core is Apache 2.0, but the enterprise features such as SSO, SCIM, audit logs and custom roles sit in source-available directories that allow production use only under a commercial agreement. Ask Dokploy which of your access control requirements fall under that agreement before you rely on them.
Custom previews with Git provider environments
Teams that already run GitHub Actions, GitLab CI/CD or Gitea Actions can build previews from their own pipeline, deploying each branch to a namespace or environment and tearing it down on merge. This gives full control over naming, authentication and cleanup, but the team owns the deploy scripts, DNS records, certificates and the cleanup jobs that stop orphaned environments from consuming capacity. Confirm who approves access to preview data, whether previews may use production-like secrets, and how the pipeline's runner access is restricted. No additional platform license is needed, though runner, server and registry costs still apply.
Choosing on license and access control
Compare the three options on what you must put in writing before adoption: the license that covers the code you run, whether preview URLs can be restricted to authenticated staff, and who handles incidents on preview servers. Coolify's self-hosted edition carries no feature gating in its pricing description, while Dokploy's enterprise access controls require a commercial conversation. Ask each vendor for its written license and feature list, and test an unauthenticated request against a preview URL in your own environment before any sensitive branch is deployed.
How wildcard DNS, TLS and build hooks make previews work
A preview deployment follows a short request path. The Git provider sends a pull or merge request event to the self-hosted platform, the platform builds that branch into a container, and the reverse proxy routes a unique preview hostname to that container and terminates HTTPS for it. In Coolify, the proxy is Traefik by default, with Caddy as the alternative. Dokploy also routes through Traefik. Each step can fail independently, so when a preview does not load, check the event delivery, the build log, the proxy routing and the certificate in that order. The default Coolify pattern gives each request its own hostname, built from the pull request number and your domain. Every new hostname needs a DNS record, and creating one record per branch would mean editing DNS on every push. A wildcard DNS record that points all subdomains of the preview domain at the server avoids that. Confirm that the DNS provider accepts wildcard records for your zone, that the record resolves from outside your network, and that no other service already owns the subdomain pattern you plan to use.
Coolify can receive pull request events from GitHub through a GitHub App or a webhook, and it also supports GitLab, Gitea and Bitbucket. A GitHub App is generally the easier choice for teams because it is installed per organization or repository and manages its own permissions, while a webhook requires you to configure the payload URL and secret yourself. Either way, the platform must be reachable from the provider, so a server behind a firewall or a private network needs an inbound path or a different trigger model. Verify the delivery log in the provider after the first test push. TLS for preview hostnames is the point most teams should verify before relying on previews. Coolify's proxy handles HTTPS automatically for the domains it routes, but whether a wildcard name gets a certificate depends on how issuance is configured in your environment, including the ACME challenge type your DNS provider supports. Confirm with your platform team which challenge method will be used for the wildcard domain, test one preview end to end, and document how certificates renew. Do not assume that a certificate for the production domain covers preview subdomains.
Protecting preview URLs without Vercel's SSO
Network restriction keeps preview hostnames unreachable from the public internet. The preview domain resolves only for devices or networks that are already allowed, so an anonymous visitor never reaches the login screen or the application. This is usually the strongest option for internal previews because it removes the public attack surface before any application code runs. Teams commonly place the preview wildcard behind a VPN or a zero trust access product, and those tools vary in how they route wildcard hostnames and handle reviewers on unmanaged devices.
- Scope the wildcard: Confirm that your VPN or zero trust product can publish a wildcard hostname such as the one used for
{{pr_id}}.{{domain}}previews, and that new subdomains are covered without a manual change. - Identity-backed access: Tie access to your identity provider so that removing a reviewer removes preview access.
- Reviewer devices: Decide how external reviewers, such as contractors or auditors, get onto the network, and whether that path is acceptable under your policies.
- Certificates and DNS: Plan certificate issuance for the wildcard and the internal resolver that answers for preview names.
- Logging: Keep access logs from the network layer, since they are the only record of who reached a preview if the application logs nothing.
Before relying on this option, confirm the wildcard, certificate and reviewer-device behavior against the current documentation of the VPN or zero trust product you choose.
Proxy-level protection puts a gate in the reverse proxy that serves the preview. Coolify routes domains through its proxy, Traefik by default or Caddy as the alternative, and Dokku uses nginx by default with other proxies available. A basic authentication challenge or a forward authentication call can be added at that layer so the application does not need to change. This is the closest self-hosted equivalent to a platform-managed gate, but it is still configuration you write, test and maintain.
- Basic authentication: A shared credential is simple to add but is hard to rotate, cannot identify individuals, and should be limited to short-lived previews.
- Forward authentication: A separate auth service, often backed by your identity provider, validates each request before the proxy forwards it. Confirm the middleware or directive name and its behavior in your proxy's current documentation.
- Per-preview configuration: Make sure the gate is applied to every preview created by the platform's pull request integration, not only to the production domain.
- Failure mode: Decide whether the proxy fails closed when the auth service is down. Failing open exposes the preview.
- Health checks and bypass: Confirm that platform health checks and webhooks are excluded from the gate without opening a general bypass.
Test the gate with an unauthenticated request for a freshly created preview, since configuration that only covers the production route is a common gap.
Application-level login is the option where the application itself requires a sign-in before showing content. It is the most portable across hosts, because the protection travels with the code, but it is also the easiest to weaken, since every preview build must include the login and nothing blocks an unprotected build from being deployed. Use this option only with synthetic or test data, and treat the preview as a place where mistakes are expected.
- Test data only: Seed previews with fictitious records and never connect them to production databases, queues or customer systems.
- Shared login boundary: Ensure the login code path is identical across environments so a preview tests what production will run.
- Build-time guard: Add a check in the pipeline that refuses to deploy a preview without the login middleware enabled.
- Credential handling: Keep preview credentials out of the repository and rotate them on a schedule you define.
- Reviewer access: Provide reviewers with individual accounts where possible, so access can be revoked without changing a shared password.
Confirm how your framework's authentication library and middleware behave on preview builds before you depend on them.
Whichever gate you choose, the safest preview design assumes the gate could fail. Previews are built from pull or merge requests, which can be opened by people who are not on your payroll, and the platform copies configuration into each preview build. For that reason, previews should never hold production secrets, production database credentials or live payment and email keys. Separate preview variables are a precondition for every option on this page, not an optional hardening step.
- Separate variable scopes: Define preview-only values in the platform, and confirm whether the platform injects project or organization variables into preview builds by default.
- Fork and external contributor builds: Check how your Git provider and Coolify or Dokploy handle builds from forks, since these can receive different secret access.
- Preview databases: Point previews at disposable databases seeded with test data, and destroy them with the preview.
- Log hygiene: Ensure build and runtime logs do not echo environment values.
- Removal on close: Verify that closing or merging a request removes the preview hostname, container and its data.
Review the secret scoping rules for pull request builds in your platform's current documentation before you grant any preview access to a production-adjacent resource.
Moving preview deployments from Vercel to your servers
This sequence moves per-branch preview builds from Vercel to a self-hosted platform you operate, so each review URL, build and environment variable stays on infrastructure your team controls.
Inventory preview usage and Git providers
Someone on the platform team lists every Vercel project that creates previews, the Git provider that hosts each repository (GitHub, GitLab, Gitea or Bitbucket), and the reviewers who rely on preview URLs in pull requests. Record which preview URLs are linked from tickets, client sign-offs or automated tests, because those links will change. The step is done when each project has a named owner and a provider recorded.
Install the platform on a qualifying server
The operator provisions a Linux server that meets the platform's minimum requirements, then runs the vendor's installer. For Coolify, the installation documentation sets the minimum at 2 CPU cores, 2 GB RAM and 10 GB of free disk on a supported distribution. For Dokploy, the minimum is 2 GB RAM and 30 GB of disk on its tested distributions. Confirm the current requirements in the installation docs before provisioning. The step is done when the admin dashboard loads and the server shows as healthy.
Connect the Git provider to the platform
An administrator creates the connection between the platform and the repository host. For GitHub, this is usually a GitHub App or webhook; for GitLab, Gitea or Bitbucket, follow the provider-specific steps in the platform's preview documentation. Use a service account or a dedicated integration owner, not a personal token, so access survives staff changes. The step is done when a test push to a non-production branch registers in the platform's activity log.
Configure wildcard DNS and TLS
The network team creates a wildcard DNS record that points the preview domain at the server, and the platform's proxy (Traefik by default in Coolify, or Caddy) issues certificates for preview hostnames. Coolify's default preview URL pattern depends on wildcard DNS, so confirm the pattern in its preview documentation before creating records. Verify resolution and HTTPS from outside your network. The step is done when a sample preview hostname resolves and returns a valid certificate.
Scope environment variables for previews
The application owner separates production secrets from preview values, so preview builds never read production database credentials, payment keys or third-party tokens. Store preview-specific values in the platform's environment settings and mark secrets as secret where the platform supports it. Confirm with each service owner which preview backends are safe to use. The step is done when a preview build reads only the preview values, verified by a test endpoint or log check.
Run a pilot with one repository
Choose one low-risk repository and open a test pull request. Confirm the platform builds the branch, publishes the preview URL, serves it over HTTPS and removes it when the request is closed or merged. Check that the build uses the chosen build pack and that preview data does not reach production. Record any gaps, such as missing access controls on preview URLs, and decide how to handle them before wider rollout. The step is done when the pilot passes all checks and the findings have owners.
Switch the review workflow and retire Vercel previews
The engineering lead updates the review checklist, pull request templates and any links in documentation to point at the new preview URLs, then moves project owners over in waves. Disable Vercel preview deployments for each migrated project only after reviewers confirm the new workflow works. Keep Vercel access available until the last dependent project is cut over. The step is done when no active project depends on Vercel previews and the team has signed off on the new process.
Keeping Vercel production while self-hosting previews
Running previews on Coolify or Dokploy while production stays on Vercel is a workable split, but it creates a second place where configuration, DNS and data access must be controlled. The four decisions below connect those risks, so each one is settled before the first preview build runs.
Duplicate environment variable management
Each preview build needs its own copy of configuration, and that copy drifts from Vercel's production values unless someone owns the sync. Decide which variables are shared, which are preview-specific, and which secrets are never copied at all. Ask whether your Coolify or Dokploy instance can scope variables to preview builds, and document one owner for each variable set. Recheck the list after every release, because a missing variable usually shows up as a broken preview rather than an alert.
DNS separation for preview subdomains
Coolify previews use a default {{pr_id}}.{{domain}} pattern that depends on wildcard DNS, so the preview zone must never overlap a production hostname. Point the preview domain at your self-hosted server on its own record, and keep production records managed in Vercel's DNS or your registrar. Confirm that the wildcard record cannot match an existing production name, and check that certificate issuance for previews does not interfere with the Vercel-managed domains.
Preview builds reaching production data
A preview build that connects to a production database can write, migrate or delete live records. Give previews their own database instances or seeded copies, with separate credentials and no network route to production. Restrict production connection strings to production scopes in both Vercel and your self-hosted platform. Test this by confirming that a preview cannot resolve or connect to the production database host, and by reviewing any migration step that runs during the build.
Preview access and ownership of URLs
Vercel protects preview URLs with its own SSO, and that protection does not carry over to a self-hosted preview domain. Decide how each preview is restricted before enabling it, for example through an identity-aware proxy, HTTP basic authentication at the reverse proxy, or an allowlist. Confirm which option your reverse proxy supports, and make sure previews are removed when pull requests close, since stale URLs are the most common way preview content stays exposed.
Questions teams ask before replacing Vercel previews
What does it cost to replace Vercel previews with a self-hosted platform?
The cost has three parts: the servers that run the platform and previews, the people who build and maintain the setup, and the DNS and certificate work that makes preview URLs reachable. The software itself is free for Coolify, which is Apache-2.0 licensed, and Coolify's pricing page describes the self-hosted edition as free forever. If you use Coolify Cloud instead, it costs $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. Server sizing drives the infrastructure line: Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, while Dokploy needs at least 2 GB of RAM and 30 GB of disk. Ask any implementation partner for a written scope that separates one-time setup from recurring operations.
Can our engineers set up Vercel-style previews without outside help?
Often yes, if someone on the team already runs Docker hosts, reverse proxies and DNS. Coolify installs with a single script on supported Linux distributions and connects to servers over SSH, and its preview deployments build pull or merge requests from GitHub, GitLab, Gitea and Bitbucket. The harder parts are rarely the first deploy. They are wildcard DNS for preview hostnames, TLS certificates for those hosts, access control for preview URLs once Vercel's SSO is gone, and keeping the proxy, backups and security patches current after go-live. Teams with no one who has run those pieces before often underestimate that last item. Decide who owns each part before you start.
How long does a pilot for preview deployments take?
Duration depends mostly on how many repositories and frameworks you need to cover, how much of your DNS and certificate setup is already automated, and how strict your access rules for preview URLs must be. A pilot on one application with one Git provider is a much smaller job than moving every project in a monorepo. Ask for a timeline in the written scope that lists the applications in scope, the Git provider and build types, the DNS zone changes, and the acceptance tests for previews, including confirming that previews are removed when a pull request closes. This page does not give a duration because none was researched for this topic.
How do we limit the number of preview deployments on Dokploy?
Dokploy's preview deployments are available for GitHub, and the default cap is three previews per application. Confirm the current setting in the Dokploy preview deployment documentation for the version you run before you rely on it, because limits can change between releases. If your team opens many pull requests at once, plan for the server capacity each preview needs, since every preview is a running container on the same host or cluster. If you need features such as SSO or audit logs for preview access control, check the Dokploy license terms first, because those enterprise features sit in source-available code that requires a commercial agreement for production use.
Do Coolify previews delete themselves after a merge?
Yes. Coolify's documentation states that it deletes preview deployments when the pull or merge request is closed or merged. Test this during the pilot with a throwaway branch on each Git provider you use, and check that the container, routing entry and any preview-specific environment variables are gone. Also confirm that the wildcard DNS record and certificate cover the default {{pr_id}}.{{domain}} pattern, and decide whether preview databases exist at all, since database backups in Coolify do not cover every engine. Preview cleanup is the step most likely to leave stray resources behind if it is not tested.
What should we ask a partner for in a written scope?
Ask for a fixed scope that lists each application, Git provider, build type and preview rule, the server topology and sizing, the DNS and TLS design, how preview URLs are protected, the backup and restore procedure, and the handover documentation. Ask which items are one-time and which recur, such as updates and monitoring, and whether those are covered by a retainer. Ask who is responsible for each cutover step and what evidence you receive at the end. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
When is it worth bringing in a partner for preview deployments?
A partner is worth considering when the preview setup touches regulated data, many teams share one platform, or your staff cannot absorb the ongoing patching and on-call work alongside product delivery. It is also useful when access control for preview URLs must match your identity policies, which takes design work beyond the default setup. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, and it runs security testing that can check preview environments before they reach users. It does not issue audit reports or certifications. Ask for the written scope before deciding, and keep ownership of the server accounts and DNS zone with your team.
What moves to your team when previews leave Vercel
Moving preview deployments to Coolify or Dokploy means your team owns the machinery that Vercel ran for you. Patching the host operating system, watching disk use on the build servers, and keeping Docker images from filling the disk are routine duties now, and each preview build consumes the same CPU and memory as production. Set alerts on build queue length and free disk space before the first pull request opens, and confirm which server hosts the coolify-proxy or Traefik container, since a failure there takes every preview and production route down with it.
Wildcard DNS and TLS are the other standing tasks. Coolify's default preview URL pattern, {{pr_id}}.{{domain}}, depends on a wildcard record that you create and maintain, and the certificate behind it must renew without anyone noticing. Git provider credentials need a rotation schedule too: the GitHub App, GitLab, Gitea or Bitbucket token that Coolify uses to read pull requests and post status back is a credential with write scope, so assign an owner, record its expiry, and test a rotation in staging. Confirm with your Coolify administrator who holds the root and API access, since the API authorization model controls who can change preview settings.
Preview cleanup is where failures hide. Coolify removes preview deployments when a request is closed or merged, but a missed webhook or a failed container removal leaves orphaned containers and routes behind, so schedule a periodic check for previews that no longer match an open request. Remember too that a rollback in Coolify can redeploy a retained application image, but it does not restore databases or persistent files. If a preview writes to a shared database or a mounted volume, plan a separate data reset step, and document it in the runbook before the first incident.
How to run a preview pilot before cutover
This sequence turns preview deployments from a vague promise into written acceptance criteria, so the team can confirm that Git integration, DNS, build behavior, cleanup and access control work on one real repository before any fixed-scope engagement begins.
Pick one low-risk repository
Choose a single application that has a Dockerfile or a build pack that Coolify or Dokploy supports, has no customer-facing traffic in the pilot, and already produces pull requests your team reviews regularly. The platform team and an application owner agree on this choice together. The step is done when the repository, its branch rules and its owner are named in the pilot document.
Confirm the Git provider integration
Connect the repository through the provider method you intend to run in production, whether that is the GitHub App, a GitHub webhook, or the GitLab, Gitea or Bitbucket integration. Confirm that opening a pull or merge request triggers a build and that the status returns to the provider. The check is complete when a test pull request shows a preview build linked from the request, and the integration method is recorded for the security review.
Verify wildcard DNS resolves
Create the wildcard record that the preview URL pattern depends on, such as the pattern in Coolify's default {{pr_id}}.{{domain}} format, and check that the name resolves to the server's address from outside your network. Confirm that the proxy issues a valid certificate for the preview host. The check passes when a preview hostname resolves and serves over HTTPS with a certificate that matches the name.
Test a pull request build and its removal
Open a pull request with a visible change, then confirm the preview builds, serves the change and posts its URL. Merge or close the request and verify that the preview container, route and hostname are removed. The platform team records the build duration and any failed steps. The step is done when both the create and the removal behavior match what the written criteria require.
Confirm access controls block anonymous visitors
Request the preview URL from a machine with no session and no credentials, and confirm the response is blocked or redirected to a sign-in step. Confirm that the protection covers the preview hostnames and any environment variables or secrets that the preview build receives. If the chosen platform lacks built-in preview protection, record the compensating control, such as an identity-aware proxy or network allow list, and who owns it. The check passes when anonymous requests fail and the control is documented.
Record build times and server load
Over the pilot period, log build duration, CPU, memory and disk use on the build host, and the number of concurrent previews. Compare these figures with the capacity the server was sized for, since the minimum requirements in the installation docs are a floor, not a sizing plan. The team should ask the platform vendor or partner to confirm how preview builds compete with production workloads on the same host. The step closes when the figures are written into the cutover decision record.
Agree acceptance criteria in writing
Turn the results into a signed list of pass or fail criteria covering the Git integration, DNS, create and remove behavior, access control and load figures, and attach it to the fixed-scope statement of work before implementation starts. Items that failed are either fixed and retested or moved into scope with an explicit decision. The output is a written acceptance document that both the client and the implementation partner hold.
How DeployOpen scopes and delivers preview replacement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including preview deployment pipelines for Coolify or Dokploy. We start from your Git provider, DNS setup and the merge workflow your teams already use, then agree the scope in writing before any work starts.
How we scope
- Written scope lists which Git provider, pull request events and preview domains are covered.
- We confirm whether wildcard DNS and a TLS approach for preview hostnames are in place or need building.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We connect the chosen platform to your repositories and configure preview builds for pull or merge requests.
- Preview URL patterns, teardown on merge or close, and access controls for preview hostnames are configured and tested.
- We test preview builds against representative application builds, including database and environment variable handling.
How we hand over
- You receive documentation of the preview configuration, DNS records, access rules and teardown behavior.
- Runbooks cover how to troubleshoot a failed preview build and how to remove leftover preview resources.
- Handover includes a walkthrough with the engineers who will own the pipeline after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover platform upgrades, preview configuration changes and periodic review of access rules.
- Ask us to confirm the support scope, response expectations and upgrade approach in the written proposal.
