Why a Netlify alternative after credit-based pricing matters for your sites
If your team runs sites on Netlify, the question is no longer only what each deploy costs. Since September 4, 2025, new Netlify accounts draw production deploys, bandwidth, web requests and compute from one monthly credit balance, according to Netlify's documentation on credit-based pricing plans. When that balance is exhausted, every project on the account can be paused, so a single busy month can take down marketing sites, documentation and customer-facing apps at once. Before renewal, check which pricing model your account is on, how many credits your plan includes, and whether the pause applies to all projects in the team or only to some of them.
The short answer is that Coolify or Dokploy, running on servers you operate, can replace metered credits with a fixed infrastructure cost. A server is paid for by the month whether your sites receive ten visits or ten thousand, so the bill is easier to forecast and an overage cannot switch off your sites. The trade-off is that operations move to your team. You own the server, the proxy, TLS renewal, backups, patching and the rebuild of anything Netlify previously handled for you, such as forms and functions. Those costs do not disappear, they change shape, and they need a named owner before you cut over.
Treat this as a continuity decision as much as a price decision. Credit systems are hard to predict because usage depends on how often your team deploys, how much traffic a campaign brings, and how much compute your build and functions consume. A fixed-cost server gives finance a stable line item, but it also means capacity planning is yours. Ask your team to estimate peak traffic and deploy frequency for the last six months, confirm which Netlify features your sites depend on, and decide who responds when a site goes down at night. A cheaper monthly figure matters less than knowing your sites will stay online.
What continuity and cost predictability require from a replacement
A replacement for a credit-metered host has to answer five questions before any migration starts: what the monthly bill will be, whether the site stays up when a meter runs out, where builds and traffic run, who terminates HTTPS, and who restores data when something breaks. The cards below treat each as a decision you can check against a specific platform, not a general benefit.
A fixed monthly server cost
Self-hosted Coolify and Dokploy are billed by the server you run, not by each deploy or gigabyte. Coolify is free to self-host under Apache-2.0, while Coolify Cloud charges per connected server, so the number to model is your server count plus any hosted control plane fee. Ask every vendor which items are per server, per seat or per usage, and check whether your team has more than one Netlify project that would otherwise share a single credit balance.
A host that keeps serving when a meter runs out
On Netlify, a team that exhausts its credits sees every project paused, so the failure is account-wide. A replacement should keep running on hardware you already pay for, with no per-request ceiling that stops production. Confirm in writing what a platform does at capacity limits, whether it throttles, queues or suspends, and whether your plan has any usage-based component that could halt a site.
Control over where builds and bandwidth run
Netlify builds and serves traffic on its own infrastructure. With Coolify or Dokploy, builds run on servers you choose through SSH-connected hosts, and the static or server-rendered output is served from machines in the region you pick. Decide which region and provider host the build servers, check where any build cache and logs are stored, and confirm which content delivery network, if any, sits in front of the origin.
HTTPS and domain routing handled by a proxy
Netlify issues certificates and routes domains for you. Self-hosted platforms place a reverse proxy in front of each app: Coolify runs one coolify-proxy container per server with Traefik by default or Caddy as an alternative, and both handle HTTPS automatically, while the Custom (None) option leaves routing and certificates to you. Pick the proxy during setup, verify DNS and certificate renewal, and test redirects and headers before cutover.
An operator who owns backups and recovery
Moving off a managed platform moves backups and recovery to your team. Coolify's guidance for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files. Schedule database backups, store copies off the server, test a restore on a second machine, and name who is on call for a failed host before you retire the Netlify project.
Which self-hosted options fit a fixed-cost server model
This table compares Coolify, Dokploy and Dokku on the points that matter when a team moves Netlify sites onto servers it pays for by the month. Read the license and pricing rows first, because they decide whether the platform is free to run and whether any features sit behind a paid or source-available license. Check the build, preview and proxy rows against the sites you actually operate.
| Decision point | Coolify | Dokploy | Dokku |
|---|---|---|---|
| License | Apache-2.0 for the whole project, per the GitHub repository | Open core: Apache 2.0 outside /proprietary, Dokploy Source Available License 1.0 inside it | MIT, per the Dokku home page |
| Cost model | Self-hosted edition is free; Coolify Cloud is $5 per month for 2 servers plus $3 per extra server | Hobby $4.50 per month per server; Startup from $15 per month for up to 3 servers; Enterprise by contact sales | No vendor fee for the software; cost is the servers and the operator's time |
| Static sites | Static build pack for static output; check the proxy and redirect setup for your site | Static build type serves sites from an NGINX container | Static handling depends on the buildpack or Dockerfile you choose; confirm with your setup |
| Build types | Nixpacks, Railpack (beta), Static, Dockerfile, Docker Compose, plus Docker Image | Nixpacks (default), Railpack, Dockerfile, Heroku Buildpacks, Paketo Buildpacks, Static | Heroku-style buildpacks through Git push |
| Preview deployments | PR and MR previews for GitHub, GitLab, Gitea and Bitbucket; needs wildcard DNS | Preview deployments are documented; confirm Git provider support and cleanup behavior | Confirm preview support in your setup; not a core feature in the supplied sources |
| Proxy in front of apps | Traefik by default or Caddy; Custom (None) leaves routing and TLS to you | Traefik on ports 80 and 443; web interface on port 3000 | nginx by default, with Caddy, HAProxy, OpenResty or Traefik as alternatives |
| Cluster model | Multi-server deployments managed from one instance | Docker Swarm manager and worker nodes; a Docker registry is needed; vertical scaling is advised first | Single-server focus; confirm multi-server options before choosing it for scale |
| Enterprise controls | Included in the self-hosted edition, per Coolify's pricing page | SSO (OIDC, SAML), SCIM, audit logs and custom roles sit in source-available code | Confirm access control and audit needs with your own tooling |
How Static and server-rendered builds differ on your servers
Static sites and server-rendered apps need different build packs on a self-hosted server, so classify each site before you pick one. In Coolify, a plain static output can use the Static build pack, while an application that needs a runtime can use Nixpacks, a Dockerfile or a Docker Compose file. Dokploy offers the same split through its Static build type, which serves the output from an NGINX container, and through Nixpacks, Railpack, Dockerfile and buildpack types for server-rendered apps. Netlify hides this choice behind its build settings, so the migration is the first time many teams decide it explicitly. Your build output tells you which group a site falls into: a folder of HTML, CSS and JavaScript points to a static build, while a start command or a server entry point points to a runtime build.
Next.js shows the difference clearly. The Next.js deployment guide states that running Next.js as a Node.js server or a Docker container supports all Next.js features, while a static export supports a limited set and support through platform adapters varies. The Next.js Deployment Adapter API lists Vercel and Bun as verified adapters and says Cloudflare and Netlify are working on verified adapters. For a Netlify-hosted Next.js site, that means the features your team relies on, such as server rendering, middleware, image optimization or revalidation, may behave differently when the site runs on your own Node.js or container runtime. Confirm the exact Next.js version and feature list in the site's own test suite rather than assuming parity. Before cutover, run a feature parity check for each site: list every route type, rewrite, header, middleware and API route in use, then test each one on the new server with production-like data and headers. Record the result per site, since a marketing site and a dashboard built on the same framework can need different build packs. Plan a short parallel run on a separate domain or preview URL, and keep the Netlify deploy available until the checks pass. Ask your platform team to confirm which build pack and proxy setting each site uses, and whether the team owns the Node.js version and dependency updates that Netlify previously handled.
How to move sites to a fixed-cost Coolify or Dokploy server
This sequence takes Netlify sites from an inventory of features and domains to a self-hosted server with a fixed monthly cost, with a tested rollback before DNS moves. Written scope should cover each step marked as needing it, so the owner, deliverables and acceptance checks are agreed before work begins.
Inventory sites and their Netlify features
List every site, its repository, branch, build command, publish directory, custom domains, environment variables, redirects, headers, form handling, serverless functions, Blobs usage and any scheduled builds. Mark which features are static output and which need a running process, because that decides the build pack. Your team owns the list, and a reviewer confirms it against the Netlify dashboard. Done when every site has one row and every Netlify-specific feature is assigned to a replacement or flagged as a gap. This step needs written scope if DeployOpen runs the inventory.
Choose Coolify or Dokploy for the workload
Compare the two against the inventory. Coolify is Apache-2.0 licensed and offers Nixpacks, Railpack (beta), Static, Dockerfile and Docker Compose build packs, with Traefik or Caddy as the proxy. Dokploy's core is Apache 2.0, but its enterprise features sit under the Dokploy Source Available License, which allows production use only under a commercial agreement. Confirm the license terms and feature needs with the vendor before you commit. Done when the team records the choice and the reason in a decision note.
Size the server against minimum requirements
Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, on a supported Linux distribution for amd64 or arm64. Dokploy needs at least 2 GB RAM and 30 GB of disk and is tested on specific Ubuntu, Debian, Fedora and CentOS releases. These are minimums, so add headroom for build caches, images, logs and any databases you plan to host. Ask your hosting provider for the monthly server price and whether backups or snapshots cost extra. Done when a server meets the minimums in a staging environment and the total cost of that server is recorded.
Install the platform and configure the proxy and previews
Install the platform on the server with its installation script, connect your Git provider, and confirm the proxy container is running. Coolify uses one coolify-proxy container per server. Set up wildcard DNS if you want the default preview URL pattern, and decide whether the proxy handles HTTPS automatically or you manage certificates yourself. Confirm the Coolify or Dokploy version and check the release notes before you begin. Done when a test application responds over HTTPS on a staging domain and a test pull request produces a preview URL.
Rebuild each site with the matching build pack
For each site, choose the build pack from the inventory: Static or Dockerfile for static output, Nixpacks or a buildpack for server-rendered apps, and Docker Compose where several services must run together. Set environment variables in the platform, not in the repository. Run one build per site and compare the output with the Netlify deploy. Functions and Forms do not transfer automatically, so each replacement service gets its own test. Done when each site builds from Git, the output matches the Netlify deploy, and the team has a signed-off list of any features that do not carry over.
Verify redirects, headers and critical paths
Translate the _redirects file and netlify.toml rules into the proxy or static server configuration, then test each rule with a request that should match it. Check security headers, caching headers, trailing slash behavior and 404 pages. Keep a list of URLs that receive the most traffic and check them first. Done when every rule in the inventory has a passing test result and the critical paths return the same status codes and headers as the Netlify site.
Set database backups and recovery tests
Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so check each database type against that list. Configure S3-compatible storage for backups and set a retention policy. Coolify's guide notes that a rollback can redeploy an application image but does not restore databases or persistent files, so restore a backup to a separate environment and record how long it took. Done when a restore has been tested and the team knows which data is not covered by the schedule.
Cut DNS over with a rollback plan
Lower the TTL on each domain before the change, if your DNS provider allows it, and switch one low-risk site first. Monitor errors, latency and form or function behavior for an agreed period. Keep the Netlify site live until the new server has run cleanly. If a check fails, point the DNS record back to Netlify and document the cause. Done when every domain resolves to the new server, the rollback has been rehearsed, and the Netlify project is kept in place until the owner signs off to decommission it.
Questions buyers ask before moving off Netlify
What does self-hosting Netlify sites cost compared with credits?
Netlify bills new accounts from one monthly credit balance that covers production deploys, bandwidth, web requests and compute, so the bill moves with traffic and build activity. A self-hosted Coolify or Dokploy setup replaces that with server costs, plus the platform cost if you choose a paid option. Coolify's self-hosted edition is free, and its Apache-2.0 license covers the core. Coolify Cloud charges $5 per month for 2 connected servers and $3 per month for each additional server, according to Coolify's pricing page, while Dokploy's Hobby plan is $4.50 per month per server. Your servers, storage, CDN choice and staff time are the remaining components. The Netlify cost vs self-hosted Coolify comparison breaks these down further. Ask for a written quote that lists each component.
What drives the server and operations effort after a move?
Effort depends on how many sites you run, whether they are static or server-rendered, and how much you need to back up. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and Dokploy needs at least 2 GB of RAM and 30 GB of disk, according to their installation docs. Recurring work includes operating system patching, certificate and proxy checks, database backups and restore tests, and monitoring. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image but does not restore databases or persistent files, so backup design is an operator responsibility. Confirm which of these tasks your team will own and which, if any, you want to retain.
How long does a Netlify migration take, and what sets that time?
The duration depends on the number of sites, the build method each site needs, and how many redirects, headers and form or function dependencies must be rebuilt. Static sites can usually move through the Static build pack in Coolify or the Static option in Dokploy, which serves files from NGINX, while server-rendered apps need Nixpacks, Railpack, Dockerfile or buildpack setups and more testing. Sites with many redirect rules take longer to translate into proxy configuration. No fixed timeline is supplied for this work, so ask for a timeline in the written scope and confirm it against a pilot site first.
What does the migration need from our internal team?
Your team needs to provide access to repositories, DNS zones, existing Netlify environment variables, and a list of sites with their build settings and redirect files. Someone must approve the server design, the backup destination and the cutover window. Coolify connects to each server over SSH, so a named operator must manage SSH keys and server access. Dokploy's installer sets up Docker Swarm and uses ports 80, 443 and 3000, so network and firewall changes need approval from your security team before work starts.
Can our own engineers do the move without an implementation partner?
Yes, a team with Linux, Docker, DNS and TLS experience can move simple static sites with the official documentation, and Coolify's installation script and Dokploy's installer make the first server straightforward. Teams often struggle with the parts that are not in the platform docs: translating complex redirect and header rules, rebuilding Netlify Forms and Functions, setting up backups that restore, and writing runbooks for incidents. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure under a fixed-scope written agreement, and can run the work as a fixed-scope project or add ongoing support as a retainer.
What happens to Netlify Forms and Functions after a move?
Netlify Forms and Functions have no direct equivalent inside Coolify or Dokploy, so each needs its own replacement. Form submissions should be exported before the account pauses, and handling of uploaded files and personal data should be documented under your own retention rules. Serverless functions can usually be moved into a container or Node.js service that Coolify or Dokploy runs. Check each dependency during scoping, because the replacement is application work and not a platform setting.
How should preview deployments work after leaving Netlify?
Coolify builds pull or merge requests from GitHub, GitLab, Gitea and Bitbucket at a default URL pattern that needs wildcard DNS, and it deletes previews when a request is closed or merged, according to Coolify's docs. Dokploy also offers preview deployments from its own documentation. Decide before cutover how many previews you need, who can view them, and whether they should be reachable from outside your network. Preview hosts can expose unfinished code, so limit access and confirm the access controls with your security team.
Evidence to keep for change control and audits
A self-hosted Netlify replacement only stays defensible if the client can show what was agreed, how servers and routing were configured, and that backups actually restore. The cards below list the records that connect the scope, the platform and the operating history. DeployOpen prepares this evidence, but independent auditors and certification bodies are the ones who issue any assessment or certification.
Signed scope and deliverables
Keep the written scope, the deliverables list and the acceptance records for the migration of each site. Netlify's credit model means that cost and usage can shift month to month, so the scope should state which sites, domains, forms and preview workflows are in and out. Record any change requests with a date and an approver so the later configuration can be traced back to an agreed decision. Confirm who on the client side can accept changes.
Server build and patch records
Record the operating system version, Docker version and Coolify or Dokploy version on each server, along with the date of every update. Coolify's v4.0.0 release notes and Dokploy's installation requirements define the baseline to compare against. Keep a log of OS patches and reboots so you can show when a server was last brought current. Confirm the upgrade path with your provider before the first production change.
Proxy and TLS configuration
Export the proxy settings that route each domain and handle HTTPS. In Coolify this means whether Traefik or Caddy is in use, or whether the Custom (None) option was chosen and certificates are managed by hand. Keep the redirect and header rules that replace the Netlify _redirects and netlify.toml files, plus the certificate renewal records. Check who can edit these settings, because a routing change can take a site offline.
Backup schedules and restore test results
A backup is evidence only after a restore has been tested. Keep the schedule, retention settings and S3-compatible destination for each database, and note which data stores are excluded. Coolify's scheduled backups do not cover Redis, Dragonfly or KeyDB, and Dokploy's backup setup depends on the S3 destinations you configure. Record each restore test with its date, the source backup and the outcome. Persistent files and databases are not restored by an application rollback, so they need their own entries.
Admin account access control
List every Coolify or Dokploy administrator, the role each holds and the date access was granted or removed. Keep proof that multi-factor authentication and SSO are configured where the platform supports them, and that API tokens are issued and revoked under a documented process. Dokploy's SSO, SCIM and audit log features sit in its source-available code and depend on the plan you accept, so record which tier is in use. Review the list on a fixed schedule.
License terms accepted
Keep copies of the license files and terms in force on the date of deployment. Coolify is Apache-2.0 licensed, while Dokploy combines Apache 2.0 code with a source-available license for its /proprietary directories and restricts commercial resale of the service. Record the plan or agreement under which any paid Dokploy features run, and the date each terms document was reviewed. Legal counsel should confirm how these terms fit your internal use and any customer-facing sites.
Which license terms affect lock-in and resale
The license of the platform you choose decides how much control you keep over the server, the code and the future of your deployment. Coolify is licensed under Apache-2.0, according to its GitHub repository, and its pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions. Dokploy works differently. Its LICENSE.MD applies the Apache License 2.0 to code outside /proprietary directories, but code inside them falls under the Dokploy Source Available License 1.0. That license permits production use of the proprietary code only under a commercial agreement with Dokploy, and the proprietary code covers features such as SSO with OIDC and SAML, SCIM, audit logs and custom roles.
For a team moving off Netlify to escape a billing model, the Dokploy split matters in two places. First, if you rely on SSO, SCIM or audit logs for compliance evidence, those controls may depend on a commercial agreement you cannot run without. Second, the TERMS_AND_CONDITIONS.md file calls Dokploy core free and open source but forbids commercial resale or redistribution of Dokploy as a service without explicit consent. If you plan to offer hosting to clients, a partner or a subsidiary, that clause applies to you. Read LICENSE.MD, LICENSE_PROPRIETARY.md and TERMS_AND_CONDITIONS.md in the exact version you will deploy, and have counsel confirm how production use and internal use across affiliates are treated.
Before you choose, write down which features your sites need and check each against the license file that governs it. Ask Dokploy in writing which terms apply to your organization, including any fee for production use of proprietary components. Ask Coolify to confirm that the features you need are in the self-hosted edition, and keep a copy of the license and pricing pages with a date. Lock-in also depends on your own exit plan: confirm that your sites, environment settings and backups can be rebuilt on another platform without the vendor's tooling.
How DeployOpen moves sites off Netlify under your constraints
DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own infrastructure, so a Netlify move starts with the constraints that triggered it, such as credit exhaustion, residency or lock-in. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory every Netlify project, deploy type, custom domain, redirect rule and form to define the written scope.
- We record which sites are static, which need server-side rendering and which depend on Netlify Functions or Blobs.
- We agree in writing which servers, cloud accounts or data centers will host each site before any build work starts.
How we build
- We rebuild each site on Coolify or Dokploy using the build pack that matches its framework and output type.
- We move redirects and headers into the proxy layer and test each rule against the original Netlify behavior.
- We configure preview deployments, wildcard DNS and HTTPS certificates, then test them against the scoped checklist.
How we hand over
- We document the server layout, deployment steps, backup scope and rollback procedure for your operations team.
- We deliver a cutover plan covering DNS changes, form and function replacements and a retained Netlify export archive.
- We walk your team through restore tests, since a rollback does not restore databases or persistent files without a separate backup.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the migration.
- We can upgrade the self-hosted platform and its proxy as new versions are released, with changes agreed in writing.
- Ask us to confirm which platform, licence terms and feature set apply to your environment before you commit.
