Migrate from Render to Coolify

Migrate from Render to Coolify: what the move involves

Moving from Render to Coolify is a rebuild of your service definitions plus a database restore, not a lift-and-shift. Render does not export a runtime that Coolify can run unchanged. Each web service, background worker, cron job and static site has to be recreated as a Coolify application, a Docker Compose stack or a one-click service on servers you control, and your Postgres data has to be dumped from Render and restored into a Coolify-managed database. Render's Blueprint files, described in the Render Blueprint documentation, define the services, but any environment variable marked sync: false arrives without its value, so every secret must be re-entered on the new platform. The work usually falls to a platform or DevOps engineer who already runs Linux servers, Docker and reverse proxies, because Coolify connects to each server over SSH and then relies on the operator for backups, patching and monitoring. Many teams bring in an implementation partner, such as a DeployOpen-style provider, to write the scope, map each Render service to a Coolify build pack, and run the cutover rehearsal. Effort and risk are highest for stateful workloads: the database cutover, DNS and certificate changes, and any cron job that writes data. Stateless web services are usually the easiest part. Confirm the exact effort with your own service inventory, not with a generic estimate.

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. The platform cost therefore moves to the servers, storage, backup destinations and people time you already pay for, plus any partner fees. Coolify Cloud is a separate, paid option in which Coolify hosts the control plane while you bring your own servers, so confirm which edition your team is evaluating before budgeting. Ask any partner for a quote that lists each Render service, database, worker and cron job as a separate line, the restore rehearsals, the DNS and TLS cutover, and the post-cutover support period. Confirm the Coolify version you will deploy, since v4.0.0 was the first stable release and later versions are current on GitHub.

Which Render capabilities map cleanly to Coolify

This table maps each Render workload and service to its closest Coolify equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes on backups and Key Value, since those decide how much migration work remains. Items marked as needing confirmation depend on your own Render setup and should be checked before you plan the cutover.

Render capability	Coolify equivalent	Status and notes
Web services	Application from Git, Dockerfile or Nixpacks build pack	Clean. Rebuild the service from its repository, set the port and attach the domain, then verify HTTPS through the proxy.
Background workers	Application without a public domain, or a separate application from the same repository	Needs rework. Coolify has no worker service type, so define each worker as its own application with the start command set by you.
Cron jobs	Scheduled task run from an application container or host cron	Needs rework. Coolify's scheduled backups cover databases only, so recreate each Render cron job and confirm its schedule and failure alerts.
Static sites	Application using the Static build pack	Clean. Confirm any Render redirect and rewrite rules, since they must be recreated in the proxy or the build output.
Multi-service stacks from render.yaml	Docker Compose application	Needs rework. Blueprint files do not transfer directly, so map each service to a Compose service and re-enter every environment value marked sync: false.
Render Postgres	PostgreSQL database with scheduled backups to S3-compatible storage	Clean for logical backups. Render exports are directory-format archives that pg_restore can load, and Coolify's Import Backup accepts custom archives. Confirm the PostgreSQL major version you deploy.
Render Key Value (Redis-compatible)	Redis, Dragonfly or KeyDB database without scheduled backups	Gap. Coolify's scheduled backups do not cover these engines, so write a separate snapshot or export routine and decide whether the cache can be rebuilt.
Private networking and autoscaling	Docker networks on one server, or manual scaling across servers	Needs confirmation. Check whether your services depend on Render private service addresses or automatic scaling, since Coolify does not provide Render's managed scaling.

Which data and configuration move, and which you re-enter

Most of a Render migration is inventory. Some items move as files or dumps, while others, especially secret values and external integrations, must be supplied again on Coolify. Work through these cards before you schedule the cutover, so nothing is discovered in the middle of it.

Start from render.yaml Blueprints

If the workspace was built from a Blueprint, the render.yaml file is the starting inventory of services, workers, cron jobs and databases. Generated Blueprints mark environment variable values with sync: false, so the file records that a variable exists but not its value. Expect to supply every such value again on Coolify. Compare the file against the live Render dashboard, because services created by hand will not appear in it.

Export Postgres with Render logical backups

Render's logical backups are compressed .dir.tar.gz archives in PostgreSQL's directory format. Restore them with pg_restore into an empty database on the target, so take a fresh backup close to cutover rather than relying on an old one. Confirm which backups your plan and retention settings actually keep before you rely on them as the only copy.

Use pg_dump for large databases

For large databases, run pg_dump with directory format and the --jobs flag to export tables in parallel. This is the same format Render's logical backups use, so the restore path stays consistent. Run the dump from a host with a network route to the Render database, and check the job count against the CPU and connection limits on both ends before starting.

