How to migrate from Netlify to Coolify without losing sites, forms or rules
Static sites usually move to Coolify cleanly. Redirects, form handling, functions and deploy previews are the parts that need explicit rebuilding, because each one depends on a Netlify service that Coolify does not provide. A team facing a renewal, a move to credit-based billing (which applies to new Netlify accounts since September 4, 2025) or a data residency requirement should plan the work around those four areas. The platform or web team usually owns the work, often with an implementation partner for the proxy rules, backups and hardening on the servers.
Start with a parallel run. Deploy each site to a temporary domain on Coolify using the Static build pack for pre-built output, or Nixpacks or Dockerfile for server-rendered apps. Check every page, asset path and rewrite against the live Netlify site. Coolify's own migration guide recommends repointing production DNS only after the new deployment works, and keeping the Netlify site available until the new one is stable. Confirm the TLS and domain setup on the Coolify proxy before cutting over, and keep Netlify's ZIP of the last good deploy as a fallback.
Treat the rules and data as separate workstreams. Translate each entry in _redirects and each [[redirects]] table in netlify.toml into the proxy configuration, paying close attention to force, status, country, language and role conditions, which have no direct equivalent in a plain proxy file. Export verified form submissions as CSV from the form's detail page, or pull them through the API, before the Netlify project is paused or closed. Functions and Forms need replacement services you run yourself, and the cost and operations of those services belong in the quote. Confirm with your implementation partner who owns database backups, because Coolify's scheduled backups do not cover every database type.
Which Netlify capabilities map to Coolify and which need rework
This table maps each Netlify capability to its Coolify equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes, to see how much work each site will need before cutover. CDN edge behavior and Netlify Blobs are not covered by the supplied facts, so confirm them in your own environment before you plan.
| Netlify capability | Coolify equivalent | Status and what to expect |
|---|---|---|
| Static site builds and hosting | Static build pack serving a configured output directory | Clean. Point the build pack at the publish directory and confirm the build command in the site settings. |
| Framework builds (server-side rendering, Node apps) | Nixpacks or Railpack build packs, or a Dockerfile | Needs rework. Auto-detection covers supported frameworks, but Netlify-specific adapters or functions must be reviewed and tested. |
| Build environment variables | Application environment variables in Coolify | Clean. Recreate variables per environment and check that build-time and runtime values are set separately. |
| _redirects and netlify.toml redirect rules | Rules in the Traefik or Caddy proxy, or in the static server config | Needs rework. Status codes, force, query and country or role conditions must be translated and tested one by one. |
| Netlify Forms | Exported CSV or API submissions plus a self-hosted form service | Gap. Coolify does not replace the form handler, so choose and host a form service and export existing submissions first. |
| Netlify Functions | Your own containers or services deployed in Coolify | Gap. Each function must be rewritten as a service or route with its own container, scaling and logging. |
| Deploy previews and branch deploys | Coolify preview deployments for pull or merge requests | Needs rework. Requires a Git provider integration and wildcard DNS, and previews are removed when requests close. |
| CDN edge caching and global delivery | Single-server or multi-server routing through the proxy | Gap to confirm. Edge behavior is not covered by the supplied facts, so verify cache and latency needs in your own environment. |
| Netlify Blobs and other managed storage | Your own database or S3-compatible object storage | Gap to confirm. Migration design depends on usage, so confirm how the data is stored and exported before cutover. |
What data you can export from Netlify and what must be rebuilt
Netlify documents a few export paths for form submissions and redirect rules, while most of the rest of a site's setup lives in source files, environment settings and DNS that you recreate on Coolify. Work through these cards before cutover so nothing is lost when the production DNS record moves.
Form submissions as CSV
Netlify lets you download verified form submissions to CSV from the form's detail page using Download as CSV. Export the full history before you disable Netlify Forms, because the form endpoint stops accepting entries once the site moves. Check that the CSV columns match the fields your team uses, and store the file in your own backup location with a retention rule your compliance team agrees on.
Form submissions through the API
The Netlify API returns both verified and spam submissions, which the CSV export does not give you in the same way. If you need the spam flag or a scripted export, call the API with a token you create for the migration, then revoke it after the export. Confirm the current endpoints and rate limits with Netlify, since those details are not part of the facts used for this page.
Redirect and header source files
Redirect and rewrite rules live in a _redirects file in the publish directory and in [[redirects]] tables in netlify.toml, including options such as status, force, query and country, language or role conditions. Treat these files as the source of truth and commit them to Git before migration. Each rule must be translated to the reverse proxy in Coolify, so a missing condition becomes a silent behavior change.
Environment variables and secrets
Netlify environment variables are set in the site settings and are not included in the repository, so they must be copied by hand or with a script. List every variable per branch and deploy context, including build-time values used by the static build. Store them in Coolify's environment settings or your secrets manager, and rotate any value that was shared through chat or a ticket during the project.
DNS records and domain ownership
Production traffic moves when you repoint DNS, so record every custom domain, subdomain, apex record and TLS setting before you change anything. Coolify's guide recommends testing on a temporary domain and repointing production DNS only after the new deployment works, with the old platform kept available until the new one is stable. Confirm who holds the registrar account and the DNS zone.
Git repositories and build settings
Netlify builds are fed by the Git repositories you connected, and the build command, publish directory and Node version are stored in the site settings or netlify.toml. Confirm the repository owner, branch protection and webhook configuration, then record the build settings in a file you control. Netlify Blobs and deploy archives are outside the facts used for this page, so ask Netlify which additional data can be downloaded before cutover.
Migration sequence from inventory to decommissioning Netlify
This sequence moves Netlify sites to Coolify without a production outage by proving each site on a temporary domain, running both platforms in parallel, and only retiring Netlify once the new setup has held steady.
Inventory sites, forms, redirects, domains and integrations
List every Netlify site, its publish directory, build command, environment variables, and whether it is static or server-rendered. Record each
_redirectsfile and[[redirects]]table innetlify.toml, every custom domain and DNS record, every form and its submissions, and every Netlify Function, Blob store or third-party integration. Assign each site a build pack choice (Static, Nixpacks, Railpack or Dockerfile). The output is a migration inventory spreadsheet or runbook that the owners of each site have reviewed. Done when no site, form or domain on the Netlify account is missing from the list.Export form submissions and deploy assets
Before anything changes on Netlify, download verified form submissions as CSV from each form's detail page and pull submissions through the API if you also need spam-flagged entries. Keep a ZIP of the last successful deploy for each site as a rollback reference. Store these exports in your own controlled storage with access limits. Done when each form's export has been checked for row count against the Netlify dashboard and the files are recorded in the inventory.
Pilot one site on a temporary domain in Coolify
Choose a low-risk static site and create it in Coolify on a server you control, using the Static build pack for finished files or Nixpacks or Dockerfile for server-rendered apps. Point it at a temporary hostname and translate its redirect rules into the proxy configuration, Traefik or Caddy, or into the NGINX setup used by the Static build pack. Test each redirect, status code and header against a list of expected URLs. Done when the pilot returns the same responses for every test URL and the team has a short runbook of the steps taken.
Replace forms and functions with owned services
For each site that relied on Netlify Forms or Netlify Functions, decide where the replacement runs: a self-hosted form handler, an API service deployed in Coolify, or a service you already operate. Confirm the new endpoints accept the same fields and that imported submissions remain available in the destination you choose. Document data handling, retention and access for each replacement. Done when every form and function in the inventory has a named replacement, an owner and a passing test.
Run both platforms in parallel
Keep production DNS on Netlify while every migrated site runs in Coolify on its temporary domain. Enable preview deployments only where your Git provider supports them and wildcard DNS is in place. Compare analytics, error logs, build outputs and form behavior for an agreed observation period. Keep Netlify fully active during this phase. Done when each site has a recorded comparison showing that content, redirects and forms match the Netlify version.
Cut over DNS and sign off the checklist
Repoint production DNS to Coolify only after the new deployment on the temporary domain works, following the sequence in Coolify's guide for teams coming from managed platforms. Check TLS certificates, redirects from the old domain, form submissions and rollback steps during the change window. Record the change in a signed-off cutover checklist that lists the DNS records changed, the owner who approved each site and the rollback action. Done when every production hostname resolves to Coolify and the checklist is approved.
Decommission Netlify after the new setup is stable
Once each migrated site has run stably in Coolify, remove the Netlify sites, forms and functions, revoke tokens and remove team members, and confirm that the exported data and backups are stored. Note that Coolify backups cover databases but do not restore persistent files, so keep separate copies of any uploaded content. Done when the decommissioning record lists each removed Netlify resource, the stored exports and an owner for ongoing backup and patching.
How Coolify build packs and the proxy take over from Netlify's build and routing
Netlify's build and publish settings map to a Coolify build pack choice, not to a single setting. For a static site, the Static build pack serves finished files from a directory you configure, so the value you carry over from Netlify's publish directory is the folder that holds the built output, such as dist or public. Nixpacks and Railpack (beta) detect supported frameworks automatically and build the app themselves, which suits a framework-based front end that Netlify previously built with its own image. Before you choose, run the Netlify build locally with the same Node version and build command, then compare the output tree with what Coolify will serve. Confirm with Coolify's build pack documentation which frameworks Nixpacks and Railpack detect on your version, because detection is the step most likely to differ from Netlify's defaults.
Use a Dockerfile when the site needs server-side code that Netlify ran as functions. A Dockerfile gives you explicit control over the runtime, system packages and start command, and Coolify builds it from your repository. Each server runs one coolify-proxy container. Traefik is the default proxy, Caddy is the alternative, and both obtain and renew HTTPS certificates automatically once DNS points at the server. The Custom (None) option removes that automation, so you would then own routing rules, certificate issuance and renewal yourself. Decide this before cutover, and record which option each domain uses. Your redirect rules from _redirects and netlify.toml will be written against whichever proxy you keep.
Next.js sites need a specific check before you assume parity with Netlify. Next.js documentation says that deploying as a Node.js server or a Docker container supports all Next.js features, while a static export supports a limited set and platform support varies. Netlify-specific behavior, such as relying on a platform adapter for server rendering, image handling or middleware, does not carry over automatically. Inventory every Next.js feature the site uses, decide whether it needs a Node.js or Docker deployment, and test each one on a temporary domain. Coolify's guide for teams coming from managed platforms recommends repointing production DNS only after the new deployment works.
How the Netlify migration differs by site type and starting point
A purely static site is the simplest move. Netlify builds the files and serves them from its CDN, so on Coolify the work is to reproduce the build command and publish directory, then serve the output. Coolify's Static build pack serves finished website files from a configured directory, so if your site is generated by a static site generator, you can keep the build in your repository and let the Static pack serve the result. You rebuild the deploy configuration in Coolify and the domain and TLS setup, and you can keep the source repository, the content and the build command.
- Build pack: Use Static when the build output is already in a folder you can name, and Nixpacks when Coolify must run the build first.
- Build settings: Re-enter the build command and publish directory that Netlify used, taken from your
netlify.tomlor the site settings. - Domains: Point the domain at the server and let the proxy issue certificates once DNS resolves.
- Environment variables: Copy build-time variables into Coolify, since Netlify's dashboard values do not move automatically.
- Hosting capacity: Your CDN behavior changes, so measure page speed from the regions your visitors use.
Before switching, confirm that the new deployment serves every page from a temporary domain and that the build output matches the Netlify deploy.
A static site with many redirect and rewrite rules has the same build work as a marketing site, plus a rule migration. Netlify stores redirect and rewrite rules in a _redirects file in the publish directory and in [[redirects]] tables in netlify.toml, with options such as status, force, query and conditions by country, language or role. Coolify does not read those files, so you must translate each rule into the reverse proxy configuration that sits in front of your site. The build and content can stay as they are, but the routing layer is rebuilt.
- Inventory first: List every rule, including forced redirects and rules keyed to country, language or role, because some Netlify conditions have no direct equivalent.
- Proxy translation: Move rules to Traefik or Caddy, the proxies Coolify offers, and test each one against the old URL.
- Status codes: Keep 301 and 302 choices exactly as configured, since search engines and bookmarks depend on them.
- Rewrites: Confirm that single-page application fallbacks still return the right file.
- Ownership: Decide who maintains rules after migration, since they no longer live in a file Netlify reads.
Check that a sample of old URLs, including the most visited ones, returns the same destination and status code on the temporary domain before you repoint production DNS.
A framework app that needs server-side rendering changes more than the hosting target. Netlify runs server functions and rendering on its own infrastructure, so the app must run as a server process on your side. The Next.js documentation states that deploying as a Node.js server or a Docker container supports all Next.js features, while a static export supports a limited set. Coolify's Nixpacks and Railpack build packs detect supported frameworks automatically, and the Dockerfile pack gives you full control of the image. Platform adapters for Netlify are still listed as in progress in the Next.js docs, so do not assume a Netlify-specific adapter will carry over.
- Runtime mode: Run the app as a Node.js server rather than a static export if it uses rendering, image optimization or middleware.
- Build pack: Start with Nixpacks or Railpack (beta) for detection, and move to the Dockerfile pack when you need a pinned runtime.
- Caching: Netlify's edge caching is not present, so decide where static assets and cache headers are handled.
- Scaling: Confirm the memory and CPU the server needs under load, since no managed edge absorbs spikes.
- Images and secrets: Move build-time and run-time variables separately.
Ask your engineers to confirm which Netlify runtime features the app uses before you pick a build pack, because that choice determines what the server must provide.
A team with Netlify Functions and Netlify Forms in active use has the largest rebuild. Netlify's forms accept submissions without a backend, and those submissions must be exported and then handled by a service you run. Netlify lets users export verified form submissions to CSV from the form's detail page with Download as CSV, and its API returns verified and spam submissions. Export before you cut over, because the data does not follow the site. Functions must be redeployed as services on Coolify, either as part of the app container or as a separate application, and each form endpoint needs a replacement handler, spam filter and storage.
- Export early: Download CSV exports and pull API data for all forms, including spam, and store them securely.
- Form replacement: Build a handler or use a self-hosted form tool, and point the front end at its endpoint.
- Functions: Move each function into a container or Coolify application and rewrite the routes that called Netlify's function path.
- Spam handling: Replicate whatever filtering Netlify applied, since you now own that control.
- Secrets: Recreate function environment variables in Coolify and rotate any credentials that were shared with Netlify.
Confirm that every form and function has a tested replacement and that the export archive has been checked before the Netlify project is disabled.
What drives the cost and duration of moving off Netlify
This table breaks the move from Netlify into the components that carry cost: your team's rebuild time, the servers and who operates them, optional Coolify Cloud fees, replacements for Forms and Functions, and running both platforms during cutover. Read each row for who is paid, whether the cost is one-time or recurring, and what to request in a written quote.
| Cost component | Who is paid or who pays | One-time or recurring | What raises or lowers it |
|---|---|---|---|
| Rebuilding build settings and redirects | Your engineers or DeployOpen under a fixed-scope agreement | One-time | Number of sites, framework variety, and how many redirect and header rules must be translated and tested |
| Servers for Coolify | Your cloud account, data center or hosting provider | Recurring | Server count, CPU, RAM and disk sizing, plus traffic and build load; Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB free disk |
| Coolify Cloud fees (optional) | Coolify, at $5 per month for 2 connected servers plus $3 per month for each additional server (Coolify pricing page) | Recurring, with a 20% discount for annual billing | Server count and billing term; customers bring their own servers, so this covers the management plane only, not hosting |
| Operating the platform | Your platform team or a retained support arrangement | Recurring | Patching the host, proxy and Coolify itself, backup checks, and monitoring; managed platforms previously carried this work |
| Replacing Netlify Forms and Functions | Your developers, or a third-party form or serverless service you choose | One-time build, then recurring hosting | Number of forms and functions, spam filtering needs, and whether submissions must stay on your servers |
| Running Netlify in parallel during cutover | Netlify, under your current plan or credit usage | Recurring until decommissioned | Length of the DNS cutover window; Coolify's guide advises keeping the old platform until the new deployment is stable |
| Exporting data and verifying content | Your team, using Netlify's CSV export, API and deploy downloads | One-time | Volume of form submissions and blobs to retain, and whether compliance requires long-term archives |
What usually goes wrong when moving Netlify sites and how to prevent it
Most failed Netlify moves are not build failures. They come from rules that behave differently at a new proxy, DNS changes that interrupt form traffic, and data that was never backed up. Each card below names one risk, the check that catches it, and the step that prevents it.
Redirect rules behave differently at the proxy
Netlify evaluates _redirects and netlify.toml rules itself, including status codes, force flags and country or role conditions. After the move, the same rules run in Traefik or Caddy, or in an NGINX container, and some options may not translate one to one. Before cutover, request a sample of old URLs on the temporary domain and compare status codes and destinations with production.
Forms lose submissions during DNS changeover
Netlify Forms store submissions on Netlify, so DNS changes do not move them. If the form endpoint stops working before you export or replace it, visitor submissions can be lost without an error. Export verified submissions to CSV first, check the API for spam-flagged entries you may also need, and keep the Netlify site live until the replacement form handler accepts test posts.
Preview domains without wildcard DNS
Coolify's default preview URL pattern depends on a wildcard DNS record that points at the server. Without it, pull request previews fail to resolve, and reviewers assume the build is broken. Create the wildcard record before enabling previews, confirm it resolves to the server address, and check that certificates cover the preview names.
Missing environment variables
Netlify injects and stores build and runtime variables per site and per deploy context. Those values do not travel with the repository, so a build can succeed while a function or API key is empty. Export the variable list from the Netlify dashboard, set each one in Coolify for the matching environment, and compare a test build's output against a known good deploy.
Certificates not issued on the new domain
Coolify's proxy issues certificates automatically only once DNS points at the server and the domain is attached to the application. Certificate errors often appear after production DNS is changed too early. Test on a temporary domain first, repoint production DNS only after the new deployment works, and keep Netlify available until HTTPS is confirmed on every domain.
No backups for databases or persistent files
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. Netlify handled hosting and retained deploys for you, so self-hosted backups are your responsibility. Configure scheduled database dumps, store them off the server, and test a restore before decommissioning anything.
Questions teams ask before moving Netlify sites to Coolify
How much effort and cost does moving Netlify sites to Coolify involve?
The effort depends on how many sites you run, how many redirect and header rules they carry, whether any use Netlify Functions or Forms, and how many have preview deployments that your team relies on. Cost has two parts. Coolify itself is free to self-host under Apache-2.0, so the recurring spend is the servers you run it on plus the people who operate them. If you want Coolify's managed instance, Coolify Cloud costs $5 per month for 2 connected servers plus $3 per month for each additional server, according to Coolify's pricing page, with a 20% discount for annual billing. Your one-time costs are the rebuild and testing work. Ask any implementation partner for a quote based on a written scope listing sites, rules, integrations and environments.
How long does a Netlify to Coolify migration take?
Duration depends mainly on site count, the complexity of redirect sets and whether each site needs more than static hosting. A single static marketing site with a short _redirects file is a very different job from a fleet of framework apps with conditional redirects, rewrites to functions and preview workflows. Coolify's guidance for teams coming from managed platforms recommends testing on a temporary domain and repointing production DNS only after the new deployment works, and keeping the old platform available until the new setup is stable. Build that parallel-run period into your plan. Ask for a timeline tied to the written scope, not a generic estimate.
What does the work need from our team?
You need someone who understands each site's build command, output directory and framework, someone who owns DNS and TLS for the domains, and someone who can review the redirect and header rules before cutover. Coolify needs a Linux server with at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, on a supported distribution and amd64 or arm64. Your team also owns backups and recovery. Coolify's managed-platform guide notes that a rollback can redeploy a retained application image but does not restore databases or persistent files, so plan database and file backups from the start.
Can our own engineers do the migration without an outside partner?
Yes, if your team has Linux, Docker, DNS and proxy experience and enough time to run a parallel period. Coolify is designed to be operated directly: it connects to each server over SSH, prepares it for Docker workloads and deploys from a Git repository, Dockerfile, Docker Compose file or prebuilt image. Static sites with the Static build pack are the simplest starting point. Teams with many sites, compliance evidence needs or limited operations capacity often bring in an implementation partner. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms in your own infrastructure under fixed-scope engagements, and a quote follows from the written scope.
How do we export Netlify form submissions before we turn Netlify off?
Export them before you cut over DNS. Netlify lets you export verified form submissions to CSV from the form's detail page using Download as CSV. Its API also returns submissions, including those marked as spam, so use it if you need a complete record for audit or retention. Once exported, store the files under your own retention policy. Replacing Netlify Forms is a separate piece of work: you will need a self-hosted form handler or your own service for new submissions, with spam filtering, notifications and file uploads planned. Confirm the handling of uploaded files and personal data with your privacy and security owners.
Do Coolify preview deployments work with our Git host?
Coolify preview deployments build pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket. Each preview gets a default URL in the form {{pr_id}}.{{domain}}, which requires wildcard DNS for your domain, and Coolify deletes previews when the request is closed or merged. If your team relies on Netlify deploy previews, confirm that your Git host and webhook setup match your workflow, and check the wildcard certificate and DNS arrangements with your network owner before you rely on them in production.
Does Coolify's Apache-2.0 license and free self-hosted edition meet our needs?
Coolify is licensed under Apache-2.0, and its pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions. That means no per-site or per-bandwidth fees from Coolify itself, but the license does not cover your own costs. Servers, backups, storage, monitoring, on-call time and any support you buy remain yours. Confirm with your legal and procurement teams that the Apache-2.0 terms fit your use, and review Coolify's current release notes, since v4.0.0 is the first stable release and the project notes a v5 aimed at core scalability while v4 stays supported.
Which Netlify features need a replacement, and what does that replacement cost to run?
Static hosting, builds and redirects move across with the Static build pack and a proxy rule set, but Netlify Functions, Forms, Blobs and some edge features need your own services. Each replacement adds an application container, a database or storage service and monitoring to operate. Before you commit, list every Netlify feature each site uses, map it to a self-hosted component, and ask your implementation partner to price the work from that list. Netlify's own pricing has shifted to credits since September 4, 2025, according to its documentation, so compare your current credit usage with the fixed server and operations costs you would carry instead.
How DeployOpen scopes, runs and supports a Netlify to Coolify migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Netlify to Coolify move is delivered as a fixed-scope engagement on servers you control. The work starts with a written scope, then moves site by site with the old Netlify deployment kept available until the new one is stable.
How we scope
- Inventory every Netlify site, its build settings, publish directory, environment variables and custom domains.
- List redirect and rewrite rules from _redirects and netlify.toml, and flag any Functions, Forms or Blobs that need a replacement.
- Agree written deliverables, timelines and the Coolify servers, DNS access and preview domain approach before work begins.
- Confirm with your team which parts of the site depend on Netlify-only features that will need a self-hosted substitute.
How we build
- Configure each site on Coolify with the Static, Nixpacks, Dockerfile or Docker Image build pack that matches its framework.
- Translate redirect and header rules into the proxy configuration, then test each rule against a temporary domain.
- Set up pull request previews with wildcard DNS and confirm cleanup behavior when requests are merged or closed.
- Export existing form submissions to CSV and connect replacement services for the functions your sites rely on.
How we hand over
- Repoint production DNS only after the new deployment passes the agreed checks, and record the cutover steps.
- Document each site's build, proxy rules, environment variables, backups and rollback path in a runbook your team keeps.
- Walk your operators through deployments, previews and restores so the team can run the platform after handover.
- Keep a list of open items, such as features that stayed on another service, so nothing is left undecided.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Ask for a written scope that names the Coolify version, upgrade responsibilities and who monitors backups.
- Confirm with DeployOpen during scoping how database and file backups will be taken, since Coolify does not restore persistent files on rollback.
- Request a quote based on the written scope rather than a list price, since DeployOpen does not publish one.
