What you can export from Heroku, and what you cannot
A team holding a Heroku contract or renewal date can export four kinds of material: Postgres backups, config vars, app metadata and the application source, which already lives in Git. Everything else must be rebuilt on the target platform, including the dyno runtime and process formation, add-on configuration for services other than the database, routing and certificates, scheduled jobs and the build pipeline. Heroku's update on its sustaining engineering model focuses the platform on stability, security, reliability and support, and ends new Enterprise Account contracts. It does not announce a shutdown, so treat the export as a planning exercise with the renewal date as the deadline, not as an emergency.
Before you set that date, confirm the exact limits in Heroku's current Dev Center documentation: backup file formats, retention periods, download link expiry and any size ceilings. Then run a test. Take a full Postgres backup, restore it into a scratch database on the target platform, and compare row counts, extensions and sequences. If the target is Dokku, the dokku-postgres plugin provides postgres:import, so a restore test can run on a single server. Inventory config vars per app in a spreadsheet, separating ordinary settings from secrets. Secret values must come from the password manager or provider consoles where they were issued, so confirm that you hold them before the contract ends. List every add-on other than Postgres, because each one needs its own export path or a fresh instance seeded with reproduced data.
Some state will not move as data at all. Application logs and metrics history stay in Heroku's tooling, so decide now whether you need an archive, where it will live and what retention applies to your account. Team membership, pipeline settings and access history need a written record before access is removed. Domains, TLS certificates and DNS records are tied to Heroku's routing, so they are reissued and cut over on the new host as a separate step. Recreate buildpacks, Procfile process types and scheduler jobs on the target, then check each recreated item against a running copy of the app. A repeatable checklist like this turns the exit into a dated project that finishes before the contract does.
Which Heroku data can be exported and by which documented path
This table lists each class of Heroku data you may need to move, the documented export path for it, the output format, and the limit category to check. Use it as a checklist before a renewal date, because the limits set how far ahead you must start. The main takeaway is that the database is the item most likely to need a timed, rehearsed export, while the code and configuration files should already live in your own repository.
| Data type | Export method | Output format | Limits to confirm |
|---|---|---|---|
| Postgres database | pg:backups capture and download, or a direct pg_dump against the database for large or partial exports | pg_dump custom format from pg:backups; plain or custom pg_dump output from a direct export | Size and retention of stored backups, and expiry of the download URL; confirm current figures in Heroku's Postgres documentation |
| Config vars | Heroku CLI listing of config vars for each app, saved to a file you control | Key and value pairs as text, which you must store securely | Confirm any output or per-app limits in the Heroku CLI reference; treat exported values as secrets |
| App metadata (formation, add-ons, collaborators) | Heroku Platform API calls for formation, add-ons and app details | JSON responses from the API | API rate limits and authentication scope; confirm in Heroku's Platform API documentation |
| Application source | Git remote clone of the app repository, including any deployed branches | Standard Git repository history | Confirm that your deployed branch matches the repository you keep; a clone does not capture the build cache |
| Procfile and app.json | Files already committed in the application repository, reviewed before the move | Procfile text and app.json JSON manifest | Confirm which app.json features your target platform supports, since not all Heroku behavior carries over |
| Add-on data and settings beyond Postgres | Vendor-specific export for each add-on, such as Redis or other data services, taken separately | Varies by add-on and by vendor documentation | Each add-on has its own retention and export rules; confirm each one in its own documentation |
What does not export from Heroku and how to replace it
Source code, buildpacks and config can be recreated on another host, but some Heroku-managed parts never leave as files. Each card names one of these items, the workaround for it, and what to confirm with Heroku before the contract ends.
Managed runtime and Private Space infrastructure
Your dynos run on Heroku's managed Common Runtime or inside a Private Space, and that infrastructure cannot be copied. What moves is the application image or source, so the replacement is a rebuild on servers you control. Check which runtime each app uses, list any Private Space networking such as peering or VPN attachments, and plan the target network before cutover, since none of those settings come with the app.
Build caches and release history
Heroku keeps build caches and the slug history tied to your apps, and neither is an export format. On the new platform, the first build will be cold and may take longer, and rollback depends on images you keep yourself. Rebuild from the repository at the tagged commit, store the resulting images in a registry you control, and confirm with Heroku how long release history stays available to you.
Non-Postgres add-on state
Heroku Postgres has a dump path, but add-ons such as Redis hold data that you cannot pull through the same tooling. Treat each add-on as a new service: Dokku and Coolify both offer Redis, so rebuild the instance, decide whether cache contents can be rebuilt or must be migrated, and reconfigure the connection strings. Ask Heroku which add-on data exports it supports before you assume a copy is possible.
Logs and metrics history
Log streams and metrics on Heroku are retained for a limited window and are not a complete archive of past behavior. Before the contract ends, forward logs to a store you run and export any dashboards or alerts you rely on, because they will not appear on the new host. Ask Heroku what retention applies to your account and whether a bulk export of log data is available.
Managed certificates and DNS routing
Heroku issues and renews certificates for custom domains and routes traffic through its own edge. Those certificates cannot be transferred, so the new host must request its own, and DNS changes must be sequenced so traffic is not lost. Lower TTLs ahead of the move, re-issue certificates on the new proxy, and confirm that each domain validates before you point production traffic to it.
Team membership and access policies
Team roles, collaborator access and any SSO or access rules configured in Heroku do not export as files. Record who holds which role, then recreate those permissions on the new platform with the least privilege needed. Remove access on the Heroku side only after the cutover is verified, and keep audit records of both the old and new access lists.
Why the sustaining engineering shift changes the export timeline
On February 6, 2026, Heroku announced that it is moving to a sustaining engineering model focused on stability, security, reliability and support rather than new features, and that Enterprise Account contracts will no longer be offered to new customers. The announcement is about the future shape of the product and who can sign up for it. It does not switch off the platform for teams that already run apps on Heroku. Existing customers keep their apps, dynos, add-ons and contracts, and day-to-day operation does not change because of this announcement. What changes is the planning horizon: a platform that receives fewer new features and no new Enterprise Account sales is one where your renewal terms, pricing and product roadmap may move in ways you do not control.
That is why the export work belongs on a date you set from your own renewal calendar, not on the date a vendor change forces it. Start by listing every Heroku contract, add-on and Enterprise Account commitment with its renewal date and notice period, and confirm those terms in writing with your account team. Then work backward from the earliest renewal you could not comfortably exit at, and schedule the test migration, data export and DNS cutover well ahead of it. A trial export of one non-critical app, including a restore into a staging database, will show you which steps take the longest before the pressure is real. Teams that wait for a forced change usually discover missing backups, undocumented config vars or unsupported buildpack behavior in the middle of a renewal negotiation, when their options are narrowest.
The export sequence, from inventory to verified copy
This sequence turns the Heroku estate into a dated, checksummed set of artifacts you hold, so every app, database, config value and source file can be restored or rebuilt on a new platform without depending on Heroku still being available. Each step ends with a check and a named sign-off.
Inventory every app, add-on and config var
The platform owner lists each app, its process types, add-ons, custom domains, collaborators and config var names from the Heroku CLI and dashboard, and records the owning team beside each one. Config var values are not copied into this inventory at this stage. Confirm the list against the billing invoice for the period so no paid add-on or forgotten app is missed. The output is a signed inventory with one row per app and add-on, and the sign-off names the person who reconciled it with billing.
Export Postgres backups with pg:backups
The database owner creates a logical backup with Heroku's pg:backups capture for each Heroku Postgres database, then downloads the dump with pg:backups:download while the signed URL is still valid. For large or partial exports, the team also runs a direct pg_dump against the database connection string in custom format, so a second copy exists if the managed backup cannot be used. Verify each file by restoring it into a scratch PostgreSQL instance and comparing table row counts with the source. The output is a restored-and-counted dump per database, signed off by the database owner.
Export config vars into a secrets store
The security engineer reads each config var value with the Heroku CLI config command and writes it directly into a secrets manager that the organization controls, never into a shell history, a chat thread or a plain text file on a laptop. Keep the variable names in the inventory and compare the key count in the secrets store with the key count the CLI reported for each app. Confirm that access to the store is limited to named people and that the export terminal session was not logged to shared storage. The output is a store holding every key per app, signed off by the security engineer.
Capture app metadata through the Platform API
The platform engineer calls the Heroku Platform API to save app records, formation, add-on attachments, domains and collaborator lists as JSON files, one set per app, with the request time recorded in each file name. These files document what the app looked like at export and are the reference for rebuilding process types and scaling on the new platform. Compare the number of apps and domains in the saved JSON with the inventory from the first step. The output is a dated metadata archive, signed off by the platform engineer.
Archive source, Procfile and app.json
The development lead confirms that every app's Git repository is mirrored to a repository the organization controls, including all branches and tags, and copies the Procfile, app.json, buildpack configuration and runtime version files into the same archive. Check that the mirror's latest commit hash matches the deployed release commit recorded in the inventory for each app. Record which buildpacks each app uses, since that decides the builder on the new platform. The output is a mirrored repository set with matching commit hashes, signed off by the development lead.
Store artifacts with checksums and verify
The operations lead moves every dump, metadata file, config export record and repository bundle into storage the organization controls, then generates a SHA-256 checksum for each file and stores the checksum list beside the files. Re-download a sample of files from the new storage and confirm the checksums match, and confirm the object or file counts equal the counts recorded in earlier steps. Record the retention period and access list for the archive, and confirm with the compliance owner whether it must meet any internal retention rule. The output is a checksummed, verified archive with a final sign-off by the operations lead and the platform owner.
How to verify each exported data set before you rely on it
A dump file that exists is not proof that the database works. Restore the export into a scratch database on the target platform before the cutover, never directly into production, and treat that restore as the test. Compare the results against the source database as it stood at export time, using the same checks each time so the comparison is repeatable.
- Scratch restore: Load the dump into a throwaway PostgreSQL instance on the target, such as a Dokku Postgres service or a Coolify-managed database, and record the restore log and any errors.
- Row counts: Compare row counts for every table between source and restored copy, and keep the query output with timestamps.
- Key queries: Run a fixed set of business-critical queries against both copies and compare results, such as balances, order totals or the latest records per account.
- Extensions and roles: Confirm that required extensions and the application's database roles and grants exist on the target, since a missing extension can break queries without failing the restore.
- Evidence to keep: Restore logs, the row count table, query result hashes, the list of extensions and roles, and the name of the person who signed off.
Check that the restored copy is the same schema version the application expects before you point any environment at it.
Config vars carry the settings the application needs at runtime, and a missing one often causes failure only on a code path that runs rarely. Verify the names first, then the values, and never print the values while doing it. Work from the application's code and documentation rather than from memory of what the Heroku app used to do.
- Key inventory: Export the list of config var names only, then compare each name against references in the code, the
.envexamples and the deployment notes to find unused keys and undocumented ones. - Missing values: Confirm that every required key has a non-empty value on the target, using a check that reports presence and length rather than content.
- Log hygiene: Deploy to a staging app, trigger startup and a few representative requests, then search the build and runtime logs for the secret values or their prefixes to confirm nothing is echoed.
- Secret handling: Record which values were rotated during the move, since a value copied out of a Heroku export may still be live in the old environment and should be treated as exposed.
- Evidence to keep: The reviewed name inventory, the presence-check output, the log search result and the rotation record, with no secret values in the file.
Ask the application owner to confirm which keys are optional and which fail the app when absent.
App metadata describes how the application is meant to run: its process types, scaling, attached services and public addresses. These details are easy to lose because they live in several places. Build an inventory from the source platform first, then check each item on the target against that inventory.
- Process formation: Compare the Procfile process types and the number of instances for each against the formation recorded in the export, and confirm that the web process is running after deploy.
- Add-ons: Match every attached service, such as the Postgres, Redis or scheduler add-ons, to a replacement on the target, and mark any without a replacement as an open item.
- Domains: Confirm that each custom domain and its certificate resolve to the target, and that no domain is missing from the inventory.
- Release and cron tasks: Check that release-phase commands and scheduled jobs are present and run once on the target.
- Evidence to keep: The source inventory, a target inventory with the same fields, the diff between them and the list of accepted differences with an owner for each.
Ask the owner of each open item to confirm whether the gap is acceptable before cutover.
The source archive is the basis for every future build, so it must be a complete and buildable copy of the code the app runs. A clone that looks correct can still miss a file, a submodule or a build step. Verify by building, not by browsing the files.
- Clean clone: Clone the archive or repository into an empty directory on a machine with no prior state, and record the commit or tag that was checked out.
- Build on target: Run the build on the target platform, for example through a Dokku git push or a Coolify build, and confirm it finishes without manual steps.
- Dependency lock: Confirm that lock files and pinned runtime versions are in the archive, so the build on the target resolves the same dependencies as production.
- Runtime check: Start the built image or app and confirm it serves a health endpoint response before any traffic is sent to it.
- Evidence to keep: The commit hash, the clean clone log, the build log, the image or release identifier and the health check result.
Ask the team to confirm that the commit in the archive matches the commit currently deployed in production.
How the exported Postgres data restores on Dokku or Coolify
The restore path depends on which target you choose, and both are documented. On Dokku, the official dokku-postgres plugin provides postgres:import for loading a dump, plus one-off or scheduled backups to S3-compatible storage, and it installs PostgreSQL 18.6 by default. On Coolify, the Import Backup feature accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps, and Coolify's own PostgreSQL backups use the pg_dump custom format. Your export from Heroku should be in a format one of these tools accepts, so check that before you schedule the cutover.
Before restoring anything, confirm the PostgreSQL major version on the source and the target. Run SHOW server_version; against the Heroku database, then compare it with the version your Dokku or Coolify PostgreSQL service will run. Dokku's default is a specific minor release, and Coolify lets you pick the image, so the decision is yours to make and document. Restoring a dump into an older major version usually fails or produces a database your application cannot read, so align versions first and only then move data. Also check extensions, since a dump that depends on an extension the target image lacks will fail partway through.
Test the restore on a scratch server before touching production. Build a disposable Dokku host or Coolify server, restore the most recent export, and run the application's migrations, read queries and a sample of write paths against it. Record how long the restore took, the row counts on the largest tables and any warnings from the import, because those numbers become your cutover plan. Keep the scratch server as a rehearsal environment so you can repeat the restore after the next Heroku export. Ask your provider or the plugin maintainers to confirm the restore behavior for your exact versions, and treat any gap you find as a blocker for the renewal date, not a detail to fix later.
What to plan before the Heroku renewal or termination date
Most of the work before a Heroku exit is decision-making, not migration. Fix the contract dates, owners, retention rules and target platform first, then size the parallel run and the cutover around them. Each card below is a decision or input that is easier to settle now than under deadline pressure.
Renewal calendar and notice terms
List every Heroku contract, order form and invoice cycle, with its renewal date and the notice period that applies. Ask your Heroku account team to confirm the notice period and any Enterprise Account terms in writing, because the terms that apply to your contract are the ones that count. Heroku has said Enterprise Account contracts will no longer be offered to new customers, so check how your existing terms renew and whether any change to them is possible before your date.
Owner of each app and add-on
Name one accountable owner for every Heroku app, dyno formation, add-on and custom domain. Include who holds the Heroku login, who can approve a cutover and who answers when a database alert fires after the move. Unowned add-ons are the most common reason an exit stalls, because nobody can say whether a database is still needed or what it stores.
Retention for logs and backups
Decide how long you must keep application logs, database backups and exported data after the move, and which system holds them. Heroku backups and log drains do not transfer, so set a retention rule for the new platform before cutover. For Postgres on Dokku or Coolify, the backup schedule and retention settings are yours to configure, and a rollback does not restore databases or persistent files.
Target platform choice
Choose between Dokku on a single server, Coolify managed over SSH, or Kubernetes for multi-server growth. Dokku and Coolify suit small to mid-size app estates that fit on a few hosts, while Kubernetes adds control plane, etcd and upgrade work that your team must staff. Base the choice on how many apps, databases and servers you run, and whether an existing team already operates Kubernetes.
Parallel-run window and DNS cutover
Plan a period where the Heroku app and the new platform both serve traffic, so you can compare behavior and roll back. Lower DNS record TTLs before the window, then move each domain in a staged order and check certificate issuance on the new proxy. Confirm with the new platform's documentation how it handles HTTPS and wildcard DNS for each domain before you start.
Budget lines for servers and staff time
Budget for the new servers, storage, backup targets, monitoring, and the staff hours for setup, testing, cutover and on-call. Self-hosted platforms replace Heroku's per-dyno and per-database fees with infrastructure you rent and people you assign, so each line is recurring or one-time in a different way. Ask any implementation partner for a fixed-scope written quote that lists each component, and compare it against the Heroku invoice line by line.
What a rollback cannot recover after you leave
Once the team runs its own platform, capacity, backups and recovery belong to the operator. A managed platform carries those duties for you. On a self-hosted tool, a rollback is only part of the answer. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image, but it does not restore databases or persistent files. Plan for that gap before the first production cutover, not after the first bad release.
Treat the Heroku exit as two separate recovery problems. The first is application state: the image and config of each app, which a rollback can often handle if the image is kept. The second is data: Postgres contents, Redis data where persistence is configured, uploaded files and anything written to disk. Only the second needs a tested restore path. Check your scheduled backups on Dokku with the dokku-postgres plugin or on Coolify's database backups, and run a restore into a scratch database to confirm the dump is usable. Confirm which data stores your scheduled backups actually cover before you rely on them.
Keep the Heroku account, its final pg:backups archives and your exported config and app metadata until the new platform has passed its acceptance checks, including one restore test and one full redeploy. Ask Heroku in writing how long the account, backups and download links remain available after cancellation, and whether any data is deleted on a set date. Those dates should drive the renewal and cutover plan, not the other way around. A quote or migration plan should name who owns this retention window and who signs off the acceptance checks.
Questions teams ask before they export from Heroku
How much effort does a full export from Heroku take?
The effort depends mostly on the inventory behind it, and three factors drive it most: database size, the number of add-ons and the number of apps. Each Postgres database needs a dump, a restore test and a connection update, so one small database is a short task, while several large databases with long write histories need scheduled windows and more verification. Each add-on, such as Redis, scheduled jobs or log drains, needs its own replacement decision. Apps that share config vars or pipelines add coordination work. The last factor is knowledge. If only one person understands how a service is wired, the work slows until that knowledge is written down. Before estimating anything, gather a list of apps, process types, buildpacks, add-ons, config var groups and database sizes.
Can our own engineers export from Heroku without outside help?
Yes, for the documented paths. Your team can take Heroku Postgres backups, pull config vars through the CLI, and rebuild apps with git push on Dokku or with a Dockerfile on Coolify by following the vendor documentation. What an internal team often lacks is independent sign-off. Someone who owns production should decide cutover timing, approve the rollback plan and accept the restore results. Restore testing is the step most often skipped, and it belongs with that owner. DeployOpen can plan, implement and document the move under a fixed-scope agreement, or support a team that does part of the work. It does not issue audit reports or attestations. Decide early which steps your engineers own and which need a second set of hands.
How long does an export and migration take?
The duration depends on your inventory and the size of your databases, so no general figure applies. Start with a written list of apps, add-ons, buildpacks and domains. Then measure dump and restore times for each database in a staging copy, because a large database takes longer to create, transfer and load than a small one. Ask any provider, including DeployOpen, for a written scope with deliverables, dependencies and a timeline agreed before work starts. Ask them to name the steps that wait on your change windows, DNS changes and security reviews. Those waits often set the calendar more than the technical work does, so account for them when you plan around your renewal date.
Will Heroku export limits or download expiry block the work?
They can affect the work, and Heroku sets them, so confirm the current limits in Heroku's own documentation before you plan. Do not rely on a figure from memory or from a colleague's notes. Plan to download each backup as soon as it is created, store it in a location you control, and record a checksum. Keep a second copy in object storage that your organization owns. Test that the file restores in a staging database before any cutover. If a download link expires, confirm in the documentation and in your own account how Heroku handles a new backup request for the same database. Treat the download as part of the change itself, not as a task to finish later.
What must we provide to get a quote for the move?
A quote follows from a written scope, so gather the inventory before you ask. Provide the list of apps with their process types and buildpacks, add-ons with plan names and sizes, database sizes and write patterns, and the count of config vars without their secret values. Include custom domains and certificates, the target platform (Dokku, Coolify or Kubernetes), the number of servers you expect to run, and the names of the people who sign off. Share your Heroku renewal date. If you handle regulated data, state the compliance scope and any deadlines from finance or legal. Ask the provider to itemize implementation, data migration testing, hardening, backup setup and documentation separately, and to list what is excluded. Ongoing support and upgrades are usually quoted as a separate retainer.
How do we prove a database backup restores correctly?
A successful dump proves very little on its own, so run a restore test into a clean database on the target platform. Then run the application's migrations and smoke tests, and compare row counts or checksums for key tables. For PostgreSQL on Dokku, the dokku-postgres plugin provides export and import commands, so the test should use the same tooling that will carry production data. On Coolify, the Import Backup feature accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps, and the restore guide explains the steps. Record how long the restore takes, because that figure sets the minimum downtime window for cutover. Repeat the test on a fresh dump close to the cutover date, since data keeps changing until then.
Does Heroku's sustaining engineering shift affect our renewal timing?
Heroku's February 6, 2026 announcement says the company is moving to a sustaining engineering model focused on stability, security, reliability and support rather than new features. It also says Enterprise Account contracts will no longer be offered to new customers. That changes what Heroku sells and builds next, but it does not by itself mean existing services stop running. Read the announcement and your own contract for what it means for renewal terms, support and pricing. Then plan the move around your renewal date with enough margin to finish restore tests and a parallel run. Confirm any terms with your Heroku account team in writing, and keep those answers with your migration records.
How DeployOpen scopes and delivers a Heroku data exit
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Heroku exit, that means agreeing in writing which apps, databases and renewal dates are in scope before any migration work starts.
How we scope
- Inventory every Heroku app, process type, add-on and config var that the exit must carry across.
- Record the Heroku contract end and renewal dates so the cutover plan is timed around them.
- Agree the target platform in writing, whether Dokku, Coolify or Kubernetes, with the reasons stated.
How we build
- Install and harden the chosen platform on servers or cloud accounts that you own and control.
- Rebuild each app's build path from its buildpacks, Procfile or Dockerfile, and test it against staging data.
- Move datastores with a tested dump and restore, then run backup jobs and a restore test before go-live.
How we hand over
- Deliver runbooks for deploys, rollbacks, database restores, certificate renewal and access control.
- Document the cutover sequence, including DNS steps, the rollback point and who signs off each stage.
- Hand over backup retention settings and evidence of restore tests so your own team can run the platform.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan upgrade windows for the platform, its proxy and its databases against vendor release notes.
- Prepare the systems and evidence your auditors need, while independent auditors issue any attestation.
