Limits
Last updated November 04, 2024
This article is an aggregation of the limits imposed on various components of the Heroku platform.
Limits exist for several reasons. Some exist because of the architecture of the Heroku platform (for example, Heroku stores only the most recent 1500 lines of an app’s log history). Others exist to ensure good platform citizenship (for example, you can’t make more than 4500 Platform API requests per hour).
Many of the limits listed below link to another Dev Center article that provides additional context regarding the limit.
Apps
App names
App names cannot exceed 30 characters.
Maximum number of apps
- An account can have no more than 100 apps.
- A Heroku Team can have no more than 100 apps.
- An Enterprise Team can have no more than 200 apps.
Maximum custom domains per app
A single app can have up to 1,000 custom domains assigned to it.
Logs
Log history
Heroku only stores the last 1500 lines of log history. If you’d like to persist more than 1500 lines, use a logging add-on or create your own syslog drain.
Drains
You can have up to 5 drains on any given app.
Line length
Lines generated by dynos that exceed 10000 bytes are split into 10000 byte chunks without extra trailing newlines. Each chunk is submitted as a separate log line.
Build, CI and Release Phase
Log output generated by builds, CI runs and release phase are limited to 300 MB. Any output reaching that limit will be truncated from its beginning in chunks of 150 MB.
Router
HTTP timeouts
HTTP requests have an initial 30 second window in which the web process must return response data (either the completed response or some amount of response data to indicate that the process is active). Processes that do not send response data within the initial 30-second window will see an H12 error in their logs.
After the initial response, each byte sent from the server restarts a rolling 55 second window. A similar 55 second window is restarted for every byte sent from the client.
If no data is received from the dyno within the 55 second window the connection is terminated and an H15 error is logged.
Similarly, if no data is received from the client within the 55 second window, the connection is terminated and an H28 error is logged.
HTTP response buffering
The router maintains a 1MB buffer for responses from the dyno per connection.
HTTP request buffering
When processing an incoming request, a router sets up an 8 KB receive buffer and begins reading the HTTP request line and request headers. Each of these can be at most 8 KB in length, but together can be more than 8 KB in total. Requests containing a request line or header line longer than 8KB will be dropped by the router without being dispatched.
Dynos
Dyno memory
Different dyno sizes offer different amounts of maximum RAM:
eco,basic, andstandard-1xhave 512 MBstandard-2xandprivate-shas 1 GBperformance-m,private-m,shield-mhas 2.5 GBperformance-l,private-l,shield-lhas 14 GBperformance-l-ram,private-l-ram,shield-l-ramhas 30 GBperformance-xl,private-xl,shield-xlhas 62 GBperformance-2xl,private-2xl,shield-2xlhas 126 GB
Dyno memory and restarts
The maximum amount of RAM available to your application depends on the dyno size you use. The dyno manager restarts your dyno and logs an R15 error if the memory usage of a:
eco,basicorstandard-1xdyno reaches 1 GB, two times its quota.standard-2xdyno reaches 2 GB, two times its quota.performance-mdyno reaches 5 GB, two times its quota.performance-ldyno reaches 28 GB, two times its quota.performance-l-ramdyno reaches 36 GB, 1.2 times its quota.performance-xldyno reaches 74 GB, 1.2 times its quota.performance-2xldyno reaches 151 GB, 1.2 times its quota.private-sorshield-sdyno reaches its quota of 1 GB.private-morshield-mdyno reaches its quota of 2.5 GB.private-lorshield-ldyno reaches its quota of 14 GB.private-l-ramorshield-l-ramdyno reaches its quota of 30 GB.private-xlorshield-xldyno reaches its quota of 62 GB.private-2xlorshield-2xldyno reaches its quota of 126 GB.
Attached one-off dyno timeout
Connections to one-off dynos will be closed after one hour of inactivity (in both input and output). When the connection is closed, the dyno will be sent SIGHUP. This idle timeout helps prevent unintended charges from leaving interactive console sessions open and unused.
Detached one-off dyno timeout
Detached one-off dynos are cycled every 24 hours. As a result, a one-off dyno will run for a maximum of 24 hours
Concurrent one-off dynos
The following limits exist per app:
- 1 Eco one-off dyno (Eco requires a subscription to the Eco dynos plan)
- Up to 50 concurrent one-off Basic dynos
- Up to 50 concurrent one-off Standard-1X dynos
- Up to 50 concurrent one-off Standard-2X dynos
- Up to 5 concurrent one-off Performance-M dynos
- Up to 5 concurrent one-off Performance-L dynos
- Up to 5 concurrent one-off Performance-L-RAM dynos
- Up to 5 concurrent one-off Performance-XL dynos
- Up to 5 concurrent one-off Performance-2XL dynos
- Up to 5 concurrent one-off Private-S dynos
- Up to 5 concurrent one-off Private-M dynos
- Up to 5 concurrent one-off Private-L dynos
- Up to 5 concurrent one-off Private-L-RAM dynos
- Up to 5 concurrent one-off Private-XL dynos
- Up to 5 concurrent one-off Private-2XL dynos
- Up to 5 concurrent one-off Shield-S dynos
- Up to 5 concurrent one-off Shield-M dynos
- Up to 5 concurrent one-off Shield-L dynos
- Up to 5 concurrent one-off Shield-L-RAM dynos
- Up to 5 concurrent one-off Shield-XL dynos
- Up to 5 concurrent one-off Shield-2XL dynos
Submit a request to raise this limit for your application.
Config vars
Config var data (the collection of all keys and values) is limited to 64 KB for each app.
Boot timeout
The web process in a dyno may not take more than 60 seconds to bind to its assigned $PORT.
If your application requires more time to boot, you may use the boot timeout tool to increase the limit. However, in general, slow boot times will make it harder to deploy your application and will make recovery from dyno failures slower, so this should be considered a temporary solution.
Exit timeout
When a dyno is killed or restarted, the processes within the dyno have 30 seconds in which to exit on receiving a SIGTERM. The process is sent SIGKILL to force an exit after this 30 seconds.
Dyno restart limits
These limits are documented in Automatic dyno restarts and Dyno crash restart policy.
Dyno scale
The eco and basic dyno types support a maximum of one running dyno per process type. Additionally, applications that use the eco dyno type are limited to a maximum of two concurrently running dynos.
By default, all applications are limited to 100 dynos. Additionally, a process type can’t be scaled to more than 10 dynos for performance, private, or shield dynos.
Submit a request to raise this limit for your application.
Processes / threads
The maximum number of processes/threads that can exist in a dyno at any one time depends on dyno size:
eco,basicandstandard-1xdynos support no more than 256standard-2xandprivate-sdynos support no more than 512performance-m,private-m,shield-mdynos support no more than 16384performance-l,private-l,shield-ldynos support no more than 32768performance-l-ram,private-l-ram,shield-l-ramdynos support no more than 24576performance-xl,private-xl,shield-xldynos support no more than 32768performance-2xl,private-2xl,shield-2xldynos support no more than 65536
These limits include all processes and threads, whether they are executing, sleeping or in any other state. Note that the dyno counts threads and processes towards this limit. For example, a standard-1x dyno with 255 threads and one process is at the limit, as is a dyno with 256 processes.
Build
Concurrent builds
Only verified accounts can run builds of multiple apps across an account concurrently.
Verified users without an established payment history can create up to 10 concurrent builds at one time. Verified users with an established payment history can create up to 300 concurrent builds at one time.
Ensure that you’re using Heroku Pipelines correctly for any nearly identical apps. Instead of building multiple versions of the same app to deploy, use a pipeline to build a slug once, then promote the slug to multiple apps in your pipeline.
Git repos
Users are limited to a rolling window of 75 requests to Heroku Git repos per hour, per app, per user.
The uncompressed size of a checkout of HEAD from the repo, combined with the size of restored submodules, cannot exceed 1 GB.
Slug size
Your slug size is displayed at the end of a successful compile. The maximum slug size (after compression) is 500 MB; most apps should be far below this limit. Once a slug size reaches 300 MB we will warn about larger slug sizes having the potential to cause longer boot times.
Slug compilation
Slug compilation is limited to 15 minutes.
Build Resources
Heroku Builds have a maximum memory limit of ~12GB. Builds exceeding the limit will receive an Out of Memory error and will need to adjust their app builds to fit within the memory limit.
Heroku Postgres
Dataclips row limits
Dataclips can return up to 100,000 rows.
Dataclips data limits
Dataclips can return up to 100mb of data.
Dataclips query limit timeout
Dataclips will cancel queries after 10 minutes.
Basic, Standard, Premium, and Enterprise tier limits
The limits associated with each Postgres plan tier are described in the Choosing the Right Heroku Postgres Plan article.
Credentials limit
The maximum number of credentials Heroku Postgres supports is 120.
We strongly recommend that you use as few credentials as possible for security and operational reasons. Be sure to track where you’re using the credentials.
API
Heroku API limits
Calls to the Heroku API are limited to a rate of at most 4500 calls per hour.
Network
Network Bandwidth
Network bandwidth is soft limited at 2TB per app per month.
Enterprise Teams
Membership Limits
Enterprise Team memberships are limited to:
- 25 members for non-enterprise accounts
- 500 members for enterprise accounts
Other
Maximum number of SSH keys
All accounts may have a maximum of 50 SSH keys associated with their accounts. If you need more than this you should look into using the Build API.