This set builds vocabulary for Heroku's process-based PaaS deployment model.
0 / 5 completed
1 / 5
At standup, a dev mentions the lightweight, isolated container that runs a single instance of an application process on the platform. What is this unit called?
A dyno is Heroku's term for a lightweight, isolated container running a single instance of a defined process type, like a web server or background worker, and scaling an application means adjusting the number of dynos running that process type. This abstraction lets a developer think in terms of process types and their scale rather than individual physical servers. The concept generalizes the container-based execution model common across many PaaS platforms.
2 / 5
During a design review, the team defines the command used to start each process type, like web or worker, in a single declarative file. What is this file called?
A Procfile declares the exact command used to start each process type an application defines, such as web or worker, letting the platform know how to launch and scale each one independently. This declarative approach keeps the startup configuration version-controlled alongside the application code. It's a simple but foundational convention for platforms built around this process-type model.
3 / 5
In a code review, a dev adds a managed add-on providing a Postgres database, provisioned and connected automatically via environment variables. What does this represent?
A managed add-on provisions a service like a Postgres database and automatically injects connection details into the application's environment variables, removing the need to manually install and wire up the database server. This convenience reduces setup friction for common backing services. It reflects a broader pattern of marketplace-style add-ons common across PaaS platforms.
4 / 5
An incident report shows a stateful file upload feature broke after a dyno restarted and lost its locally written files. What architectural mistake does this reveal?
A dyno's local filesystem is ephemeral and can be wiped on restart or redeploy, so relying on it for persistent file storage, rather than an external object storage service, is a common architectural mistake on this style of platform. Understanding this ephemerality upfront avoids designing a feature around an assumption the platform doesn't actually support. This caution generalizes to any platform with stateless, ephemeral compute units.
5 / 5
During a PR review, a teammate asks why the team defines process types in a Procfile instead of hardcoding a single fixed startup command. What is the reasoning?
A single hardcoded startup command can't express that an application has distinct process types, like a web server and a background worker, that need to be scaled independently, while a Procfile declares each explicitly so the platform can manage them separately. This separation mirrors real differences in how each process type handles load. It keeps the deployment configuration expressive without requiring separate applications for each process type.