How to export your data from Render

How to export your data from Render before the contract ends

A renewal, a price change or an EU residency requirement is forcing you off Render, and the data question comes first. Postgres data can be exported through documented paths: logical backups created from the database's Recovery page with Create export, or direct pg_dump and pg_dumpall exports to a machine you control. Service configuration, environment values and secrets are not exported in the same way, so they must be collected and rebuilt by hand. Two gaps matter early. Databases on the Free compute plan get no logical backups at all, and Render keeps each logical backup for seven days regardless of workspace plan, so an export is a short-lived copy you must move off the platform promptly.

Start with an inventory of every database, then check each one's plan and recovery settings. For paid databases, create an export and download the compressed .dir.tar.gz archive, which is in PostgreSQL's directory format. Only one export can run at a time per database, so schedule these around your cutover window. Confirm the Render PostgreSQL version against the target you plan to run, because the restore path depends on it. Run a direct pg_dump as a second copy, and restore both only into an empty database, as Render recommends.

Environment variables need separate handling. Render's generated Blueprint files mark environment variables with sync: false and omit their values, so the secrets behind each service are not in the file you download. Export your service list and Blueprint from the dashboard, then record every key and value from each service's environment settings in a secure store, including DATABASE_URL and third-party API keys. Ask your security team to confirm where those secrets may be kept during the move, and rotate any credential that has been shared outside the vault.

Which Render data you can export and how

This table compares each kind of Render data with the method that exports it, the format you receive and the limits that apply. Read it as a checklist: the Postgres rows carry the time-sensitive limits, so start those exports first. The main takeaway is that Render's logical backups expire after seven days, so keep your own copies.

Data type	Export method	Format	Limits to plan around
Postgres logical backup	Create export from the database's Recovery page	Compressed .dir.tar.gz archive in PostgreSQL directory format	One export at a time per database; retained seven days regardless of workspace plan
Single Postgres database	pg_dump run against the Render Postgres connection from your machine	Dump file you choose via pg_dump options	Restore only into an empty database on the target
Whole Postgres instance	pg_dumpall run against the instance	All databases and roles in one dump	Restore only into an empty database; confirm the connection rights your plan allows
Databases on the Free compute plan	Logical backup export not available	Not applicable	No logical backups are created; use pg_dump while the database is reachable and confirm its availability first
Blueprint configuration	Copy the render.yaml Blueprint from your repository	YAML infrastructure-as-code file	Generated files omit environment variable values, which are marked sync: false
Environment variable values	Collect from the Render dashboard or your secret store	Key and value pairs kept outside the Blueprint	Must be collected separately because Blueprints do not carry the values

What does not export from Render and the workaround for each

Render's export tools move database contents and Blueprint files, but several parts of a running service stay behind. The cards below cover each gap, the reason it exists, and the step that closes it before you cut over. Work through them before you start the export so nothing is lost after the Render workspace is shut down.

Environment variable values

Render's generated Blueprint files mark environment variables with sync: false, so the file lists the variable names but not their values. Every value that your services read at runtime has to be collected from the Render dashboard for each service and worker. Record the names and values in a secrets manager, then re-enter them in Coolify or Dokku before the first deploy. Check that each variable exists on every service that used it, since shared values are easy to miss.

Secrets stored outside Blueprints

Secret files, API keys added through integrations, and values pasted into the dashboard by hand have no export path at all. Some teams keep them only in a developer's password manager or in a deploy hook they forgot about. Inventory every service, cron job and integration in the Render workspace and list where each secret is consumed. Rotate any credential you cannot account for once the new environment is running.

Service settings missing from Blueprints

Health check paths, custom domains, build and start commands, instance sizes, auto-deploy branches and notification settings may not appear in a Blueprint file, depending on how the service was created. Compare each service's dashboard settings with the exported file line by line. Write the missing settings into your Coolify application or Dokku app.json and Procfile, then confirm each one with a test deploy.

Persistent disk contents

A persistent disk attached to a service holds files that a Git rebuild will not recreate, such as uploads, generated reports or local caches that matter. Render's logical backups cover Postgres only, so the disk contents need their own copy. List which services have a disk attached, copy its files with a tool that runs in the service's shell, and move them to object storage or a volume on the new server before cutover. Confirm each copy by checking file counts and sizes.

Free plan databases without backups

Render does not create logical backups for databases on the Free compute plan, so an export from the Recovery page is not available for them. A direct pg_dump may still work if the database accepts external connections, but confirm this in the Render dashboard before you rely on it. If it does not, plan for a fresh application-level export and accept that data written after your last copy will be lost. Check the compute plan of every database early in the project.

