🟪 Deploying to Heroku Platform

Why Heroku?

Heroku is a Platform as a Service (PaaS). You hand it your code; it handles the servers, the operating system, scaling, load balancing, and routing. There is no infrastructure to provision and no server to SSH into.

💡 The concierge analogy: AWS is like renting an apartment and furnishing it yourself — total control, total responsibility. Heroku is a serviced hotel: you bring your suitcase (your code), and the staff handle housekeeping, utilities, and the front desk. You trade some control for enormous convenience.

How Heroku Works

A handful of concepts explain almost everything Heroku does. Learn these names and the CLI commands stop feeling like magic incantations.

⚠️ The filesystem is ephemeral. Anything a dyno writes to its local disk vanishes when the dyno restarts (which happens at least daily). Never store uploads or state on the dyno — put files in S3 and state in Postgres or Redis. This is the single most common Heroku beginner trap.

Deploying Your App

Two rules every Heroku app must follow

1. Listen on process.env.PORT. Heroku assigns your dyno a port at runtime and routes traffic to it. Hard-coding port 3000 will fail.

const express = require('express');
const app = express();

// Heroku injects PORT; fall back to 3000 for local dev
const port = process.env.PORT || 3000;

app.get('/', (req, res) => {
  res.send('Hello from Heroku!');
});

app.listen(port, () => {
  console.log(`App listening on port ${port}`);
});

2. Declare your processes in a Procfile at the project root — a plain text file naming each process type and its command:

# Procfile
web: node server.js
worker: node worker.js

For Python you'd run through a production WSGI server:

# Procfile (Python)
web: gunicorn app:app

Method 1 — Git deployment (the classic path)

# Create the app (adds a 'heroku' git remote)
heroku create my-awesome-app

# Ship it
git push heroku main

# Open it in the browser
heroku open

Method 2 — GitHub integration (auto-deploy)

In the Heroku Dashboard, open your app's Deploy tab, choose GitHub, connect your repository, and enable Automatic Deploys from main. Every merge now deploys itself — no local push required.

Method 3 — Container registry (bring your own Docker)

If you'd rather ship the exact image you built and tested, push a Docker container instead of source:

heroku container:login
heroku container:push web -a my-app
heroku container:release web -a my-app

Node.js walkthrough

A minimal Node app needs a package.json with a start script and a pinned Node version:

{
  "name": "nodejs-example",
  "version": "1.0.0",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "dev": "nodemon server.js"
  },
  "dependencies": {
    "express": "^4.19.2"
  },
  "engines": {
    "node": "20.x"
  }
}

git init
git add .
git commit -m "Initial commit"

heroku create nodejs-example-app
git push heroku main
heroku ps:scale web=1     # ensure one web dyno is running
heroku open

Python (Flask) walkthrough

Flask needs requirements.txt, a Procfile, and a production server (gunicorn):

# app.py
from flask import Flask
import os

app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello from Flask on Heroku!'

if __name__ == '__main__':
    port = int(os.environ.get('PORT', 5000))
    app.run(host='0.0.0.0', port=port)

# requirements.txt
flask==3.0.3
gunicorn==22.0.0

heroku create flask-example-app
git push heroku main
heroku open

Add-ons: Databases & Config

Because the dyno filesystem is ephemeral, real apps store data in add-ons — managed services Heroku provisions and connects for you.

Attach a Postgres database and a Redis cache. (The old hobby-dev tier is retired; the current entry tiers are essential-0 for Postgres and mini for Redis.)

# Managed PostgreSQL — sets DATABASE_URL automatically
heroku addons:create heroku-postgresql:essential-0

# Managed Redis — sets REDIS_URL automatically
heroku addons:create heroku-redis:mini

# List and inspect
heroku addons
heroku config:get DATABASE_URL

Attaching Postgres sets the DATABASE_URL config var for you. Your code reads it from the environment — never hard-code credentials:

// db.js — connect using the injected DATABASE_URL
const { Sequelize } = require('sequelize');

const databaseUrl = process.env.DATABASE_URL || 'postgres://localhost:5432/local_db';

