Vercel vs Dokploy: when each one fits
If a renewal is coming up, a usage bill has grown, or a data residency rule now applies, the first question is which team you are. Vercel fits teams that need its global edge network, full Next.js feature coverage and no server operations. **Dokploy fits teams that already run or can staff Linux servers, want their apps on infrastructure they control, and accept Docker-based hosting with fewer built-in managed services.* Both can be the right answer, and the choice turns on four things: how much you depend on global edge delivery, which Next.js features your app uses, who will patch and operate the servers, and whether the enterprise features you need fall under a paid Dokploy agreement.
Start with Next.js. The Next.js deployment documentation states that running the app as a Node.js server or in a Docker container supports all Next.js features, while a static export supports a limited set. Vercel is listed among the verified Deployment Adapters that pass the full compatibility test suite. Confirm which Next.js features your app depends on, such as image optimization, ISR, middleware and streaming, and test each one on a Dokploy staging server before deciding. On the operations side, Dokploy needs at least 2 GB of RAM and 30 GB of disk, and your team owns patching, backups and capacity. Ask who on call can handle a failed host at night.
Then check licensing before you commit. Dokploy's core is Apache 2.0, but code in the /proprietary directories, including SSO with OIDC and SAML, SCIM, audit logs and custom roles, falls under the Dokploy Source Available License, which permits production use only under a commercial agreement. If you need those controls, get the written terms and the current Dokploy pricing from the vendor, and compare that recurring fee with your Vercel renewal. Do not assume a feature is free because the core is open source. Ask Dokploy to confirm, in writing, which features your organization needs and whether they are covered.
Which option fits which scenario
This table matches common team situations to the platform that fits better and the condition that decides it. Read each row against your own workload, team skills and data rules, since the right answer often depends on one constraint rather than overall preference.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Frontend team shipping Next.js to a global audience | Vercel | The app depends on Vercel's global CDN, edge features and framework-native previews, and the team does not want to run servers or caching. |
| Team with Docker and Linux skills hosting several internal apps | Dokploy | Engineers can own a Docker Swarm host, patch it, and accept that they run the backups, upgrades and recovery. |
| Team that must keep application data on its own servers | Dokploy | Data residency rules require databases, backups and logs to stay in infrastructure the organization controls, and Vercel's default function region and global network do not meet that rule. |
| Team that needs SSO and audit logs | Depends on the agreement | SSO with OIDC or SAML, SCIM and audit logs in Dokploy sit in source-available code and need a commercial Dokploy agreement for production use. Confirm the plan and terms in writing before choosing. |
| Team with no one to patrol servers | Vercel | No one on the team can take an on-call page for a host, so a managed platform that absorbs patching and capacity is the safer default. |
| Team running a Next.js app behind its own container platform | Dokploy | The app can be built as a Node.js server or Docker container, which supports all Next.js features, and the team can accept the work of caching, image optimization and multi-instance setup. |
| Team that depends on Vercel previews for every branch | Vercel | Preview deployments work out of the box, while Dokploy previews need GitHub setup and a default cap of three per app, which the team should confirm fits its workflow. |
| Team that needs multi-server scaling | Vercel for global traffic, Dokploy for a small fixed fleet | Dokploy clusters use Docker Swarm and need a registry, and its docs recommend vertical scaling first, so confirm the expected load before committing. |
What Dokploy's open-core license means for production use
Dokploy's core is not covered by one license, and the difference matters for production. The repository's LICENSE.MD applies the Apache License 2.0 to code outside the /proprietary directories, while code inside them falls under the Dokploy Source Available License 1.0. That license allows production use only under a commercial agreement with Dokploy. The proprietary code covers SSO with OIDC and SAML, SCIM, audit logs, custom roles and license key handling, which are the features regulated buyers most often need. Before you commit, list which identity, audit and access controls your policies require, then confirm which of them depend on proprietary code in the license text for the proprietary directories.
The commercial terms reach beyond production use. Dokploy's TERMS_AND_CONDITIONS.md describes the core as free and open source but prohibits resale or redistribution of Dokploy as a service without explicit consent from the Dokploy team. That matters if you host apps for clients, subsidiaries or agencies, or plan to offer a managed platform built on it. Pricing is per server on the lower tiers. Hobby lists $4.50 per month per server for one server, one organization and one user. Startup starts at $15 per month for up to three servers and basic RBAC. Enterprise, cloud or self-hosted, includes SSO/SAML, SCIM, audit logs and an SLA, priced on contact with sales. Ask for a written quote that states server count, user count and whether the proprietary features are included, as listed on the Dokploy pricing page.
Have counsel review the Dokploy Source Available License and the terms document against your intended use before any production deployment, especially if the platform serves more than one legal entity or customer. Ask counsel to confirm whether internal use by employees, contractors and affiliates counts as production use under a commercial agreement. Then confirm the current plan terms, included usage and seat rules on the Vercel pricing page, since these change over time. Compare total cost, including the servers, backups and staff time you will carry, alongside the license fees. Treat the licensing answer as a gating decision that comes before the rest of the evaluation.
Capabilities side by side: Vercel and Dokploy
This table maps the capabilities teams usually check at a Vercel renewal against what Dokploy documents. Where Dokploy's docs confirm a feature, the cell says so, and where a gap needs checking, the cell names what to confirm. The main takeaway is that Dokploy covers builds, GitHub previews, domains and databases, while the global CDN, edge functions and enterprise identity features need a closer review before you decide.
| Capability | Vercel | Dokploy |
|---|---|---|
| Build types | Managed builds with framework detection for Next.js and other frameworks | Nixpacks (default), Railpack, Dockerfile, Heroku and Paketo buildpacks, static sites on NGINX |
| Next.js support | Vercel is a verified Next.js deployment adapter | Node.js server or Docker container supports all Next.js features; confirm your version |
| Git-triggered previews | Per-branch preview deployments managed by Vercel | GitHub-based previews, capped at three per app by default; confirm other Git hosts |
| Rollbacks | Promote an earlier deployment from the dashboard | Confirm how earlier deployments are restored and what data they touch |
| Domains and HTTPS | Domains and certificates handled by the platform | Traefik serves ports 80 and 443; confirm certificate issuance and renewal in your setup |
| Multi-server clusters | Scaling handled by the platform | Docker Swarm manager and worker nodes with a Docker registry; vertical scaling is recommended first |
| Managed databases and backups | Databases come from Marketplace providers, which hold their own backups | Postgres, MySQL, MariaDB, MongoDB and Redis with S3 backups; you run storage and restore tests |
| CDN and edge functions | Global CDN and edge functions included in the platform | No CDN documented; confirm whether you need a separate CDN or edge layer |
| SSO and audit logs | Enterprise identity and audit features; confirm the tier and terms | SSO with OIDC and SAML, SCIM, audit logs and custom roles need a commercial Dokploy agreement |
Where your data runs and who controls it
Vercel and Dokploy differ most in where application code, traffic and data sit, and who holds the keys. The cards below cover the decisions that follow from that split, from hosting location and identity to backups and audit evidence. Each one names what to confirm before a renewal or migration decision.
Where Vercel Functions run
Vercel Functions run in Vercel's managed infrastructure, and requests reach them through its global network, so traffic and function execution leave the servers you control by design. The default function region is a Vercel setting, not a property of your own network. Check the default region for each project, which Vercel regions your functions use, and where logs and build artifacts are stored under your plan.
Where Dokploy runs
Dokploy runs on Docker and Traefik on servers you provide, whether bare metal, a VM in your own cloud account, or a data center host. Application containers, databases and the Traefik proxy stay on those hosts, and the installer sets up Docker Swarm on them. Confirm which regions and providers your servers use, who holds the root and cloud credentials, and where Docker images are pushed.
Identity with SSO and SCIM
SSO with OIDC and SAML, SCIM provisioning and custom roles are in Dokploy's proprietary code, which is source-available and requires a commercial agreement for production use. Without that agreement, user access is managed through the core product's basic roles. Confirm which identity provider you use, whether your team needs SCIM deprovisioning, and whether the enterprise agreement covers your server count.
Audit logs and access records
Audit logs are part of Dokploy's proprietary feature set, so the audit trail for deployments, configuration changes and role updates depends on the plan you hold. Vercel's audit trail is delivered as part of its managed service and plan tier. Before migrating, define which events your security team must retain, where they are forwarded, and how long they are kept under your own policy.
Backup destinations on S3
Dokploy's database backups go to S3 destinations configured in its settings, so backup storage can sit in a bucket you own, in your own region and under your own retention rules. Vercel does not hold your application databases, which are typically held by a Marketplace provider. Confirm the bucket owner, encryption and retention, and test a restore, because backup configuration alone does not prove recoverability.
Compliance evidence and auditors
Moving hosting does not transfer compliance. Evidence for access control, change management, logging and backups is produced by your own controls and reviewed by an independent auditor or certification body, not by Dokploy or DeployOpen. Ask your assessor which artifacts they will sample, such as role exports, deployment logs and restore test records, and confirm that each one has an owner after the move.
What Vercel and self-hosted Dokploy cost to run
Vercel's bill and Dokploy's bill have different shapes, so the comparison starts by listing who gets paid for what. On Vercel, the Pro plan includes a $20 credit, and metered usage above that credit (function execution, data transfer, image and build usage, depending on what your team consumes) is billed by Vercel. Seat fees apply per team member. The Dokploy side is different: the core is Apache 2.0 and free to run, but the Dokploy pricing page lists Hobby at $4.50 per month per server, Startup from $15 per month with up to 3 servers and basic RBAC, and Enterprise at contact-sales pricing. Confirm which plan covers the features you need, because SSO, SCIM, audit logs and custom roles sit in the source-available /proprietary code and require a commercial agreement for production use. Ask for the plan tier, server count and seat count in writing, and confirm whether any fee changes with the number of servers in a cluster.
The infrastructure cost is the largest line you control. Dokploy needs at least 2 GB of RAM and 30 GB of disk per server, and the installer uses Docker Swarm, so a multi-server cluster needs enough nodes to be useful for failover and capacity. Add a Docker registry to distribute images across nodes, and S3-compatible storage for database backups, since Dokploy's automated backups target S3 destinations you configure. Each of these is a recurring cost from your cloud or data center provider. Costs rise with build concurrency, database size, backup retention and the number of environments, including preview deployments. One-time work includes the migration itself: mapping projects, rebuilding preview and domain settings, moving environment variables and cutting DNS over. Estimate that effort from your own project count and ask any implementation partner for a fixed-scope quote with written deliverables.
The cost most teams underestimate is engineering time. Vercel handles builds, CDN, scaling and patching of the platform. On Dokploy, your team owns server patching, Docker and Traefik upgrades, backup testing, restore drills, monitoring and on-call response. Confirm who on your staff holds that role and how many hours per month you can commit, because that time recurs for as long as you run the platform. Check whether your team also needs an external retainer for upgrades and testing, and ask any provider to price that separately from the initial build. When requesting a quote, ask for: the Dokploy plan and server count, the server specifications and provider, registry and S3 storage sizing, the migration scope and deliverables, backup and restore testing, and the support or retainer terms, including response expectations in writing.
Choosing a Dokploy build type for a Next.js app
Nixpacks is Dokploy's default build type. It inspects the repository, detects the language and framework, and produces a container image without a Dockerfile you write yourself. For a standard Next.js project with a conventional build and start script, it is the fastest way to get a first deployment running, and it suits teams that want to avoid maintaining build files.
- Fit for Next.js: A Node.js server deployment supports all Next.js features, so Nixpacks works well when the app uses server rendering, route handlers or ISR.
- Less control: The generated image is determined by detection logic, so system packages or a custom Node version may need explicit configuration.
- Reproducibility: Pin the Node version and lockfile so builds do not change between deployments.
- Debugging: When a build fails, the detection step is a common cause, so compare its output with a local build.
- Portability: If you later need a fixed image for a registry or air-gapped setup, a Dockerfile gives you a file you can review.
Before choosing Nixpacks, confirm with the team which Vercel-only features the app uses, such as Vercel image optimization, Edge Config or Vercel-specific middleware, because those need replacements regardless of build type.
Railpack is the newer builder option in Dokploy's list of build types. It also detects the stack from source code and builds an image without a Dockerfile, and it is worth testing when Nixpacks detection does not match the app. Because the build types differ in how they resolve dependencies and runtimes, run the same repository through each candidate and compare the resulting images before you standardize.
- Test before adopting: Build the same Next.js commit with Nixpacks and Railpack and compare the start command, Node version and image size.
- Fit for Next.js: As with Nixpacks, a Node.js server image keeps the full feature set of Next.js.
- Version tracking: Record the builder version used for each release, since builder changes can alter the image.
- Team skills: Check whether the team understands the builder's configuration well enough to troubleshoot it.
- Fallback: Keep a working Dockerfile or another build type available in case the detected configuration breaks.
Ask the Dokploy documentation or your own test builds to confirm which Node.js versions and package managers each builder supports for your project.
A Dockerfile build puts the team in full control of the image. The build steps, base image, Node version, system libraries and start command all live in a file in the repository. For Next.js, this is the most explicit route to a Node.js server or standalone container, and it is the path most regulated teams prefer when they need to review and version the build.
- Fit for Next.js: A Node.js server or Docker container runs all Next.js features, so the Dockerfile can build the app with the standard
next buildoutput and start it withnext startor a standalone server. - Base image control: Pin the base image by digest and track its updates through your own scanning process.
- Multi-stage builds: Separate dependency installation, build and runtime stages to keep runtime images smaller.
- Secrets handling: Keep secrets out of image layers. Build-time variables that Next.js embeds into the client bundle are visible to anyone who can read the frontend.
- Maintenance: The team owns the file, so it must be updated when Node or the framework changes.
Run a local docker build before the first Dokploy deployment, and confirm that the image starts with the same environment variables Vercel supplied.
Dokploy also offers Heroku Buildpacks, which use Heroku 24 by default, and Paketo Buildpacks. Both build images from Cloud Native Buildpacks, so they follow a buildpack model instead of a Dockerfile. This suits teams that already run Heroku-style apps or that want a standard buildpack maintained by a community project. Heroku's own platform moved to buildpacks only, so Heroku Buildpacks are a familiar choice for teams migrating from Heroku.
- Fit for Next.js: The buildpacks produce Node.js server images, which support the full Next.js feature set.
- Stack choice: Heroku Buildpacks default to the Heroku 24 stack, while Paketo has its own builder images. Choose one and document it.
- Buildpack maintenance: Track updates to the buildpack and its base stack, since these change independently of your code.
- Customization: Buildpacks offer less direct control than a Dockerfile, so system dependencies may need extra configuration.
- Standardization: Cloud Native Buildpacks are maintained by several organizations, which can help if you run many services with the same conventions.
Check whether the Next.js version and package manager in your repository are supported by the buildpack you select.
The Static build type serves a site from an NGINX container. It fits when the Next.js app can be exported as static HTML, CSS and JavaScript, such as a marketing site or documentation. Next.js documents that a static export supports a limited set of features, so this option is only appropriate after you confirm that no server rendering, dynamic routes without pre-rendering, API routes, middleware, or server actions are needed.
- Feature limits: Static export does not run a Node.js server, so features that depend on request-time code will not work.
- Adapter support: Platform adapters for Next.js vary in what they support, so do not assume that a static export behaves the same as a Vercel deployment.
- Simplicity: An NGINX container is small and easy to operate, and it has few moving parts.
- Caching: Configure cache headers for hashed assets and HTML separately, since you manage the CDN or proxy behavior yourself.
- Mixed apps: An app that uses both static pages and server features needs a Node.js build type, not the static option.
Review every route and API call in the app, and confirm with the application owners which Vercel-only features, such as image optimization or edge functions, are in use before choosing this option.
What a move from Vercel to Dokploy involves
The sequence below moves Vercel projects, domains, variables and data onto a Dokploy install you control, with previews, cutover and rollback checks in a defined order. It ends with Vercel decommissioned only after the replacement has been proven.
Inventory projects, domains, variables and databases
List every Vercel project, its framework, build settings, custom domains, redirects, cron-like jobs and environment variables, noting which values are marked as secret. Identify each database or storage service the app uses, including any held by a Marketplace provider. Vercel's environment variables can be pulled with the CLI, but secret values are not returned, so the team must recover them from the original source. The step is done when a written inventory exists for each project and every missing secret has an owner who can supply it.
Size servers and choose a container registry
Confirm the server specification against Dokploy's installation requirements, which call for at least 2 GB of RAM and 30 GB of disk on a supported distribution. Decide whether a single server is enough or whether a Docker Swarm cluster with manager and worker nodes is needed, and plan the Docker registry that distributes images to those nodes. Dokploy's documentation recommends scaling vertically first because horizontal scaling needs more configuration. The step is done when hardware, OS and registry choices are written down and approved by the team that operates them.
Install Dokploy and connect GitHub
Install Dokploy on the chosen hosts, confirm that Traefik answers on ports 80 and 443 and that the web interface on port 3000 is reachable only from the networks your administrators use. Connect the GitHub account or app that holds the repositories, and set up user roles and SSO if the enterprise features are part of the agreement. Check the license terms for each feature you plan to rely on before go-live. The step is done when a test application deploys from a repository and the team can log in with its assigned roles.
Rebuild each project with a chosen build type
For each Vercel project, pick a Dokploy build type: Nixpacks (the default), Railpack, a Dockerfile, Heroku Buildpacks, Paketo Buildpacks or a static site served from an NGINX container. Next.js apps that need the full feature set are best served as a Node.js server or container, since static export supports a limited feature set. Recreate environment variables, build commands, health checks and domains, then deploy to a staging domain. The step is done when each project builds reproducibly from Git and passes the same smoke tests it passed on Vercel.
Configure previews and validate Vercel-dependent features
Set up Dokploy preview deployments for the repositories that used Vercel previews, and confirm the preview cap and how previews are removed. Then test each feature that depended on Vercel's global CDN, serverless functions, image optimization or caching, because these have no direct equivalent on a single origin. Measure response behavior from the regions your users are in and document any gap that remains. The step is done when every previously used feature has a pass result, a workaround or an accepted gap recorded in the change file.
Set up backups and rehearse recovery
Configure automated database backups to an S3 destination in Dokploy's settings, and back up persistent files and configuration separately. Dokploy does not restore application state for you, and a rollback in a self-hosted PaaS can redeploy an application image without restoring databases or files. Run a restore into a separate environment and time the steps the team actually performs. The step is done when a backup has been restored successfully, the restore steps are written as a runbook, and someone outside the original builder has followed them.
Stage DNS and run a parallel period
Lower DNS time-to-live ahead of the change, point the production domains at the Dokploy hosts, and keep Vercel serving as a fallback for an agreed window. Compare error rates, logs and certificate status on both platforms and watch for mixed traffic from cached DNS. Confirm that HTTPS certificates are issued for every domain and that redirects behave as before. The step is done when the cutover has run without open defects and the team has signed off on the parallel results.
Decommission Vercel after sign-off
Once the parallel period closes, remove the Vercel domains, revoke deploy hooks and tokens, delete or archive projects, and export any remaining logs or records you must keep. Confirm billing is stopped and that secrets copied to the new platform are rotated where policy requires. Record the final state, including any retained Vercel data and where it is stored. The step is done when Vercel no longer serves traffic, its access tokens are revoked, and the decommission record is filed with the owners of the change.
Questions buyers ask before a Vercel to Dokploy move
Can a small team move from Vercel to Dokploy without outside help?
A small team with someone comfortable with Linux, Docker and DNS can attempt the move alone, but the work is operational, not just a redeploy. Dokploy runs on a server you control, so someone must own the host, OS patches, backups, the Traefik proxy on ports 80 and 443, and the web interface on port 3000. Dokploy's installation docs require at least 2 GB of RAM and 30 GB of disk on a supported distribution. Before deciding, list which of your Vercel projects, domains, functions and data each need an owner after cutover, and confirm that a named person can handle an incident at night.
How long does a Vercel to Dokploy migration take?
No duration is published in the sources for this move, so treat any number you hear as unverified until it is scoped against your own estate. The main drivers are the number of projects and environment variables, how much your apps rely on Vercel-specific features such as functions, image optimization and ISR, the size of the databases you must move and tested backups, DNS cutover planning, and how many preview workflows your team uses daily. Ask for a written scope that lists each of these items with its deliverable before work starts.
Do Dokploy previews match Vercel preview deployments?
Dokploy offers GitHub-based preview deployments, but it does not reproduce Vercel's preview system one for one. Dokploy's documentation describes preview deployments tied to GitHub, and the default cap is three previews per application, which your team should confirm against its current docs. Check how preview URLs are generated, how DNS wildcards are configured, how previews are cleaned up after merge, and whether you can protect preview URLs without Vercel's built-in SSO. Test a real pull request workflow before you commit to the cutover.
Which Dokploy features require a paid Dokploy agreement?
Dokploy's core is Apache 2.0 licensed outside the /proprietary directories, but code inside them is covered by the Dokploy Source Available License, which permits production use only under a commercial agreement. In that proprietary code, the features named in the repository include SSO with OIDC and SAML, SCIM, audit logs, custom roles and license key handling. Dokploy's pricing page also lists Startup and Enterprise tiers with different server, RBAC and SSO limits. Have legal review the LICENSE.MD and TERMS_AND_CONDITIONS.md files, and confirm the exact tier you need in writing with Dokploy before you depend on any enterprise feature.
What changes for Next.js ISR and image optimization after leaving Vercel?
Next.js supports full features when deployed as a Node.js server or Docker container, but Vercel is the verified platform adapter, so Vercel-specific behavior does not carry over automatically. Your team will need to decide how to handle image optimization, typically by running sharp inside the container, and how to share the ISR cache across multiple instances with a custom cache handler. Plan for stateless builds, consistent deployment IDs and encryption keys if you run more than one instance. Test these paths under load in staging before the cutover, because they often fail quietly.
Does Dokploy scale across servers the way Vercel does?
Vercel scales its functions and CDN for you, while Dokploy scales only what you provision. Dokploy clusters use Docker Swarm manager and worker nodes and require a Docker registry to distribute images. Dokploy's docs recommend vertical scaling first, because horizontal scaling needs more configuration. Your team also loses the global CDN, so static assets and edge caching need their own plan. Ask for a written capacity model that covers traffic peaks, failover and where images and assets are served from.
When should we bring in an implementation partner?
Bring in a partner when the move involves regulated data, many production applications, or databases that must cut over with a tested rollback plan. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, so independent assessors remain necessary for any compliance requirement. Ask for a quote based on a written scope that names your applications, data stores, environments and acceptance tests.
How DeployOpen helps you decide and move
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Vercel vs Dokploy decision, we start by mapping which of your Vercel workloads depend on preview deployments, multi-server scaling or the Dokploy enterprise features, so the choice rests on your requirements.
How we scope
- We list your Next.js and other app builds, domains, databases and environment variables that would move to Dokploy.
- We identify which features need the Dokploy proprietary components, such as SSO, SCIM and audit logs, and which need a paid agreement.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install Dokploy on servers in your cloud account or data center and configure Traefik routing, HTTPS and the Docker Swarm layout.
- We choose build types for each app, such as Nixpacks, Dockerfile or Static, and test builds against your Next.js output.
- We set up GitHub preview deployments, database backups to your S3 destinations and a documented rollback path.
How we hand over
- You receive configuration records, runbooks for deploys, backups and restores, and a list of Vercel features that were replaced or dropped.
- We walk your engineers through preview deployments, server sizing and the Docker registry used for cluster images.
- We document what Dokploy does not replace, such as Vercel's global CDN, so you can plan those separately.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can test the deployed apps and their APIs on a schedule and report findings against your own environment.
- Confirm with your team which Dokploy plan or agreement covers your production use before cutover.
