An application is a collection of source code written in one of these languages, perhaps a framework, and some dependency description that instructs a build system as to which additional dependencies are needed in order to build and run the application.

Procfiles list process types – named commands that you may want executed.

Applications consist of your source code, a description of any dependencies, and a Procfile.

Buildpacks lie behind the slug compilation process. Buildpacks take your application, its dependencies, and the language runtime, and produce slugs. They’re open source – enabling you to extend Heroku to other languages and frameworks.

A slug is a bundle of your source, fetched dependencies, the language runtime, and compiled/generated output of the build system – ready for execution.

Dynos are isolated, virtualized Unix containers, that provide the environment required to run an application.

Config vars contain customizable configuration data that can be changed independently of your source code. The configuration is exposed to a running application via environment variables.

The combination of slug and configuration is called a release.

As Heroku contains a store of the previous releases of your application, it’s very easy to rollback and deploy a previous release

The dyno manager of the Heroku platform is responsible for managing dynos across all applications running on Heroku.

Add-ons are third party, specialized, value-added cloud services that can be easily attached to an application, extending its functionality.

Logplex automatically collates log entries from all the running dynos of your app, as well as other components such as the routers, providing a single source of activity.Web: Web dynos are dynos of the “web” process type that is defined in your Procfile. Only web dynos receive HTTP traffic from the routers.

Web: Web dynos are dynos of the “web” process type that is defined in your Procfile. Only web dynos receive HTTP traffic from the routers.

Worker: Worker dynos can be of any process type declared in your Procfile, other than “web”. Worker dynos are typically used for background jobs, queueing systems, and timed jobs. You can have multiple kinds of worker dynos in your application

One-off: One-off dynos are temporary dynos that can run detached, or with their input/output attached to your local terminal. They’re loaded with your latest release. They can be used to handle administrative tasks, such as database migrations and console sessions. 

Dynos use the Network Time Protocol (NTP) for time synchronization

Dynos in a Private Space are all connected via a virtual private network configured as part of the space.

Trusted IP Ranges can be used to control which client IPs are allowed to communicate with the applications in a Private Space.

free, hobby and standard-1x dynos support no more than 256 processes

standard-2x and private-s dynos support no more than 512 processes

performance-m and private-m dynos support no more than 16384 processes

performance-l and private-l dynos support no more than 32768 processes

A web dyno must bind to its assigned $PORT within 60 seconds of startup. If it doesn’t, it is terminated by the dyno manager and a R10 Boot Timeout error is logged

he dyno manager will restart your dyno and log an R15 error if the memory usage exceed it’s limit

Autoscaling is currently available only for Performance-tier dynos and dynos running in Private Spaces.

One-off dynos are named in the scheme run.N rather than the scheme <process-type>.N.

You can run a dyno in the background using heroku run:detached

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

The Dyno Runtime is a central component of Heroku that is responsible for running your app’s dynos. A Dyno Runtime is responsible for:

  • Provisioning dynos (secure, isolated containers for running your app’s code).
  • Managing and monitoring the lifecycle of each dyno.
  • Adding and removing dynos when the scaling configuration of the app changes.
  • Providing proper network configuration so dynos can make network requests to attached add-on services and other external endpoints.
  • Receiving web traffic on an application’s domain and routing it to web dynos.
  • Capturing log output from each dyno and forwarding it to the application’s log drains.

Heroku has two types of Dyno Runtimes: the Common Runtime, and the Private Spaces Runtime.

Dynos within a Private Space can communicate directly with each other over a private network.

You can share a single Heroku Postgres database between multiple apps with the heroku addons:attach command

The PostgreSQL project stops supporting a major version five years after its initial release. 

Dataclips are stored in the US.

You can view expensive queries for your database at data.heroku.com. Select a database from the list and navigate to its Diagnose tab

Dataclips cannot connect to Shield databases.

As long as a dataclip has been viewed or downloaded at least once in the past seven days, Heroku automatically executes its query and updates its results about once per hour whether or not the results are viewed or downloaded

A dataclip can return up to 100,000 rows.

  • You can’t share dataclip results with Heroku Teams that you don’t belong to.
  • Unauthenticated users retrieving results from the .csv or .json endpoints are limited to 30 requests per minute per IP.

