Cloud Foundry and PCF: staging, droplets, routing and release recovery
Explain the Cloud Foundry application lifecycle from package and buildpack to droplet, Diego execution and routing. Compare restart, restage and rolling deployment recovery with explicit state boundaries.
TL;DR: A Cloud Foundry release moves source or a package through staging into a runnable droplet, then schedules application processes and connects healthy instances to routes. Keep build inputs, runtime configuration and external service state separate when diagnosing failure or planning recovery.
Establish which foundation you are discussing
An interview question may use PCF as shorthand for a Cloud Foundry installation. Ask for the distribution, foundation version and application runtime. Product names do not establish which CLI features, buildpacks or health-check mechanisms are available. This page describes the Cloud Foundry application lifecycle; it does not imply that every product carrying a related brand has identical operations.
The Cloud Controller manages application records and lifecycle requests. Buildpacks prepare supported application packages during staging. The resulting droplet contains the runnable application output, while Diego manages execution of application processes. The Cloud Foundry overview describes the platform roles. A successful upload is only an early checkpoint.
Preserve the staged release identity
Staging can resolve dependencies and select runtime components. Identical source pushed on two different days can therefore produce different runnable output if a buildpack or dependency source changes. Record the package, buildpack, stack and resulting droplet identity in the release evidence. Pin supported inputs where the platform permits it and retain the previous compatible output.
A service binding supplies application access to a backing service. That service's data usually has a lifecycle outside the application's containers. Replacing an application instance does not roll its database back, and local container files are a poor place to put durable business state.
| Operation | Principal effect | Remaining boundary |
|---|---|---|
| Restart | Starts application processes again using the selected runnable output | Does not rebuild dependencies |
| Restage | Produces a new droplet from the uploaded package and current staging inputs | May change runtime output without changing source |
| Rolling deployment | Replaces instances progressively | Old and new versions overlap |
| Cancel deployment | Attempts to return to the earlier application deployment | Environment changes and bindings are not automatically undone |
The restart and restage guide explains when staging-dependent environment changes require restaging. A restart cannot repair a missing library that must be packaged during staging.
Follow a release through observable boundaries
The repeated section repairs build inputs after a staging failure. Runtime observation can reveal a compatibility failure that requires a corrected candidate, even if staging completed successfully.
Work through a staging failure and a routing failure
Consider a fictional payments API. Its upload succeeds, but staging cannot fetch a private dependency because the build environment lacks access. The running production instances may still be healthy. Changing their health-check endpoint does nothing for the staging job. Inspect staging logs, the selected buildpack and the credentials or network route available to that stage.
Now consider a different candidate that stages and starts, but users cannot reach it. Check the target organization and space, mapped route, process type and instance readiness. A worker process that consumes messages may be healthy without an HTTP route; a web process needs the expected listening port and request path. Avoid solving both cases with an indiscriminate restart.
These read-only commands provide a starting record in an already authorized foundation. Use the real application name instead of orders-api:
cf target
cf app orders-api
cf events orders-api
cf logs orders-api --recent
Logs can include application data, so select relevant lines before sharing them. Establish the failed phase and its timestamps, then correlate the release operation with staging and runtime observations.
Readiness and liveness have different consequences
Cloud Foundry's health-check documentation distinguishes liveness failure, which can restart an instance, from readiness failure, which removes it from the route pool. Readiness support has foundation component-version requirements; verify them before prescribing a manifest field to an older installation.
A process check proves that a process exists. A port check proves a listener responds at that level. An HTTP check can exercise an application endpoint, but its usefulness depends on what that endpoint tests. A health endpoint that fails whenever an optional reporting service is unavailable can remove otherwise useful checkout capacity.
Recovery has to cover the overlapping versions
During a rolling update, both versions may receive requests. Preserve database compatibility and avoid assuming session memory moves with the client. Choose rollout bounds from available capacity and acceptable overlap, then observe completion rather than treating the first healthy instance as the entire rollout.
The deployment guide states that canceling a deployment does not revert environment variables or service bindings and does not guarantee zero downtime. Reverting a droplet after rotating a required credential can leave the old application unable to connect.
Self-check: the deployment is canceled, the earlier droplet runs again, and database access still fails. Which state could remain changed? Inspect the binding, runtime environment and database-side credential or schema change. Recover the compatible combination; the earlier droplet alone is incomplete evidence of recovery.