Exports older than seven days

Render keeps each logical backup for seven days after creation on any workspace plan, so an export taken weeks before cutover is gone. Old archives cannot be recovered from Render support once they expire. Take a fresh export within the last few days before the final switch, then verify it restores into an empty database on the target host. Keep a dated copy of every archive outside Render so the rollback path does not depend on the retention window.

The sequence for a complete Render export with verification

This sequence turns a Render workspace into a set of verified copies: configuration files, logical database exports, a second pg_dump copy, and collected environment values, each tested by a restore before you rely on it.

Inventory services, databases and Blueprint files
Start by listing every web service, background worker, cron job, static site, Postgres database and Key Value instance in the workspace, and note which ones are defined in a Blueprint file. Commit or download the render.yaml Blueprint for each repository so the service types, build commands, start commands, regions and disk settings are preserved outside Render. You are done when every resource in the Render dashboard has a matching line in your inventory and each Blueprint is stored in a repository you control.
Confirm each database is on a paid plan
Check the plan of every Postgres database before you export. Render does not create logical backups for databases on the Free compute plan, so a Free database has no Render-generated export to download and needs a pg_dump run instead, while still producing a full copy of the data. Record the plan and the Postgres version for each database, and confirm the version with your target platform before you plan the restore.
Create and download the logical export
On each paid database's Recovery page, select Create export. Render produces a compressed .dir.tar.gz archive in PostgreSQL's directory format, and only one export can run at a time per database, so wait for each to finish before starting another. Download the archive promptly, because Render keeps logical backups for seven days after creation regardless of workspace plan. You are done when the archive is stored in your own backup location and its size looks plausible for the database.
Run pg_dump or pg_dumpall as a second copy
Use the connection details from the database dashboard to run pg_dump against each database, or pg_dumpall for the whole instance, from a machine you control. Render documents these methods for exporting to a local machine, and this copy is independent of Render's export archive, so a problem with one does not remove the other. Store the output with a checksum and note the time it was taken. You are done when each dump file completes without errors and its checksum is recorded alongside the Render archive.
Collect environment values separately
The Blueprint files omit environment variable values, marking them sync: false, so the values must be gathered from the Render dashboard for each service, worker, cron job and static site. Include secrets, connection strings for Key Value instances, and any values set through Render's environment groups. Store them in a secrets manager or other encrypted store, not in a plain document or repository. You are done when every key listed in the Blueprint and the dashboard has a stored value and a named owner who can confirm it.
Restore into an empty database and check it
Restore each export into an empty database on the target platform, which is the only restore target Render recommends, and do not restore over a populated database. Restore the directory-format archive with pg_restore and the pg_dump file with psql or pg_restore as appropriate. You are done when each restore finishes without errors, and you have kept the restore log.
Compare row counts and key tables
Compare the restored database with the source using the same queries on both sides. Start with row counts for every table, then check key tables such as accounts, orders or other records your business cannot lose, and confirm sequences and extensions are present. Where Render is still reachable, run the queries against the live source before the cutover, and keep the results. You are done when the counts and key-table checks match, or each difference has a documented explanation and an agreed owner.

How to check that a Render export is complete and restorable

Restore every archive into an empty PostgreSQL instance before you rely on it. A Render logical backup is a compressed .dir.tar.gz file in PostgreSQL's directory format, and the file existing in your storage does not prove that it restores. Render's guidance is to restore exports only into an empty database, so create a scratch database on infrastructure you control, run the restore with pg_restore into it, and check for errors in the output. Keep the restore log with the export file so that the evidence of the check travels with the data.

Once the restore completes, compare the restored database with the live Render database in three ways. First, compare object lists: schemas, tables, indexes, sequences, views, functions and triggers, using pg_dump --schema-only on both sides and a diff of the output. Second, compare row counts per table, and for tables where exact content matters, compare a checksum such as an ordered hash of the rows. Run the live comparison while the application is paused or in a read-only window, because counts taken during writes will not match. Third, confirm extensions and roles. Check pg_extension against what the application uses, and check that the roles and ownership referenced by objects exist, since a logical restore does not recreate the cluster-level settings you may have relied on.

Choose a target major version that is still supported, such as the versions listed on the PostgreSQL versioning policy, and confirm that your restore target runs the same or a compatible major version as the source. Ask your target platform, whether it is Coolify, Dokku or another host, which PostgreSQL versions it installs and which extensions it ships, and test the restore against that exact version. Note any gaps as findings to resolve before cutover, not after.

