Decent Newsroom
Sign In

Heroku add-ons mapped to self-hosted containers

By Peon October 30, 2026
A practical mapping of common Heroku add-ons to open source services you can run in Docker.

Heroku apps often depend on a handful of add-ons provisioned years ago. When moving to your own server, each needs a replacement. Most have a well known open source equivalent that runs in a container next to your app.

Heroku Postgres

Replace with the official postgres image, matching the major version. Migrate with pg_dump from the Heroku URL and pg_restore on the new server. Add scheduled backups to object storage, because Heroku’s continuous protection does not come with you.

Heroku Data for Redis

Use redis or valkey. Enable AOF persistence if it backs a job queue. Set maxmemory and an eviction policy that matches the use: allkeys-lru for caches, noeviction for queues.

Heroku Scheduler

Replace with scheduled tasks in your deployment platform or a cron container. Heroku Scheduler runs one-off dynos; the equivalent is running a command in a fresh container from the same image.

Papertrail, Logtail and log drains

Self-hosted options include Loki with Grafana, or simply good container log rotation plus a searchable UI from your platform. Start simple; many small apps only need recent logs and a way to search them.

New Relic, Scout and APM

For errors, self-hosted Sentry or GlitchTip. For metrics, Prometheus with Grafana, or the built-in metrics of your platform. Lightweight setups often skip full APM until a real performance question appears.

SendGrid, Mailgun and email add-ons

Keep using a transactional email provider directly. Running your own outbound mail server is rarely worth the deliverability work.

Bucketeer and S3 add-ons

Point the app at an S3 compatible bucket from any provider. Copy files with rclone.

Heroku Connect, Kafka and specialized add-ons

These are harder to replace. Consider keeping a managed service for them, even if the app moves.

Config vars

Heroku add-ons inject variables like DATABASE_URL and REDIS_URL. Keep the same names on the new platform so the app code does not change.

Order of migration

  1. List every add-on and its plan
  2. Decide replace, keep managed or drop
  3. Stand up replacements and migrate data
  4. Move the app last

Most teams find that half their add-ons are no longer used. Dropping them is the easiest saving of all.

For a broader look at platforms that replace Heroku’s workflow, see this guide to Heroku alternatives in 2026.

Disclosure: I work on Peon.

#heroku #migration #self-hosting
Write a comment