Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku Architecture
    • Dynos (app containers)
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Command Line
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery
    • Continuous Integration
  • Language Support
    • Node.js
    • Ruby
      • Working with Bundler
      • Rails Support
    • Python
      • Working with Django
      • Background Jobs in Python
    • Java
      • Working with Maven
      • Java Database Operations
      • Working with Spring Boot
      • Java Advanced Topics
    • PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
    • Heroku Data For Redis
    • Apache Kafka on Heroku
    • Other Data Stores
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
    • Compliance
  • Heroku Enterprise
    • Private Spaces
      • Infrastructure Networking
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
    • Single Sign-on (SSO)
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Integrating with Salesforce
  • Heroku Architecture
  • Platform Policies
  • Limits

Limits

English — 日本語に切り替える

Last updated November 28, 2022

Table of Contents

  • Apps
  • Logs
  • Router
  • Dynos
  • Build
  • Heroku Postgres
  • API
  • Network
  • Enterprise Teams
  • Other

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.

Maximum custom domains per app

A single app can have up to 1,000 custom domains assigned to it.

Source

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.

Source

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.

Source

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.

Source

HTTP response buffering

The router maintains a 1MB buffer for responses from the dyno per connection.

Source

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.

Source

Dynos

Dyno memory

Different dyno sizes offer different amounts of maximum RAM:

  • eco, basic, and standard-1x have 512 MB
  • standard-2x has 1024 MB
  • performance-m has 2.5 GB
  • performance-l has 14 GB

Source

Dyno memory and restarts

If the memory size of your dyno keeps growing until it reaches two times its quota (for a standard-1x dyno, 512 MB x 2 = 1 GB), the dyno manager will restart your dyno with an R15 error.

Source

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.

Source

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

Source

Concurrent one-off dynos

The following limits exist per app:

  • 1 eco one-off dyno
  • 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

Contact sales to raise this limit for your application.

Source

Config vars

Config var data (the collection of all keys and values) is limited to 32kb for each app.

Source

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.

Source

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.

Source

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 dynos.

Contact sales to raise this limit for your application.

Source

Processes / threads

The maximum number of processes/threads that can exist in a dyno at any one time depends on dyno type:

  • eco, basic and standard-1x dynos support no more than 256
  • standard-2x and private-s dynos support no more than 512
  • performance-m and private-m dynos support no more than 16384
  • performance-l and private-l dynos support no more than 32768

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.

Source

Build

Concurrent builds

Heroku only allows verified accounts to 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 that also have an established payment history can create up to 300 concurrent builds at one time.

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.

Source

Slug size

Your slug size is displayed at the end of a successful compile. The maximum slug size 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.

Source

Slug compilation

Slug compilation is limited to 15 minutes.

Source

Heroku Postgres

Dataclips row limits

Dataclips can return up to 100,000 rows.

Source

Dataclips data limits

Dataclips can return up to 100mb of data.

Source

Dataclips query limit timeout

Dataclips will cancel queries after 10 minutes.

Source

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.

API

Heroku API limits

Calls to the Heroku API are limited to a rate of at most 4500 calls per hour.

Source

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.

Keep reading

  • Platform Policies

Feedback

Log in to submit feedback.

Stack Update Policy Load Testing Guidelines

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences