TL;DR
Heroku's push-to-deploy loop still works: git push, buildpacks, dynos, Heroku Postgres, and a large add-on marketplace. If your agent builds the app and other people and agents will use it, floo keeps the loop and builds in the parts Heroku leaves to add-ons or your code: sign-in, agent keys, schedules, and storage.
- Sign-in: Heroku's docs offer no built-in sign-in for an app's users. floo's gateway admits the people you invite.
- Agents: Heroku's CLI, API, and MCP servers manage Heroku. floo also gives each agent a scoped key to the app itself.
- Schedules and previews: Heroku Scheduler runs every 10 minutes, hourly, or daily on a best-effort basis, and review apps need Pipelines, GitHub integration, and an
app.json. On floo, cron and previews are keys infloo.app.toml. - Where Heroku leads: a large add-on marketplace, Postgres tiers up to Shield, Private Spaces, and Salesforce integration through AppLink.
Facts about Heroku come from its Dev Center documentation and blog, read on October 29, 2026. Sources are listed at the end.
What does an agent-built app need that Heroku leaves to you?
Heroku's model is clean: you push to a git remote or connect GitHub, a buildpack builds the app, and dynos run it. A Procfile declares process types, and only web takes HTTP traffic. Heroku Postgres and a Redis-compatible key-value store are first-party. Most other needs come from add-ons, run by Heroku or by third parties.
That fits a developer who already knows which add-ons to pick. An app your agent builds for a team usually needs four things on day one: a sign-in that keeps it private, a database, a job that runs on a schedule, and a way for an agent to call it. On Heroku, three of those are add-ons or app code. On floo, all four are configuration.
How do they compare?
| Heroku | floo | |
|---|---|---|
| Deploy | git push heroku, or GitHub integration with auto-deploy | Each push to GitHub deploys to dev; a GitHub release deploys to prod |
| Build | Buildpacks; Fir uses Cloud Native Buildpacks only, and Cedar now supports them too | A Dockerfile per service |
| Private app sign-in | None in Heroku's docs; auth in your code or a third-party add-on such as wwwhisper | access_mode = "accounts"; invited people sign in through floo |
| Agent credential for the app | None documented; build your own | Key per named consumer, scoped to declared routes, rate-limited, with request history |
| Database | Heroku Postgres | Managed Postgres, DATABASE_URL injected |
| Cache | Redis-compatible key-value store | Managed Redis, cache-only |
| Files | Dyno filesystem is ephemeral; S3 or third-party add-ons such as Bucketeer | S3-compatible storage declared in config |
| Schedules | Scheduler add-on: every 10 minutes, hourly, or daily, best effort; or a clock process | [cron.<name>] with a cron expression, run in your container |
| Previews | Review apps, with Pipelines, GitHub integration, and app.json | Pull request previews with their own managed resources and Postgres branch, off until turned on |
| Rollback | New release with the old build and config vars; add-on data unchanged | Traffic back to an earlier deploy's image; config and data unchanged |
How does sign-in work?
Heroku's authentication docs are about signing in to Heroku. For your app's users, you write auth into the app, or add a third-party add-on such as wwwhisper, which authorizes access to web apps independent of language and framework.
On floo, one line does it:
[app]
name = "stock-tracker"
access_mode = "accounts"
floo apps invite teammate@acme.com --role member sends an invitation. Your code reads the signed-in person from X-Floo-User-Email, and removing someone ends their sessions immediately. See how to add sign-in without writing auth code.
How does an agent work with the app?
There are two jobs here. The first is operating the platform, and Heroku covers it well: a CLI, a Platform API, a local MCP server that wraps the CLI, and a remote MCP server at mcp.heroku.com with OAuth. floo covers the same job with a CLI whose output-producing commands all support --json and an HTTP API described by an OpenAPI spec. See agent setup.
The second job is calling the app itself, for example an agent that updates stock counts every morning. Heroku's docs do not describe a credential for that, so it is a key table and middleware you write. On floo:
floo apps consumers create stock-agent
floo apps keys create stock-agent --consumer stock-agent --scope inventory.write --rate-limit-rpm 60
The key works only on routes declared with that scope. floo strips it before your code sees the request and passes the consumer's identity instead.
What about schedules and previews?
Heroku Scheduler offers three intervals: every 10 minutes, every hour, or every day. Its docs say runs are expected but not guaranteed, that a job can occasionally be skipped or run twice, and recommend a custom clock process for critical production jobs.
floo cron jobs take a standard cron expression, run in UTC inside one of your service images, and sync on every deploy:
[cron.low-stock]
schedule = "0 9 * * *"
command = "python scripts/low_stock.py"
service = "web"
For previews, Heroku review apps work well once set up: they need Pipelines and GitHub integration enabled, plus an app.json in the repository, and can open and close with each pull request. floo previews are turned on with a setting in floo.app.toml. Each pull request gets its own URL and its own preview-owned managed resources, including a Postgres branch, and an agent can create one for a pushed branch from the CLI or API. See production-shaped preview environments.
Where is Heroku stronger?
- Postgres range and Private Spaces. Heroku Postgres runs from Essential through Advanced and classic tiers up to Shield, and Fir launched with Fir Private Spaces.
- Add-ons. The Elements Marketplace has an add-on for most needs.
- Salesforce. AppLink exposes Heroku apps as API services in Salesforce.
- Rollback includes config. A Heroku rollback restores the old config vars with the old build. floo's rollback reverts code and keeps the environment's current variables.
Is Heroku still being developed?
In February 2026, Heroku said it was moving to a sustaining engineering model focused on stability, security, and reliability rather than new features, and stopped offering Enterprise Account contracts to new customers. Its October 2026 update still shipped Postgres Advanced, Cloud Native Buildpacks on Cedar, Postgres 18 as the default, and team-owned API tokens.
Which should you choose?
Stay on Heroku when the app already runs there, depends on its add-ons or Salesforce, or needs Private Spaces. Choose floo when your agent builds the app and a known group of people and agents will use it: sign-in, data, schedules, storage, previews, and agent keys come from one file in the repository, so your agent can set up the whole thing.
For the wider field, see the best platforms to host internal tools built with AI and where to host an app built with Claude Code.
Sources
- Heroku: how Heroku works, GitHub integration, Procfile, generations, Heroku Postgres, key-value store, add-ons, S3, Bucketeer, Scheduler, pipelines, review apps, wwwhisper, releases, Platform API, CLI, MCP server, remote MCP server, AppLink, an update on Heroku, October 2026 update
- floo: app sign-in, app API keys, Postgres, Redis, storage, cron jobs, preview environments, rollbacks, Dockerfiles, agent setup
Frequently asked questions
Does Heroku have built-in sign-in for an app's users?
Not that its docs describe. Heroku's authentication docs cover signing in to Heroku itself. For a private app you write auth into the app or use a third-party add-on such as wwwhisper. On floo, access_mode = "accounts" puts hosted sign-in in front of the app.
How do scheduled jobs compare?
Heroku Scheduler runs a job every 10 minutes, hourly, or daily, and its docs say runs are expected but not guaranteed. For critical jobs Heroku recommends a custom clock process. On floo, a [cron.<name>] section in floo.app.toml takes a cron expression and runs the command in your app's container.
Is Heroku still adding features?
In February 2026 Heroku said it was moving to a sustaining engineering model focused on stability, security, and reliability. Its October 2026 update still shipped Postgres Advanced, Cloud Native Buildpacks on Cedar, and team-owned API tokens. Read both posts and judge for your workload.
Can my agent operate a Heroku app?
Yes. Heroku has a CLI, a Platform API, and local and remote MCP servers. What it does not give the agent is a credential for the app's own routes. floo gives each agent a key scoped to declared routes, with a request log.