Heroku - Git Push Deploy for Web Apps

Look, Heroku is git push hosting. That's it. You push code, it runs. No SSH keys, no server configuration, no "did I install Node 18 or 20?" bullshit. It just works, which is both the best and worst thing about it.

I've been using Heroku since 2012, deployed probably 200+ apps to it. Here's the honest truth: it's fantastic for getting stuff online fast. Terrible if you care about money or have any special requirements.

The "Platform as a Service" Marketing vs Reality

PaaS means they handle the servers so you don't have to. This sounds amazing until you realize you're trading control for convenience, and convenience costs money. A lot of money.

Heroku supports Node.js, Ruby, Java, PHP, Python, Go, Scala, and Clojure, but honestly most people just use Node.js or Python. The buildpack system is pretty solid - it auto-detects your language from your package.json or requirements.txt and sets everything up.

Here's what actually happens when you deploy:

1. You run git push heroku main
2. Heroku builds your app (this can take 2-5 minutes, get coffee)
3. If the build succeeds, it starts serving traffic
4. If it fails, you debug the build logs and try again

The automatic scaling is real but costs extra. Load balancing works fine. SSL certificates are actually seamless - I'll give them that. Health monitoring is basic but catches most issues.

The AI Stuff (Because Everything Needs AI Now)

In 2025, Salesforce bolted AI onto Heroku because they needed something to talk about at Dreamforce. They launched Managed Inference and Agents which is basically OpenAI hosting that costs more than your mortgage payment with a dashboard that looks like it was designed by committee.

The AI features work fine if you need them and don't mind paying 2-3x what OpenAI charges directly. You get access to GPT-4, Claude, and other models without managing API keys. There's also pgvector support for RAG applications if you're building document search.

But here's the reality: unless you're building for a client who explicitly demanded "enterprise AI" (and has the budget to match), just call OpenAI's API directly. It's cheaper, less vendor lock-in, and you won't spend three hours debugging why your prompt works in the OpenAI playground but fails on Heroku.

The Performance Reality Check

Salesforce paid Forrester to write a study claiming Heroku delivers 286% ROI and 40% productivity gains. Take that with a mine-sized grain of salt - Forrester studies are basically expensive marketing brochures written by consultants who've never deployed a production app.

The real math: my AWS bills are consistently 60-70% lower than equivalent Heroku setups. Where Heroku wins is developer sanity - you'll spend 10+ fewer hours per month not debugging why your Load Balancer randomly decided to stop health checking your instances. Whether that's worth the premium depends on your hourly rate and how much you value your mental health.

What's actually true: Heroku dynos are lightweight containers that restart every 24 hours whether you want them to or not. They have a 30-second boot timeout, so if your app takes longer than that to start, it fails. I learned this the hard way with a Rails app that took 45 seconds to boot and would randomly fail deploys with zero useful error messages.

I once had a client's e-commerce site scale to 50 dynos during a Black Friday traffic spike, and the bill was $2,400 for three hours of traffic. The worst part? The auto-scaling didn't scale back down for another 6 hours because their algorithm assumes "sustained load" lasts longer than a flash sale.

The containers are "automatically managed" which means you have zero control over the underlying infrastructure. Sometimes this is great (no SSH access to break things), sometimes it's terrible (no SSH access to fix things).

Salesforce Integration (If You're Into That)

Since Salesforce owns Heroku, there's tight integration with their CRM platform. Heroku Connect syncs data between Heroku Postgres and Salesforce objects, which is actually pretty useful if you're already paying for Salesforce.

The integration works well, but it's expensive and vendor lock-in hell. You're basically married to the Salesforce ecosystem at that point. Great if you're already there, terrible if you're not.

Heroku's architecture is pretty straightforward once you understand the basic workflow. I spent way too many hours debugging deployments before figuring out what actually happens when you push code.

Cedar vs Fir: The Platform Generations Nobody Talks About

Heroku has two platforms: Cedar (the old reliable one) and Fir (the new shiny one). Most people use Cedar and don't even know Fir exists.

Cedar (what you're probably using):
Cedar uses slugs - basically tar.gz files of your compiled app that get distributed across Heroku's infrastructure. Here's exactly what happens when you git push heroku main:

1. Build Phase: Heroku downloads your code and runs buildpacks to compile it (detects language from package.json, requirements.txt, etc.)
2. Slug Creation: Everything gets packaged into a slug (max 500MB or your deploy fails hard)
3. Release: The slug + your config vars become a "release" with a unique version number
4. Dyno Execution: Your Procfile tells Heroku what commands to run (web: node server.js)

The slug size limit will bite you eventually, and when it does, you'll want to throw your laptop out the window. I had a Next.js app that generated 600MB of build artifacts and took me 3 hours to debug why deployments kept failing. The error message was about as helpful as a chocolate teapot: "Slug size too large" without telling you what the limit is, where the bloat is coming from, or how to fix it. Turns out the limit is 500MB and Next.js was caching every fucking image in .next/static.

Fir (the new hotness nobody uses yet):
Fir runs on Kubernetes and uses Docker images instead of slugs. It's basically Heroku trying to catch up with modern container practices. Unless you're paying for Private Spaces, you're probably not using this.

The main advantage is better Docker support and no slug size limits, but most apps work fine on Cedar so why complicate things?

Dynos: The Containers That Restart When You Don't Want Them To

Dynos are Heroku's containers. Think of them as mini Linux boxes that run your code. There are three types:

Web Dynos handle HTTP requests. They MUST bind to $PORT or Heroku assumes your app crashed. I learned this when my app listened on port 3000 instead of process.env.PORT and spent 2 hours wondering why deployments "succeeded" but returned 503 errors. The worst part? The dyno logs showed the app was running fine, listening on port 3000, but Heroku's load balancer was like "nope, not on the port I expected, fuck you."

Worker Dynos run background jobs. These are great for queue processing, but they cost the same as web dynos which is annoying if you just need to run a cron job once a day.

One-off Dynos are for running commands like heroku run rails db:migrate. They use the same dyno pricing as your regular dynos, so a 30-second database migration costs you an hour of compute time.

The Router: Load Balancing That Actually Works

Heroku's HTTP routing is pretty solid. It randomly distributes requests across your web dynos, which sounds dumb but works fine in practice.

Key things to know:

• 30-second timeout: If your app takes longer than 30 seconds to respond, Heroku kills the request. This is non-negotiable.
• SSL is automatic: Actually one of Heroku's best features. Custom domains get SSL certificates automatically.
• HTTP/2 support: Works fine, nothing special here
• Request headers: Heroku adds X-Forwarded-For and similar headers automatically

The 30-second timeout killed me on a PDF generation service that took 45 seconds for complex documents. Had to rewrite it to use background jobs.

Database Services: Postgres and Redis

Heroku Postgres (starts at $5/month):

• 1GB storage, which runs out faster than you think
• Automated backups that actually work (tested this in production)
• Connection pooling is built-in and saves your ass with high traffic
• Performance monitoring is decent

The $5 plan is fine for development. You'll need the $50+ plans for anything real, which is where the costs start adding up.

Heroku Redis (starts at $3/month):

• 25MB storage (good for sessions, nothing else)
• Sub-millisecond access times as advertised
• Persistence works but you pay extra for it
• Pub/sub messaging for real-time features

Apache Kafka on Heroku:
Expensive and overkill for most apps. Use Redis or just call your APIs directly unless you're actually doing event streaming.

Config Vars: Environment Variables Done Right

Config vars are Heroku's environment variables. This is actually well-designed and follows twelve-factor app principles properly.

heroku config:set DATABASE_URL="postgres://..."
heroku config:set API_KEY="your-secret-key"

Add-ons automatically create config vars, which is convenient. Database credentials rotate automatically without you having to update anything, which is nice.

The main gotcha: config var changes restart ALL your dynos simultaneously. No rolling restart, no graceful shutdown, just boom - 30 seconds of 503 errors while your app boots. I learned this when I updated a feature flag during peak traffic and took down a client's checkout flow for 45 seconds. The client was not amused, and neither was I when I realized Heroku doesn't give a shit about your uptime requirements.