Table of Contents
Heroku handles many of the execution and orchestration concerns inherent in running your application. However, there are many auxiliary functions that need to be accounted for as well, including running one-off tasks and gaining visibility into your application.
These management and visibility principles are one of several categories of best-practices when developing for Heroku. Please review all the principles of architecting applications to gain a complete understanding of properly developing apps on Heroku.
Managing a production application often involves having to perform administrative and maintenance tasks such as running database migrations, arbitrary code in a REPL session, and one-time scripts.
These processes should be run in an identical environment, using the same code, config and dependency isolation, as the foreground processes. On Heroku, these one-off processes can be provisioned on Heroku via one-off dynos, which are identical in code and config to all your app’s other dynos.
Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format.
Logs are the stream of aggregated, time-stamped events collected from the output streams of all running processes and backing services. Logs in their raw form are typically a text format with one event per line (though backtraces from exceptions may span multiple lines). Logs have no fixed beginning or end, but flow continuously as long as the app is operating.
Heroku apps never concern themselves with the routing or storage of its output stream. They should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout.
During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior. In staging or production, each process’ stream is captured by the Heroku Logplex, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival.
Developers can view logs realtime in their console using the CLI, perform more advanced management and search tasks using one of the many logging add-ons or even send the logs to an external service using log drains.