Forking creates a new database containing a snapshot of an existing database at the current point in time.

Followers are only supported on Standard, Premium, and Private and Shield tier database plans. 

except for private and shield tier databases, Heroku Postgres databases are accessible from anywhere and can be used from any application using standard Postgres clients. For private databases, outside access can be enabled using Mutual TLS.

Heroku Redis is an in-memory key-value data store, run by Heroku, that is provisioned and managed as an add-on

A Kafka cluster is comprised of a number of brokers, or instances running Kafka.

Producers are clients which write to Kafka brokers, while consumers are clients which read from Kafka brokers.

In Shield Spaces, Zookeeper access is not allowed.

Currently, Apache Kafka on Heroku has a minimum retention time of 24 hours, and a maximum of 2 weeks for standard plans and 6 weeks for extended plans.

Security

Heroku offers three application runtimes to allow you to meet different data sensitivity requirements

  • Common Runtime: Secure multi-tenant environment for low to moderately sensitive data type that provides essential data security features
  • Heroku Private Spaces: Account isolated environment with defined network boundaries for moderate to high data types that provides additional data security and geographic isolation features
  • Heroku Shield Private Space: Account isolated environment with defined network boundaries for highly regulated data types such as PCI or HIPAA data that provides enhanced data security and geographic isolation features

Heroku Enterprise

Only team administrators can create, destroy, or modify Private Spaces

Trusted IP ranges for data services are not available in Shield Private Spaces.

The only users who can create apps in a Private Space are: Administrator and Team members that have been granted the “app creation” permission by an administrator

Internal Routing

Internal Routing is useful for

  • APIs and other secure microservice components that are consumed solely by your other Private Space apps and software running in a peered AWS VPC.
  • Apps that are accessible only to users on a VPN-connected, on-prem network. Requests to apps can originate only from hosts on the private network, and requests and responses can only transit the IPSEC connection.

Internal Routing can only be configured on app creation. It is not possible to enable Internal Routing for an existing app.

Automated Certificate Management is not compatible with Internal Routing

Private Space Logging is available only for Shield Private Spaces.

When Private Space Logging is enabled, log data will be sent directly from the source to the configured log destination. It will not be routed through Logplex. 

Enterprise Team

Enterprise Team users with “admin” and “member” permissions can create an app directly within the Enterprise Team

Users in an Enterprise Team can be admins, members, viewers, or collaborators.

Admin:

An admin user controls membership to the Enterprise Team, can view billing information, and can perform any action on any app owned by the team. Admin users can:

  • Access all apps in the Enterprise Team
  • Add, remove, and modify users in the Enterprise Team
  • View resource usage across the Enterprise Team
  • Manage invoices and billing for the Enterprise Team
  • Rename the Enterprise Team
  • Transfer, create, and delete apps in the Enterprise Team

Member:

Member users can only be added by Enterprise Team admins. Assigning a user the member role gives them read-only access to all apps within the Enterprise Team. They can be granted additional access on a per-app basis. Members can:

  • List all apps in the Enterprise Team
  • View admins & members in the Enterprise Team
  • View resources for the Enterprise Team
  • Transfer personal apps into the Enterprise Team
  • Create apps in the Enterprise Team

Viewer:

Viewer is a limited role that enables users to view apps and pipelines, spaces, users (Access tab), and resources.

Collaborator:

Collaborator users don’t belong to your Enterprise Team but are granted app-specific permissions. Collaborator users can’t:

  • List or access other apps that belong to the Enterprise Team
  • View the list of Enterprise Team users
  • Create or transfer apps to the Enterprise Team

Heroku Security, Privacy, and Compliance

Heroku has following compliance certifcate

  • PCI
  • HIPAA
  • GDPR
  • ISO 27001, 27017, 27018
  • SOC 1, 2, and 3 Attestation Reports

Twelve Factor App

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

The Twelve Factor

  • Codebase
  • Dependency
  • Config
  • Backing Services
  • Build, Release, Run
  • Processes
  • Port binding
  • Concurrency
  • Disposability
  • Dev/prod parity
  • Logs
  • Admin Processes