A Heroku alternative in Europe: from PaaS to your own cloud without a platform team

A B2B product has been running on Heroku for years: three Standard-2X dynos (two web, one worker) with 1 GB of RAM at $50 a month each, plus Heroku Postgres on the Standard tier from $50, so $200 a month in total as of October 2026. It works. Then management reads that Heroku is no longer building new features and asks for a plan B. A Heroku alternative is a platform that keeps the convenient workflow – push the code, the app runs – while putting the cost, location and future of the infrastructure in your hands.

Why do teams look for a Heroku alternative?

• The end of the free plans. Since 28 November 2022 there have been no free dynos and no free plans for Heroku Postgres and Redis.
• The price per dyno. A Standard-1X with 0.5 GB of RAM costs $25 a month, a Performance-M with 2.5 GB $250 (as of October 2026). Add-ons such as the database come on top; the bill grows with every dyno.
• The regions. The Common Runtime has two regions, “eu” and “us”. Specific locations such as Dublin, Frankfurt or London exist only in Private Spaces, a separate, isolated runtime.
• The future. On 6 February 2026 Heroku announced its move to a “sustaining engineering” model: stability, security, reliability and support, but no new features; Enterprise contracts are no longer offered to new customers. According to Heroku, nothing changes in pricing or operations for existing customers.

What Heroku does well – and what you have to replace

Heroku set the standard: push the code and the app runs, the database is an add-on, the configuration lives in config vars. Moving means replacing each building block:

• Build from Git: usually a Dockerfile instead of buildpacks, built in the cluster or in GitHub Actions.
• Config vars: become environment variables; passwords and keys belong in write-only secrets.
• Postgres add-on: becomes a managed database with a private endpoint, reachable only from the cluster.
• Logs: heroku logs --tail becomes a log viewer across the pods; keeping logs for months needs a log service.
• Scaling: a fixed number of replicas or an autoscaler instead of the dyno formation.
• Domains and TLS: an ingress controller with cert-manager for Let’s Encrypt certificates, plus the DNS records.

Which options are there?

1. Another PaaS. The shortest route: the workflow stays almost the same, and several European providers run data centres in the EU. But you swap one PaaS for the next: compute at a bundle price, data with the provider, exit by migration again.
2. Managed Kubernetes on your own. Scaleway Kapsule in your own account, say: nodes at list prices, full control – but you build and maintain the build, ingress, certificates, database connection, backups and upgrades yourself, a platform team’s work.
3. Managed Kubernetes plus a control plane. As with option 2, the infrastructure sits in your account, and a platform takes over the Heroku part: build, deploy, databases, domains, certificates and running the cluster. That is Clusterward’s approach – bring your own cloud on Scaleway in Paris, Amsterdam or Warsaw.

Two questions decide which option fits: who should own the infrastructure, and who has time to run it? Two such control planes are compared in Clusterward vs. Qovery.

How does a migration from Heroku work?

1. Take stock. Process types from the Procfile, dynos, add-ons, config vars, domains – each gets its replacement from the list above.
2. Build a container. Write a Dockerfile and run it locally. The app listens on a fixed port; if it reads it from PORT, set the variable yourself.
3. Set up the target. Cluster, managed database with a private endpoint, service with port, resources and replicas.
4. Carry over the configuration. heroku config lists the config vars. Create passwords and keys as secrets, the rest as variables; the new DATABASE_URL points at the new database.
5. Dry run. Deploy, copy the data once, check everything under a test domain – sign-in, background jobs, uploads, emails.
6. Cut-over. Lower the DNS records’ TTL to a few minutes the day before, stop writes on Heroku, copy the data a final time, switch DNS. Delete the Heroku app only after days of silence.

Typical pitfalls when moving

• The database URL. On Heroku, DATABASE_URL appears in the config vars automatically, and Heroku may change it after a failover or a credential rotation. After the move you enter the connection details yourself, once.
• TLS to the source. Heroku Postgres requires sslmode=require; databases on Private and Shield plans cannot be reached from outside at all, so export from inside the space.
• What the buildpack did silently. System packages, the asset build, the right language version – it all has to be in the Dockerfile now.

What Clusterward replaces – and what it doesn’t

Clusterward covers the Heroku part on Scaleway Kapsule, in your own Scaleway project:

• Builds from Git, inside the cluster without a Docker daemon or via GitHub Actions; a short workflow with an API token deploys on every push to main (deployments).
• Environment variables and secrets, in Scaleway Secret Manager if you like. After a change the service page shows “restart pending” until you restart.
• Managed PostgreSQL or MySQL with a private endpoint only (managed databases). A service’s database is created in one step; you copy the DATABASE_URL into the variables yourself. The import pulls the data straight from a Postgres URL, Heroku’s included, and stops the app while it runs.
• Logs of all pods merged, up to 10,000 lines, including the crashed run; uptime checks, notifications and rollback to an earlier version.
• Domains with Let’s Encrypt or wildcard certificates, DNS records created automatically in registered Cloudflare or Scaleway zones, scheduled jobs as CronJobs.

What is missing: preview environments per pull request – if you work with review apps today, you lose them when you switch. There is no add-on marketplace; Redis, search or email delivery you book yourself. Logs are not kept beyond a pod’s life, and the autoscaler scales on CPU only.

Conclusion

Finding a Heroku alternative is easy; the right one depends on who should own the infrastructure afterwards. Another PaaS is the shortest route, managed Kubernetes the most independent – and a control plane on top keeps it from becoming a platform-team project. List the building blocks first, and you move in stages rather than over one weekend.

Planning to leave Heroku? Send us your list of dynos and add-ons. We’ll tell you what maps one to one in Clusterward and what doesn’t. Ask a question →

Sources and further reading

• Heroku blog: An update on Heroku
• Heroku Dev Center: End of the free plans
• Heroku: Pricing
• Heroku Dev Center: Regions
• Heroku Dev Center: Connecting to Heroku Postgres