Heroku Basics Cheat Sheet
Covers Heroku's dyno model, Procfile configuration, add-ons, and core CLI commands for deploying and scaling applications.
Core Concepts
Heroku's application deployment model.
- Dyno- A lightweight container that runs your app's processes (web, worker, etc.)
- Procfile- Declares process types and the command to start each one
- Buildpack- Detects your app's language and prepares it to run (e.g. heroku/nodejs)
- Add-on- Managed third-party service (Postgres, Redis, logging) attached to your app
- Config Vars- Environment variables set per app, accessible at runtime
- Release Phase- An optional process type run before a new release goes live, e.g. migrations
Procfile Example
Defines a web process and a background worker.
web: node server.jsworker: node worker.jsrelease: node migrate.js
Heroku CLI Basics
Common commands for deploying and operating an app.
heroku login # authenticateheroku create my-app # create a new appgit push heroku main # deploy via githeroku ps:scale web=2 worker=1 # scale dynosheroku config:set API_KEY=abc123 # set a config varheroku logs --tail # stream logsheroku addons:create heroku-postgresql:mini # add a Postgres add-on
Pipelines & Review Apps
Promote builds through staging/production stages and spin up ephemeral apps per pull request.
heroku pipelines:create my-pipeline -a my-app-staging --stage stagingheroku pipelines:add my-pipeline -a my-app-production --stage production# Promote a tested staging build straight to production (same slug, no rebuild)heroku pipelines:promote -a my-app-staging# app.json enables Review Apps per PR when connected to GitHubcat app.json# {# "environments": {# "review": { "addons": ["heroku-postgresql:mini"] }# }# }
Releases, Rollback & One-Off Dynos
Inspect release history, roll back instantly, and run detached admin tasks.
heroku releases # list release history with slugsheroku releases:info v42 # inspect config/env diff for a releaseheroku rollback v41 # instantly revert to a prior releaseheroku run bash # one-off interactive dynoheroku run:detached python manage.py migrate # detached one-off jobheroku ps # list running dynos and their state
Multiple & Custom Buildpacks
Chain buildpacks or point at a third-party/custom one via URL.
heroku buildpacks:clearheroku buildpacks:add heroku/nodejsheroku buildpacks:add https://github.com/heroku/heroku-buildpack-multi-procfileheroku buildpacks:add --index 1 heroku-community/apt # insert at position 1heroku buildpacks # verify ordered chain# APT.txt lets the apt buildpack install system packages before the app buildsecho "ffmpeg" > Aptfile
Postgres Follower DBs & Backups
Create a read replica and manage point-in-time backups on Heroku Postgres.
heroku addons:create heroku-postgresql:standard-0 --follow DATABASE_URL -a my-appheroku pg:backups:capture -a my-appheroku pg:backups:download -a my-appheroku pg:backups:schedule DATABASE_URL --at '02:00 America/New_York' -a my-appheroku pg:info -a my-app # connections, PG version, cache-hit rateheroku pg:diagnose -a my-app # highlights index bloat, slow queries, etc.
Scaling & Runtime Internals
Concepts that matter once an app outgrows a single free-tier dyno.
- Dyno formation- the combination of dyno type (Basic/Standard/Performance) and process count/scale for an app
- R14 - Memory quota exceeded- error logged when a dyno exceeds its RAM limit; often a leak or an oversized in-process cache
- H12 - Request timeout- router kills any request running past 30s; long jobs belong on a worker dyno with a queue
- Preboot- `heroku features:enable preboot` starts new dynos before killing old ones, enabling zero-downtime deploys
- heroku labs:enable runtime-heroku-metrics- exposes dyno-level CPU/memory metrics via the Heroku Metrics API
- Session affinity- `heroku features:enable http-session-affinity` routes a client to the same dyno via cookie
- Config var change restart- setting any config var triggers a full restart of all dynos, so batch changes with `heroku config:set A=1 B=2`
Free and eco dynos sleep after 30 minutes of inactivity, adding cold-start latency to the next request — use a paid dyno type or an external uptime pinger for anything user-facing that needs consistent response times.