What to plan before the Render contract renews or ends

Leaving Render is mostly a sequence of decisions with deadlines attached. The cards below cover the items that determine whether data, domains and secrets arrive intact, and they should be settled before anyone schedules a cutover date.

Export window against retention

Render keeps logical backups for seven days after creation, whatever the workspace plan. Any export you rely on must be created, downloaded and verified inside that window, so plan the export as a dated step rather than a file you assume exists later. Confirm with Render support how long data remains after the account or workspace is closed and when deletion happens.

Dated cutover plan

Write down the order of work: export each database, restore it into the target, repoint services, then switch traffic. Give each step an owner and a rollback point, because a PaaS rollback does not restore databases or persistent files on the new host. Illustrative example: a team exports on a Tuesday, verifies a restore on Wednesday, and moves traffic after a second export.

DNS and certificate ownership

Find out who controls the DNS zone and whether certificates are issued by Render or must be reissued on the new host. Lower record TTLs ahead of the switch so a rollback is quick. Coolify runs Traefik or Caddy to handle HTTPS, and the new routing layer needs the domain records pointed at it before traffic moves.

Secrets inventory

Render's generated Blueprint files mark environment variables with sync: false and omit their values, so the secret values are not in your repository. Build a list of every variable each service uses, record where its value currently lives, and collect the values through a secure channel. Missing secrets are the most common reason a migrated service fails to start.

Backup storage location

Decide where export archives will live before the first export runs. Coolify can upload PostgreSQL backups to S3-compatible storage, and Dokku's Postgres plugin supports S3-compatible backups too. Confirm the bucket region, access controls and retention settings your data policy requires, and keep a copy outside the new host.

Read-only freeze period

Choose a window in which the application stops accepting writes, so the database export captures a consistent state. Agree who can approve a freeze, how long it lasts and how users are told. Restoring exports only into an empty database, as Render recommends, keeps the freeze from being undone by a partial import.

Questions teams ask before exporting data from Render

How much effort does a full data export from Render take?

The effort depends on how many Postgres databases you run, how large each one is, and how many environment values and secrets you must collect by hand. Logical exports from the Recovery page are one step per database, but each archive must then be restored into an empty database on the target platform and checked. Environment values are not included in Blueprint files, so the collection step often takes longer than the database copy itself. Ask your team to inventory databases, sizes and environment variables before estimating the work, and request a written scope that lists each item.

Can our own engineers export everything from Render without outside help?

Most teams with a working knowledge of PostgreSQL and their own deployment setup can perform the export themselves. Render documents exports with pg_dump for a single database and pg_dumpall for every database in an instance, and it recommends restoring only into an empty database. The harder parts are usually rebuilding services, mapping background workers and cron jobs, and verifying that the restored data behaves correctly in the new environment. If no one on the team has run a restore before, plan a dry run on a copy first and confirm the skills you need against your own environment.

What skills and staff time does a Render data export require?

At minimum you need someone who can run pg_dump and pg_restore, someone who owns the application configuration, and someone who can approve the cutover. Staff time goes to inventorying databases and secrets, testing restores, updating connection strings, and checking application behavior after the switch. Security or compliance staff may also need to review where the archives are stored and who can read them. Ask for a named owner for each step and agree on who signs off on data integrity before the export begins.

Do logical backups from Render cover databases on the Free plan?

No. Render does not create logical backups for databases on the Free compute plan. If a Free plan database holds data you need, you must export it directly with pg_dump or pg_dumpall while you still have access, because Render will not produce a logical archive from the Recovery page. Check each database's compute plan in the Render dashboard before you plan the export, and do not assume that a database in a paid workspace is on a paid compute plan.

How long does Render keep logical backup exports available?

Render retains logical backups for seven days after creation, regardless of workspace plan. After that window, the archive is no longer available from Render, so you should download it, store it in your own location, and verify it within that period. Render allows only one export at a time per database, so schedule exports so that a failed attempt can be repeated within the retention window. Confirm the current retention terms with Render before relying on them for a regulated retention requirement.

What changes if we need point-in-time recovery after leaving Render?

Logical exports capture a database at the moment they run, so they do not provide point-in-time recovery. Recovering to an arbitrary moment requires continuous WAL archiving and a base backup, which PostgreSQL documents as continuous archiving and point-in-time recovery. On a self-hosted platform, the operator owns that setup, including storage, retention and restore testing. Coolify's scheduled PostgreSQL backups use the pg_dump custom format, which is a logical method, so confirm with your platform team whether point-in-time recovery is needed and how it will be configured.

