Moving from Heroku to Build
Still deciding? Build vs Heroku compares the two platforms and where each one fits. This page covers what changes technically when you move.
Build is Heroku-compatible at the buildpack, API and CLI level. Most conventional Heroku applications run on Build without code changes. This page covers the parts that are not identical.
What carries over
Section titled “What carries over”| Carries over | Notes | |
|---|---|---|
| Buildpacks | Yes | Heroku buildpacks are supported directly |
| Dockerfile builds | Yes | Supported as an alternative |
| Process types | Yes | web and worker processes, same Procfile |
| Config vars | Yes | Same concept, same name, importable |
| Pipelines | Yes | Build can also promote across regions |
| Review apps | Yes | Same concept |
| Postgres | Yes | Build-operated |
| Key-value store | Yes | Build-operated |
| Add-ons | Depends | The most widely used are covered. Check for a specific one before planning a move |
| Request timeout | Changes | Heroku fixes 30 seconds. Build’s is configurable per application |
| Dyno cycling | Changes | Heroku restarts every dyno roughly daily. Build does not restart on a schedule |
| Dyno classes | Changes | Build has no Standard tier. Every dyno is performance-class |
| Add-on operators | Changes | Build’s first-party add-ons run on Build hardware, not partner infrastructure |
Concepts and terminology
Section titled “Concepts and terminology”Most Heroku concepts map one to one.
| Heroku | Build | Notes |
|---|---|---|
| Dyno | Dyno | Same unit. Build dynos are all performance-class |
| Dyno type (Standard-1X, Performance-M) | Dyno size | Sizes map 1:1, billed in dyno-hours |
| Buildpack | Buildpack | Heroku buildpacks are supported directly |
| Config var | Config var | Same concept and same name |
| Pipeline | Pipeline | Build can promote across regions |
| Review app | Review app | Same concept |
| Add-on | Add-on | Build add-ons run on Build infrastructure |
| Private Space | Private Space | Same concept and same name. Additional charges may apply on Build with some setups |
heroku CLI | bld CLI | Near-identical command surface. See the CLI guide |
Compute and runtime
Section titled “Compute and runtime”Build runs every dyno as performance-class, so there is no Standard tier and no shared-tenancy step to graduate past. Dyno sizes map one to one with Heroku’s, billed in dyno-hours against a monthly pool. See Dyno Sizes.
Build also runs virtual machines alongside dynos, and provides direct kubectl access to your own Kubernetes namespaces. Heroku exposes neither: its runtime control plane is not addressable by customers.
Request timeout. Heroku’s router enforces a 30-second request limit that cannot be changed. On Build the response timeout is a per-application setting.
Runtime policies. Build exposes as per-application settings several things Heroku fixes. Under App Policies: response timeout, WebSocket support, shared process namespace, TLS passthrough, temporary certificate provisioning, the web application firewall and erosion resistance. Under App Settings: stack, buildpack selection and ordering, build cache and region. All of them are application-scoped. See Configuration.
Restarts. Heroku cycles every dyno roughly once every 24 hours. Build does not restart processes on a fixed schedule. Where you want one, Erosion Resistance sets a time limit after which a process is automatically restarted, for example as a guard against a memory leak.
Pipeline promotion. Build images are per application and per region, so a build can be promoted across regions. Heroku pipeline promotions are single-region. See CI/CD & Pipelines.
Build concurrency. Build does not impose a concurrent build limit. On Heroku the limit is account-level and depends on account standing: one concurrent build for unverified accounts, ten for verified accounts without an established payment history, and 300 for verified accounts with one. A migration that redeploys many applications at once is the point where that ceiling is felt.
Session recording. Shell and exec sessions are recorded and replayable from the application’s activity log. Heroku has no equivalent.
Data services
Section titled “Data services”Both platforms provide managed Postgres and a managed key-value store, and both support attaching them across applications. Build’s first-party add-ons are operated by one team on the same hardware as the compute: Schema To Go (PostgreSQL), Ave To Go (MariaDB), Sequel To Go (Microsoft SQL Server), Cache To Go (Redis), Donkey To Go (MongoDB) and Spandex To Go (Elasticsearch and OpenSearch), alongside Mailer To Go for transactional email and Infer To Go for AI model inference. They are billed through Build and draw from the plan’s add-on credits. Partner add-ons are provisioned through Build but provided and billed separately. See Add-on Services.
On Heroku, Postgres, Key-Value Store and Kafka are Heroku-operated, and the remainder come from third-party Elements partners.
Database control. Three things Heroku does not let you change are settings on Build. PostgreSQL parameters, including shared buffers, effective I/O concurrency and max parallel workers, are tunable per instance. Connection pooling is a mode you set rather than a buildpack you install. And you choose the weekly maintenance and base backup windows rather than being told them.
Point-in-time recovery exists on both platforms.
Cross-region relocation. A data store can be moved between regions self-serve, through a visible provision, sync, cutover and config-update sequence. Heroku has no self-serve region move for a running data add-on.
Add-on equivalence. Heroku’s marketplace is the largest in the category, with more than 200 add-ons. Build covers the most widely used of them on its own infrastructure. If an application depends on a specific add-on, check for an equivalent before planning a move.
Networking and regions
Section titled “Networking and regions”Build offers data residency in the US, the EU and Japan on every plan, with private networking standard and per-app multi-zone failover available. See Regions.
Heroku’s Common Runtime is US and EU. Other regions require Private Spaces, which is a paid tier. Heroku has no per-application zone failover.
Security and compliance
Section titled “Security and compliance”Both platforms hold SOC 2. Heroku holds SOC 1, 2 and 3 across both Common Runtime and Private Spaces regions, and its PCI DSS and HIPAA coverage is limited to Shield products.
Neither platform gates the SOC 2 report or role-based access control. Heroku made fine-grained access control available to all customers in August 2026, and its compliance reports are requested through support with no stated tier requirement.
What differs is packaging. On Build, SOC 2 certification, private networking, audit logs, role-based access control and Google Workspace single sign-on are included on every plan. On Heroku, audit logs and company-wide single sign-on are Enterprise account features.
Build additionally provides, with no Heroku equivalent at any tier:
- A per-application web application firewall using the OWASP Core Rule Set, toggleable per app
- An SPDX software bill of materials generated for every build
- Container image vulnerability scanning, with the report available per image
- Shell and exec sessions recorded and replayable from the application’s activity log
See Security.
Billing model
Section titled “Billing model”The unit changes. Heroku bills per dyno and per add-on, each priced monthly. Build bills a monthly pool of dyno-hours, drawn down by whatever is running, with add-on credits and unlimited seats included in the same figure.
A dyno-hour is one hour of a Standard-1X dyno. Larger sizes draw proportionally more: a Performance-M uses eight dyno-hours per hour. This is the number to plan capacity against.
For a worked cost comparison, see Build vs Heroku. For plan capacity, see Build pricing.
Migrating
Section titled “Migrating”Build can import applications, config vars and add-on configuration from a connected Heroku account, and both platforms can run in parallel while the application is validated. Engineer-led migration support is included for every Enterprise customer. See migrating to Build.
Do Heroku buildpacks work on Build?
Yes, directly. Build also supports Dockerfile builds.
Do dyno sizes map one to one?
Yes. A dyno billed at N units on Heroku consumes N dyno-hours per clock hour on Build. All Build dynos are performance-class.
Is there an equivalent to Private Spaces?
Build has Private Spaces under the same name. Private networking is standard on every plan, and non-US regions are available on every plan without a tier change. Additional charges may apply for Private Spaces with some setups.
Will my 30-second timeout workarounds still be needed?
Not for the timeout itself. The response timeout is a per-application setting on Build, so work split out purely to stay under Heroku’s fixed 30 seconds can be brought back inline if that suits the application better.
Do dynos still restart every day?
No. Build does not restart processes on a fixed schedule. If your application relies on the daily cycle to clear state or reclaim memory, configure a restart-after-N-seconds policy explicitly through Erosion Resistance.
Last reviewed: 7 September 2026