Migrate from Heroku

10 min readUpdated April 2026

Most Heroku apps migrate to StackBlaze in under an hour. StackBlaze understands Procfiles, can build your app with Cloud Native Buildpacks (the same standard Heroku uses), and has direct equivalents for every common Heroku add-on, Postgres, Redis, and scheduled jobs included.

Unlike Heroku, StackBlaze runs on dedicated bare-metal Kubernetes. There are no dyno hour limits, no sleeping on inactivity, and no shared compute. Your app gets a fixed slice of CPU and memory that belongs to it alone.

No dyno sleeping

Always-on dedicated pods

No dyno hour caps

Unlimited runtime per month

Dedicated resources

CPU + RAM never shared with others

Migration overview

config varsPostgres add-on→ StackBlaze env vars→ Managed PostgreSQL
Heroku App

Procfile + config vars

Postgres add-on

Env Variables

DATABASE_URL

REDIS_URL, PORT …

Postgres

heroku-postgresql

Essential-0 plan

StackBlaze

Web + Worker services

Managed Postgres + Redis

Step by step

01

Export your Heroku config vars

Run the Heroku CLI to export all environment variables as JSON, then paste them into the StackBlaze environment variables panel. StackBlaze imports them in bulk, no re-typing needed.

# Export config vars from Heroku

heroku config -a my-app --json > env.json

# Review the output

cat env.json

02

Connect your GitHub repository

StackBlaze deploys from the same GitHub repo Heroku does. Click "Add Service", choose GitHub, authorise StackBlaze, and select the repo. No changes to your repository are required.

03

Auto-detect your Procfile

StackBlaze reads your Procfile automatically. A "web:" process type becomes a Web Service (Deployment + Ingress + TLS). A "worker:" process type becomes a Background Worker (Deployment without public ingress). Additional process types like "release:" are run as Kubernetes Jobs before the new pods start.

# Procfile

web: node dist/server.js

worker: node dist/worker.js

release: node dist/migrate.js

04

Provision add-on equivalents

Create managed services directly from the StackBlaze dashboard: Heroku Postgres becomes StackBlaze PostgreSQL, Heroku Redis becomes StackBlaze Redis, and Heroku Scheduler becomes a StackBlaze Cron Job. Each service runs in your private cluster network.

05

Wire up DATABASE_URL and REDIS_URL

Attaching a managed add-on to your app injects its connection string automatically, so DATABASE_URL and REDIS_URL point at the new StackBlaze services with no manual editing. If you kept placeholder values from Heroku, remove them so the injected ones take over.

06

Test with a staging deploy, then go live

StackBlaze supports multiple environments. Deploy to a staging environment first, run your smoke tests, then promote to production. Attach your custom domain under Settings → Domains, StackBlaze provisions a TLS certificate automatically via cert-manager.

Heroku → StackBlaze equivalents

HerokuStackBlaze
web dynoWeb Service (Deployment + Ingress)
worker dynoBackground Worker (Deployment)
one-off dynoJob (Kubernetes Job)
Heroku PostgresStackBlaze PostgreSQL
Heroku RedisStackBlaze Redis
Heroku SchedulerCron Job
heroku config:setDashboard → Environment Variables
heroku ps:scale web=2Dashboard → Scale → 2 replicas
heroku releasesDashboard → Deployments

Under the hood

StackBlaze can build your app with Cloud Native Buildpacks (CNB), the same standard Heroku uses, so no Dockerfile is required, or from your own Dockerfile if you prefer. Either way, Procfile process types map directly to Kubernetes workload types:

  • web: becomes a Kubernetes Deployment with an Ingress and automatic TLS. Traffic is load-balanced across all replicas.
  • worker: becomes a Kubernetes Deployment without any Ingress. It runs on the private cluster network and processes jobs from a queue.
  • release: becomes a Kubernetes Job that runs to completion before new pods are created, the same guarantee Heroku release phase provides.