Does a self-hosted platform restore our Render environment values automatically?

No. Render's generated Blueprint files mark environment variables with sync: false instead of including their values, so secrets must be collected separately from the Render dashboard or your secret store. Plan to record every variable per service, confirm which values are secrets, and store them in a location your team controls. Coolify and Dokku will not import those values from a Blueprint, so each one must be entered again on the target platform and tested before cutover.

Should we export Render data before deciding on a new platform?

Yes, export and verify your data before committing to a target platform, because the seven-day retention window applies regardless of your decision. Take logical backups of every paid database, record every environment value, and store the archives in a location you control. This keeps your options open while you compare Coolify, Dokku and other paths. Ask any implementation partner for a written scope that starts with a data inventory and a verified restore on a test instance.

Where exported data goes once it leaves Render

The target side of an export is a Postgres database you run, a bucket for the archives you keep, and a service definition you rebuild by hand. On Coolify, the PostgreSQL database is deployed from the Coolify databases catalog, and its Import Backup function accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps, so a directory-format export from Render can be restored through the same workflow used for any other backup. On Dokku, the dokku-postgres plugin provides postgres:import for the same job, and linking the service sets DATABASE_URL on the app. Before you restore anything, confirm which PostgreSQL major version your target runs, because Render's version and your server's version need to be compatible with the dump you took.

Keep the archives in S3-compatible object storage that you control, separate from the database host. Coolify can upload its scheduled PostgreSQL backups to S3-compatible storage, and the dokku-postgres plugin runs scheduled backups to the same kind of target, so one bucket with a retention rule can hold both your Render exports and your new scheduled dumps. Decide who can read that bucket, how long you keep Render-era archives after cutover, and whether the bucket sits in the same region as your data. Those choices carry compliance and privacy weight, so record them before the first archive lands.

Blueprint files do not carry secrets, so the target side starts with a list rather than a file. Use the render.yaml Blueprint to inventory services, workers, cron jobs and databases, then rebuild each one as a Coolify application or a Dokku app with its own process definitions. Environment values marked sync: false must be collected from the Render dashboard and entered on the target. For the full cutover sequence, including DNS, certificates and the order of restores, follow the Migrate from Render to Coolify guide for Coolify or the Dokku migration guide, which cover those steps in detail.

Export approach by team size and database count

A small team with one web service and one Postgres database can usually complete the export from the Render dashboard. Open the database's Recovery page, select Create export, and download the resulting compressed .dir.tar.gz archive once it is ready. Render keeps logical backups for seven days after creation, so the export is a short-lived copy that you must move off Render within that window. Because only one export can run at a time per database, a single export is the normal case here.

Export source: Use the Recovery page export for the database, which produces PostgreSQL directory-format archives.
Retention clock: Note the creation time and download the archive well before the seven-day retention ends.
Plan check: Confirm the database is not on the Free compute plan, because Render does not create logical backups for those databases.
Restore target: Plan to restore into an empty database on the new host, as Render recommends for exports.
Secrets: Record the environment values separately, since the Blueprint file does not contain them.

Before you start, confirm the database plan and the exact retention rule in Render's current documentation, because limits can change.

How DeployOpen works on this

DeployOpen plans and carries out the export as a fixed-scope engagement inside your own infrastructure, so the Postgres dumps, environment values and Blueprint notes are collected, checked and handed over under written terms. The work covers the Render side of the export and the first restore on infrastructure you control.

How we scope

Inventory every Render Postgres database, its compute plan and whether logical backups exist for it
Flag databases on the Free compute plan, which receive no logical backups, before any cutover date is set
Agree in writing which dumps, environment values and Blueprint files are in scope and who holds the secrets

How we build

Run Create export from each database Recovery page and download the directory-format archives within the seven-day retention window
Take direct pg_dump and pg_dumpall copies as a second path, and verify restores into an empty target database
Rebuild environment values and secrets from a separate collection step, since Blueprint files omit their values

How we hand over

Deliver checksummed archives, restore notes and a record of each database's source version and row counts
Document the Blueprint-to-deployment mapping and the list of values you must re-enter on the new host
Provide a runbook for repeating the export, including the one-export-at-a-time limit per database

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after handover
Quotes follow from the written scope, so ask for the cost components and recurring items to be itemized

How to export your data from Render