Migrate Heroku to Coolify or self-hosting

Do you want to replace Heroku while retaining controlled deployment and operations? WZ-IT provides Heroku migration from EUR 1,990 excluding VAT through target acceptance and can take over ongoing operations.

A migration from Heroku to Coolify or self-hosting translates a mature PaaS model into explicit components. Dynos, Procfile, buildpacks, config vars, add-ons, pipelines and Heroku Postgres need to keep working on the target or be replaced deliberately.

Inventory the Heroku application and pipeline

Capture in particular:

• apps and their Heroku Pipeline assignment
• staging, review and production environments
• dyno types, counts and resources
• process groups in the Procfile
• buildpacks, runtime versions and system dependencies
• config vars and secret use
• add-ons and their actual function
• Heroku Postgres, Redis, storage and external data paths
• scheduler, release phase and one-off dynos
• domains, TLS, email, webhooks and OAuth callbacks
• logs, metrics and alerting

The add-on list alone is insufficient. For every service, determine which data it holds, how the application connects and which export or replacement path is available.

Map dynos and the Procfile

A Procfile describes start commands, but not the complete operating model. Add health checks, resources, restart, concurrency, logging and scaling on the target.

Replace buildpacks with reproducible builds

Buildpacks detect language and dependencies partly automatically. During exit, make the build explicit and reproducible. Depending on the application, this becomes a Dockerfile or a transparent target-platform build configuration.

Validate:

• runtime and package versions
• lockfiles and private registries
• operating-system packages and native libraries
• build and release scripts
• static assets and compilation steps
• start command and expected ports
• behaviour across multiple instances

Produce the build independently of Heroku and start it in an isolated target environment first.

Replace add-ons by function

Heroku add-ons may provide databases, cache, queues, email, monitoring, logging, search or object storage. Replace the required function and data path, not merely the product name.

For each add-on document:

1. data and configuration
2. export and import path
3. target product or retained external service
4. new connection details and secret rotation
5. acceptance and rollback
6. later cancellation or retention

Migrate Heroku Postgres

Heroku documents export and import paths for Postgres. Capture database version, size, extensions, roles, connections, pooling, write activity and permitted outage before selecting the method.

After restore, validate more than table counts. Include sequences, constraints, functions, triggers, extensions, time zones and critical business queries. Test the application against the new database in staging first.

Staging, review apps and Git deployment

Git-based deployment remains possible. Heroku Pipelines and Review Apps do not automatically translate one to one. The target can provide fixed staging and production environments and optional short-lived previews.

Define branches, secrets, data access, domain, approval, health check and rollback separately. Preview environments must not alter production data unintentionally.

Cutover and ongoing operations

Before switching, validate web processes, workers, scheduler, data, email, webhooks, restart, logs, monitoring, backup and restore. Cutover coordinates in-flight jobs, write boundaries, final data sync, domain change and smoke tests. Keep the source available through the agreed rollback window where the data model and contract permit it.

For several applications or unknown add-ons, the PaaS Exit Review can be the more appropriate first step.

Sources

• Heroku: The Procfile
• Heroku: Config Vars
• Heroku: Postgres Import and Export
• Heroku: Buildpacks