Import the dump with Coolify restore

Coolify's PostgreSQL Import Backup accepts SQL dumps, custom archives, tar archives and all-database dumps, so the directory-format export can be restored from the Coolify database resource. Restore into a fresh database, then compare row counts and extensions against Render before pointing applications at it. Confirm the Postgres major version on Coolify matches or exceeds the source before you restore.

Rebuild webhooks and DNS records

Render does not carry its deploy hooks, webhook targets or DNS records to another platform. Inventory every external caller that triggers a deploy or sends events to a service, then point each one at the new Coolify endpoint. Custom domains need new DNS records and new TLS certificates, so lower TTLs before cutover and plan how long the old and new records will both resolve.

Reconnect Git for preview deployments

Coolify builds preview deployments from pull or merge requests on GitHub, GitLab, Gitea and Bitbucket, using a default {{pr_id}}.{{domain}} URL. That pattern needs a wildcard DNS record pointing at the server, and the Git connection (GitHub App or webhook) must be configured again on the new platform. Decide whether previews are needed at all on day one, because they add a wildcard certificate and DNS dependency to the cutover.

Migration sequence from inventory to decommission

This sequence moves Render services and Postgres onto Coolify in an order that keeps Render running until each piece is proven on the new server. Each step closes with a written output so the cutover is a decision made on evidence, not on hope.

Inventory services, Blueprint settings and data
Your team lists every Render web service, background worker, cron job, static site, Postgres database and Key Value instance, and records the settings that Render's Blueprint file defines for each. Because generated Blueprints mark environment variable values as sync: false, the inventory must also list where each secret value is kept so it can be re-entered on Coolify. Output: a service inventory with build commands, start commands, ports, domains, scaling settings, cron schedules and data stores, plus a list of environment variables with their owners.
Pilot one low-risk service on Coolify
Pick one stateless web service with no hard dependency on other services and provision a Coolify server that meets the documented minimum of 2 CPU cores, 2 GB RAM and 10 GB of free disk. Connect it over SSH, deploy the pilot from its Git repository, and confirm that the coolify-proxy container routes a test domain with HTTPS. Output: a running pilot on a staging hostname, with a short record of what broke and how it was fixed.
Rebuild each service with the right build pack
For each remaining service, choose the build pack that matches how it builds today: Nixpacks for buildpack-style apps, Dockerfile where a Dockerfile already exists, Docker Compose for multi-service stacks, or Static for built sites. Railpack is in beta, so confirm its status before relying on it. Cron jobs and workers become scheduled tasks or separate services, and the team checks each build output against the Render build log. Output: a build configuration per service, with each image or artifact confirmed to start with the production command.
Rehearse the database restore
Take a logical backup of the Render Postgres database in directory format, as Render documents, and restore it into a Coolify-managed PostgreSQL instance of the same major version. Use pg_restore into an empty database, and run the application's migrations and read queries against the restored copy. Time the restore and record any extension, role or collation differences. Output: a restored staging database, a row-count and checksum comparison against Render, and a documented restore procedure that the team has run at least once end to end.
Re-enter environment values and secrets
Using the inventory, the owner of each service enters environment values into Coolify directly, never by copying them into chat or tickets. Confirm that each secret reaches the running container and that no value is baked into an image. Store the list of keys and owners, not the values, in your change record. Output: a checked environment map for every service where each key shows as set on Coolify and each owner has confirmed the values.
Run both platforms in parallel
Keep Render serving production while Coolify serves the same workloads on staging hostnames, and send a controlled share of test traffic to Coolify if your load balancing allows it. Watch logs, error rates, job runs and database replication lag against the Render baseline, and reconcile any difference in cron behavior. Preview deployments on Coolify need wildcard DNS and are removed when a pull request closes, so plan their hostnames before enabling them. Output: a parallel-run log with agreed pass criteria and a list of defects closed before cutover.
Cut over DNS and certificates
Lower the DNS time to live in advance, then change the records to point at the Coolify proxy and confirm that HTTPS certificates issue for each production domain. Freeze writes to the Render database for the final data sync, take a last logical backup, and restore it into the Coolify database before switching traffic. Keep the Render services running so the rollback path stays open. Output: a signed-off cutover runbook with the exact record changes, the freeze window agreed by the business owner, the verification checks and the rollback steps, plus a post-cutover smoke test result.
Decommission Render after the retention window
Keep the Render services and databases in place through an agreed retention window, so the team can roll back and reconcile data if a problem appears late. Confirm that scheduled Coolify database backups run, that backups are stored off the server, and that a restore from them has been tested. Then delete Render resources and confirm the final invoice. Note that Coolify's documented rollback can redeploy an application image but does not restore databases or persistent files, so the restore test is your recovery plan. Output: a decommission record listing each deleted resource, the backup evidence and the owner who approved removal.

