Where Heroku fits — and where teams hit the wall
Where Heroku fits well: small web applications that fit a web dyno, a Postgres, and a few add-ons, run by teams who value calm operations over infrastructure control.
Where teams outgrow Heroku: when the add-ons become the architecture — data, jobs, caching, and search each rented separately, each with its own dashboard, plan tiers, and invoice line that somebody has to reconcile.
The add-on economy, viewed from the invoice
Heroku’s core loop is still lovely: push code, get a running app. Everything the app grows into, though, is rented. The database is an add-on, background jobs are an add-on, search is an add-on — often operated by entirely different companies behind the marketplace curtain.
Each one made sense when it was attached. Together they mean the real system is a dyno formation plus a portfolio of external products, none of it declared in one place, and the monthly bill is a small archaeology project.
The same calm, with the pieces inside the project
A KERNSTACK project declares what a Heroku app rents: functions and container workers for the code, tables and buckets for data and files, a search index when the app needs one, and workflows for the jobs that used to be a scheduler add-on.
- No add-on marketplace: the resources are part of the project and its one credit balance
- An idle project spends no compute credits; Heroku-style always-on dynos are not the meter
- Agents draft changes in a sandbox and a person approves the plan — the review Heroku never had
Side-by-Side: Heroku vs KERNSTACK
| Dimension | Heroku | KERNSTACK (Software Lifecycle Cloud) |
|---|---|---|
| Deploy model | Git push to a dyno formation | A declared project: stack.json, plan, promote |
| Everything beyond code | Add-ons rented from a marketplace, each billed separately | Tables, buckets, search, and workflows inside the project |
| Background work | Worker dynos and scheduler add-ons | Container workers and workflows with human steps |
| Bill | Dynos plus every add-on’s own plan and invoice line | One credit balance; compute at 0.01 credits per GiB-second |
| Idle cost | Dynos bill for every hour they exist | No compute charge while idle; storage only |
| Operator | Salesforce’s platform on hyperscaler regions | Our own bare metal in Europe, one zone per project |
Frequently asked questions
Neither. Request-shaped code runs as functions; long-running processes run as container workers declared with a runtime such as nodejs, python, or php. The Procfile’s jobs become resources in stack.json, which is what makes them reviewable as one diff.
KERNSTACK tables — with the trade stated plainly: they are key-value tables, not SQL. If your app leans on relational queries, keep a Postgres somewhere and call it; if your access is keyed reads and writes, tables remove the add-on, its plan tiers, and its separate bill.
Heroku bills for capacity that exists; KERNSTACK bills for work that happens. Compute spends 0.01 credits per GiB-second, storage 0.04 credits per GB-hour, and an idle project spends nothing on compute — closer to how a rarely-used internal tool actually costs.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.