Heroku

What Heroku provides

Heroku is a platform for deploying and operating applications without managing the underlying servers directly. It builds application code into a deployable artifact and runs processes in dynos. A release combines that build with configuration, so changing a setting can be an operational change even without new source code.

For example, a small application can have a web process answering requests and a worker handling queued work. Those processes have different jobs and should be scaled according to their workload.

Dynos and persistent data

Heroku gives each dyno an ephemeral filesystem. Files written there are not shared automatically with other dynos and do not persist across restarts or new deployments. Databases, queues and external storage provide backing services for data that must outlive a process.

An upload that appears to work during a test can therefore disappear later if it is saved only to the web dyno. Test storage through a restart, not just through a second request to the same running process.

Postgres, Key-Value Store and Kafka

Heroku’s data services extend the platform beyond dynos. Heroku Postgres supplies a relational database, Heroku Key-Value Store supports cache and key-value workloads, and Apache Kafka on Heroku supports event streaming. These services store or move application data independently of a dyno’s disposable filesystem.

Add-ons and separate application processes

The add-on ecosystem connects applications to supporting services. An application can use separate process types for HTTP requests and background workers, allowing each workload to scale independently. A web process might accept an order while a worker handles a queued follow-up job; the persistent queue and database must remain available across process restarts.

Operating a Heroku application

Separate a deploy failure from a runtime failure. A build can succeed while the application fails to start because it lacks configuration or cannot reach a backing service. Logs, process status and release history answer different parts of that investigation.

When increasing capacity, examine the database and job queue too. More web processes can increase pressure on shared services. Plan configuration changes and database migrations so that old and new application processes can coexist during a rollout.