How Coolify builds and routes your services

Coolify connects to each server you add over SSH, prepares it to run Docker workloads, and then deploys your Render services from a Git repository, a Dockerfile, a Docker Compose file or a prebuilt Docker image. For a Render web service that already uses a Dockerfile, the Dockerfile build pack is the closest match and keeps your build behavior unchanged. For services that Render built with its native runtime, the Nixpacks build pack detects the language and produces an image without a Dockerfile, while Railpack, which Coolify lists as beta, is a newer option you should test before relying on it. Use the Static build pack for Render static sites, the Docker Compose build pack when a Blueprint defines several cooperating services, and the Docker Image method when you prefer to build in CI and pull a tagged image onto the server. Confirm the build pack behavior against the build pack documentation, since detection rules can differ from Render's build for your language version.

Each server runs one coolify-proxy container. Traefik is the default reverse proxy and Caddy is the alternative, and both route domains to your containers and obtain HTTPS certificates automatically. If you already terminate TLS at a load balancer or manage certificates yourself, the Custom (None) option hands routing and certificate handling back to you, which means you must configure ports, certificate renewal and redirects before cutover. Decide this before you move DNS, because a Render custom domain that points at a proxy without a valid certificate will fail for every visitor. The minimum host is 2 CPU cores, 2 GB RAM and 10 GB of free disk, on a supported Linux distribution (Debian, Ubuntu, the Red Hat family, SUSE, Arch, Alpine or 64-bit Raspberry Pi OS) on amd64 or arm64. Those are minimums, not sizing advice: build jobs, image storage and databases all compete for the same disk and memory, so size the host for your largest build and database, and confirm the figures against the installation documentation for your chosen version.

What drives cost and duration of the Render to Coolify move

This table breaks the move into cost components, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape the questions you put to a quote and to separate the migration project from the running cost of the platform. The main takeaway is that people time for inventory and rebuilds usually outweighs the server bill during the move, while the recurring cost depends on how many servers, databases and backup copies you keep.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Service inventory and mapping	Your platform or DevOps team, and an implementation partner if scoped	One-time	Number of web services, workers, cron jobs and static sites, plus undocumented environment values
Blueprint rebuild	Your engineers rebuilding render.yaml settings as Coolify applications or Docker Compose stacks	One-time	Blueprint size, number of sync: false variables re-entered, and any use of Render-specific features
Database export and restore	Your engineers running pg_dump or Render logical backups and restoring into Coolify	One-time, repeated for test restores	Database size, extension use, and how many rehearsal restores you run before cutover
Server capacity	Your infrastructure provider or data center, billed to you directly	Recurring	Number of servers, CPU, RAM and disk, which must meet Coolify's minimum requirements, plus headroom for builds
Backup storage and retention	Your object storage provider for S3-compatible targets	Recurring	Database size, backup frequency, retention by count, days or size, and whether you keep copies off-server
Coolify Cloud (optional)	Coolify, at $5 per month for 2 connected servers plus $3 per month for each additional server (source: Coolify pricing page)	Recurring, 20% discount for annual billing	Number of connected servers. You still bring the servers, and the Coolify instance runs on Coolify's managed infrastructure
Monitoring and on-call	Your operations staff, with any monitoring tools you add	Recurring	Number of services and databases to watch, alert routing, and whether you cover out-of-hours incidents
Compliance evidence	Your staff preparing evidence, and an independent auditor if you need an assessment	One-time setup, recurring collection	Regulatory scope, access logging requirements and how many systems hold regulated data
Quote request	Ask each provider to itemize people days, server sizing, storage, backup retention and any managed Coolify fees	Before work starts	Fixed scope and written deliverables reduce surprises; ask which items the quote excludes

What usually goes wrong in a Render to Coolify migration

Most Render to Coolify migrations fail at the handoff points, not in the application code. The cards below cover the items that Render supplies implicitly or that a parallel run exposes, and each one ends with a check to run before cutover.

Missed environment values

Render's Blueprint export marks environment variables with sync: false, so the file names the keys but holds no values. Teams that rebuild from render.yaml alone often deploy with empty secrets, missing API keys or stale database URLs that fail only on the first real request. Build an inventory of every key from the Render dashboard for each service, including worker and cron services, and enter each value in Coolify before the first deploy.