const sequelize = new Sequelize(databaseUrl, {
  dialect: 'postgres',
  dialectOptions: {
    ssl: { require: true, rejectUnauthorized: false }, // Heroku Postgres requires SSL
  },
});

async function testConnection() {
  try {
    await sequelize.authenticate();
    console.log('Database connection established.');
  } catch (error) {
    console.error('Unable to connect:', error);
  }
}

testConnection();
module.exports = sequelize;

Manage your own config vars (secrets, feature flags) directly:

heroku config:set NODE_ENV=production JWT_SECRET=super-secret-value
heroku config                    # list all config vars
heroku config:unset OLD_FLAG     # remove one

Run one-off tasks — like database migrations — on a temporary dyno:

heroku run npx sequelize-cli db:migrate
heroku run npx sequelize-cli db:seed:all

💡 This is the Twelve-Factor way. Storing config in the environment (not in code) is one of the Twelve-Factor App principles Heroku's own founders wrote. The same discipline makes your app portable to any other platform later.

Pipelines & Review Apps

A pipeline chains several apps into a continuous-delivery workflow: code flows through review → staging → production, and you promote a tested build forward instead of rebuilding it.

# Create a pipeline with a staging stage
heroku pipelines:create my-pipeline --stage staging -a my-staging-app

# Add the production app
heroku pipelines:add my-pipeline -a my-production-app --stage production

# Promote the exact staging slug to production (no rebuild)
heroku pipelines:promote -a my-staging-app

Review apps spin up a disposable, fully running copy of your app for every pull request, so reviewers click through the actual change before merging. Configure them with an app.json at the repo root:

{
  "name": "My Application",
  "description": "Full-stack demo app",
  "env": {
    "NODE_ENV": { "value": "review" }
  },
  "addons": ["heroku-postgresql:essential-0"],
  "buildpacks": [{ "url": "heroku/nodejs" }],
  "scripts": {
    "postdeploy": "npx sequelize-cli db:migrate"
  }
}

Everyday operations you'll reach for constantly:

# Stream live logs
heroku logs --tail

# Scale out (more dynos) or up (bigger dynos)
heroku ps:scale web=3 worker=2
heroku ps:resize web=standard-2x

# Roll back to the previous release if a deploy goes bad
heroku releases
heroku rollback

Limits & Alternatives

Heroku's simplicity comes with real constraints. Know them before you build so nothing surprises you in production.

• Ephemeral filesystem — disk writes are lost on restart
• 30-second request timeout — long operations must move to worker dynos or async jobs
• Router body limits — large uploads should go straight to object storage, not through a dyno
• Cost at scale — many dynos and premium add-ons add up quickly
• Regional coverage — fewer regions than AWS/GCP/Azure

If you outgrow Heroku, several platforms offer a similar developer experience:

Hands-on Exercise

// server.js
const express = require('express');
const path = require('path');
const app = express();
const PORT = process.env.PORT || 5000;

app.use(express.json());

app.get('/api/info', (req, res) => {
  res.json({ message: 'Hello from the backend!', env: process.env.NODE_ENV });
});

// In production, serve the compiled React app
if (process.env.NODE_ENV === 'production') {
  app.use(express.static(path.join(__dirname, 'client', 'build')));
  app.get('*', (req, res) => {
    res.sendFile(path.resolve(__dirname, 'client', 'build', 'index.html'));
  });
}

app.listen(PORT, () => console.log(`Server running on port ${PORT}`));

{
  "scripts": {
    "start": "node server.js",
    "heroku-postbuild": "cd client && npm install && npm run build"
  },
  "engines": { "node": "20.x" }
}

git init && git add . && git commit -m "Initial commit"

heroku create fullstack-demo-app
heroku config:set NODE_ENV=production
git push heroku main
heroku open
heroku logs --tail

Summary & Quiz

📚 Further Reading

• Heroku Dev Center
• The Twelve-Factor App
• Heroku Pipelines
• Dynos and the Dyno Manager

🚀 What's Next?

You've now deployed the easy way (Heroku) and the powerful way (AWS). Next we zoom in on running containers at scale: Container Orchestration Principles — the ideas behind Kubernetes and why they matter.