Postgres restore failures

Render logical backups are .dir.tar.gz archives in directory format and restore with pg_restore into an empty database. Restores fail when the target PostgreSQL major version is older than the source, when extensions the app depends on are not installed on the Coolify database, or when the restore is pointed at a database that already has objects. Confirm the source version and extension list first, create the target database with matching extensions, and run a test restore into a scratch database before cutover.

Cron jobs that run twice

During a parallel run, the Render cron job and the Coolify scheduled job both point at the same database and external APIs, so jobs such as invoice runs, emails or data syncs execute twice. The problem is easy to miss because each platform reports success. Disable or pause every Render cron job and worker that writes data before enabling its Coolify counterpart, and record which platform owns each schedule in your cutover log.

DNS and certificate gaps

Coolify runs a coolify-proxy container on each server, with Traefik by default or Caddy as the alternative, and both handle HTTPS automatically once the domain resolves to the new server. Gaps appear when DNS still points at Render, when a CNAME target changes, or when the Coolify server cannot complete the certificate challenge because port 80 or 443 is blocked. Lower DNS TTLs before the window, confirm the new certificate is issued, and keep the Render service live until traffic has moved.

Assuming rollbacks restore data

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. A team that cuts over, writes new records, then rolls back the application may find the database holds data the old code cannot read, or that uploaded files are gone. Take a fresh logical backup of Postgres and a copy of any persistent volumes immediately before cutover, and write down the restore procedure before the window opens.

Moving Postgres without losing writes at cutover

The core decision for the database is whether you accept a short write freeze or invest in logical replication to shorten it. A freeze is simpler: stop the Render web services and workers, take a logical backup from Render, restore it into the Coolify-managed PostgreSQL, and repoint the DATABASE_URL value. Render's logical backups are compressed .dir.tar.gz archives in directory format, restored with pg_restore into an empty database, and Render documents pg_dump with directory format and --jobs for large exports. Time the freeze with a dry run against a restored copy of production, because the freeze lasts as long as the dump, transfer and restore combined. Coolify's restore documentation accepts SQL dumps, custom archives, tar archives and all-database dumps, so the archive format is not the blocker.

If the write window must be shorter, logical replication is the better tool. PostgreSQL's upgrading documentation states that logical replication works between different major versions, which allows a major upgrade with only several seconds of downtime. The practical limit is that you must confirm the source and target can be configured for publication and subscription, that every table you need has a replica identity, and that sequences are synchronized at the moment you switch writes. Confirm with Render support or in your own Render environment which PostgreSQL major version and extensions the database runs, because extensions must exist on the Coolify target before any restore or replication starts. Supported versions today are 18, 17, 16, 15 and 14, with 14 supported only until November 12, 2026, so a target on 17 or 18 avoids a second upgrade soon after cutover.

Plan for the failure modes that Coolify will not handle for you. PostgreSQL does not detect a failed primary or notify a standby, so automatic failover requires external tools, and a single Coolify-managed database has no failover unless you build one. Coolify's scheduled backups cover PostgreSQL, but take a fresh backup of the target immediately after the restore and keep the Render export until the first successful scheduled backup has been restored in a test. Keep a rollback path by leaving the Render database read-only, not deleted, until the new system has run through a full business cycle.

How the migration differs by starting point

A small estate usually means one or two web services, perhaps a static site, and a single Render Postgres instance. The work is mostly sequential: create a Coolify server, deploy each service from its Git repository, move the database, then switch domains. Because there are few moving parts, one person can usually hold the whole cutover in their head, which keeps the change window simple to plan.

Sequence: Stand up the Coolify host first, deploy the services against a staging copy of the database, then repeat the final export and import during the cutover window.
Data work: Take a logical backup of the Render database with pg_dump in directory format, restore it with pg_restore into an empty Coolify PostgreSQL database, and compare row counts for key tables.
Configuration: Re-enter each environment value by hand from the Render dashboard, since generated Blueprints do not carry secret values.
Operating ownership: You become responsible for the server patching, the proxy, certificates and the database backup schedule, usually with one person on call.
Rollback: Coolify can redeploy a retained application image, but it does not restore the database or persistent files, so keep the Render database running until the new one is verified.

Before you start, confirm that your Render plan's database backup retention covers the cutover window and that someone owns the on-call duty after go-live.

Questions teams ask before moving from Render to Coolify

How much effort and cost should we expect when moving from Render to Coolify?

Expect the effort to scale with the number of services, databases, environment variables and cron jobs, plus how many of them depend on Render-specific behavior. Coolify itself is licensed under Apache-2.0, and the self-hosted edition is described on Coolify's pricing page as free forever with all features and no limitations, so the recurring costs are the servers you run it on, backup storage, and the people time for upgrades, monitoring and on-call. The one-time costs are the rebuild of Blueprint configuration, the Postgres migration and testing. Ask any provider for a quote that lists these components separately, with the number of services and databases in scope written down.

How long does the cutover take, and what sets the pace?

The pace is set by how many services and databases you move, how large the Postgres databases are, and how much testing each service needs before traffic moves. Database export and restore time grows with data size, which is why Render documents pg_dump with directory format and --jobs for parallel export of large databases. Plan a rehearsal on a copy of production, then a short freeze window for the final dump and restore. Ask your team or any implementation partner for a timeline based on your inventory rather than a generic duration.

What does the migration need from our internal team?

Your team needs to know which services depend on Render behavior, who owns each environment variable and secret, and who controls DNS and certificates. Someone must also be able to run Docker Compose stacks, read build logs and make decisions about server sizing. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on each Linux server, so confirm server access and capacity early. Name an owner for each cutover step before work begins.

Can our own engineers do the migration without an outside partner?

Yes, if your engineers are comfortable with Linux server administration, Docker, Git-based builds and PostgreSQL backup and restore. Coolify connects to each server over SSH, prepares it for Docker workloads and deploys from a Git repository, Dockerfile, Docker Compose file or prebuilt image. The harder parts are usually the operating work after cutover: patching, monitoring, backup verification and failover planning. If that capacity is not in place, consider a fixed-scope engagement that covers the migration and the handover documentation.

Is Coolify free, and what does Coolify Cloud cost?

The self-hosted Coolify edition is free under Apache-2.0, and Coolify's pricing page describes it as free forever with all features. Coolify Cloud is a separate paid option: it costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. With Coolify Cloud you still bring your own servers, while the Coolify instance itself runs on Coolify's managed infrastructure. Compare that fee with the cost of operating your own Coolify host and its backups.

How do backups and restores compare between Render and Coolify?

Render produces logical backups as compressed .dir.tar.gz archives in PostgreSQL directory format, restored with pg_restore into an empty database. Coolify's PostgreSQL backups use the pg_dump custom format, can be uploaded to S3-compatible storage, run on cron schedules and keep backups by count, days or size. Coolify's Import Backup also accepts SQL dumps, custom archives, tar archives and all-database dumps. Coolify's scheduled backups do not cover Redis, Dragonfly or KeyDB, so plan those separately. Rollbacks only redeploy an application image and do not restore databases or persistent files, so test restores before cutover.

What happens to preview environments after the move?

Coolify builds preview deployments for pull or merge requests from GitHub (through a GitHub App or webhook), GitLab, Gitea and Bitbucket. The default URL pattern uses {{pr_id}}.{{domain}}, which needs wildcard DNS, and Coolify deletes previews when the request is closed or merged. Render's preview behavior is not reproduced automatically, so confirm which branches need previews, set up wildcard DNS and test the webhook before you retire the Render workflow. Also decide who owns preview databases, since they hold data too.

How DeployOpen scopes and runs the Render to Coolify migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Render to Coolify migration, we begin with a written scope that maps each Render service, worker, cron job and Postgres database to a Coolify resource, then build and verify the move before any production traffic changes.

How we scope

Inventory every Render web service, background worker, cron job, static site and Postgres database, with its region, plan and custom domains
Map each Blueprint definition to a Coolify application, Docker Compose stack or database, and record which environment values must be re-entered
Agree in writing the deliverables, cutover approach and rollback conditions before work starts, as engagements are fixed-scope

How we build

Configure Coolify servers, the coolify-proxy container and build packs for each service, using Dockerfiles or Compose where Nixpacks does not fit
Restore a logical backup of each Render Postgres database into Coolify in a staging environment and compare row counts and application behavior
Test deploys, health checks, scheduled backups to S3-compatible storage and restore procedures before any domain is switched

How we hand over

Document each migrated service with its build settings, environment variable inventory, domain and certificate configuration and owner
Provide a cutover runbook covering DNS changes, the Render decommission sequence and the data freeze window agreed with your team
Write a restore runbook that states plainly that Coolify rollbacks redeploy application images but do not restore databases or persistent files

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after cutover, covering Coolify version changes and server patching
Review backup retention, restore test results and alerting with your operations team on the schedule agreed in the retainer
Confirm with your team which operational duties remain internal, such as on-call, monitoring and PostgreSQL minor version updates

Migrate from Render to Coolify