Deploying and Managing Application Lifecycle in Cloud Foundry with Manifests and Service Bindings

Explanation

Once org and space fundamentals are understood, the next practical skill is managing the full application lifecycle in Cloud Foundry: packaging, pushing, configuring, scaling, and connecting applications to backing services. This is where most day-to-day integration and extension work on SAP BTP actually happens. The central artifact for describing how an application should be deployed is the manifest.yml file. It declares the application name, the buildpack or Docker image to use, memory and disk allocations, the number of instances, the route (URL) the app should be reachable on, and any environment variables needed at startup. Rather than typing a long `cf push` command with many flags every time, teams check a manifest.yml into version control alongside the application code, so deployments are repeatable and reviewable. A well-structured manifest also documents dependencies implicitly, since the services an app expects to bind to are often referenced nearby in deployment scripts or pipeline configuration. Service instances are how CF applications consume backing capabilities such as a database, a connectivity service, a destination service, or an XSUAA (authorization and trust management) instance. You create a service instance from a marketplace entry (`cf create-service`), then bind it to your application (`cf bind-service`), or you can declare both the instance and the binding directly inside the manifest under a `services` list. When a binding is created, CF injects the service's credentials and configuration into a special environment variable called VCAP_SERVICES, structured as JSON, containing one entry per bound service with its credentials, plan, and label. Applications read this at startup, typically through a client library, to obtain URLs, client IDs, secrets, or certificates needed to call that backing service. Because VCAP_SERVICES is only populated at staging/start time, any change to a binding (adding, removing, or updating credentials) generally requires a restage or restart of the application, not just a reload, so that the new environment is materialized into the running container. Scaling in CF has two independent dimensions: the number of application instances (horizontal scaling, `cf scale -i`) and the memory/disk allotted to each instance (vertical scaling, `cf scale -m`). Horizontal scaling improves availability and throughput and is usually preferred for resilience, since CF's underlying scheduler (Diego) will redistribute instances across the underlying compute cells and automatically restart a failed instance elsewhere. Vertical scaling is used when a single instance cannot process a request within memory limits, but oversizing memory wastes quota and increases cost against your entitled capacity. Routes provide the externally reachable URL for an application and are separate objects from the application itself; a route can be mapped to zero, one, or multiple applications, which is the basis for zero-downtime deployment techniques where a new application version is pushed under a temporary name and then the route is remapped once healthy. Logging and troubleshooting rely heavily on `cf logs <app> --recent` for historical output and `cf logs <app>` for a live tail, though in a production landscape you typically forward these logs to a centralized log management service rather than relying on the CLI alone, since CF's own log retention is short-lived. Understanding this lifecycle deeply is what separates someone who can follow a tutorial from someone who can operate BTP Cloud Foundry applications under real project pressure, including diagnosing a crash loop, correctly re-binding a rotated service credential, or safely scaling an application before a peak load event.

Code example

# manifest.yml example for a Node.js integration adapter appapplications:- name: order-sync-adapter  memory: 512M  disk_quota: 512M  instances: 2  buildpack: nodejs_buildpack  routes:    - route: order-sync-adapter.cfapps.eu10.hana.ondemand.com  env:    NODE_ENV: production  services:    - order-sync-xsuaa    - order-sync-destination # Typical CLI lifecycle commandscf create-service xsuaa application order-sync-xsuaacf create-service destination lite order-sync-destinationcf push -f manifest.yml # Inspect injected service credentials at runtimecf env order-sync-adapter | grep -A 20 VCAP_SERVICES # Scale for higher availability before a peak load windowcf scale order-sync-adapter -i 4 # Restage after adding a new service binding so it takes effectcf bind-service order-sync-adapter order-sync-destinationcf restage order-sync-adapter

Real project scenario

A project team rotates the client secret on an XSUAA service instance as part of a security audit but only re-binds the service without restaging the dependent application. The application continues to fail authentication calls for hours because the old credentials were still cached in the running container's environment. The incident is resolved once the team restages the app, which forces CF to re-materialize VCAP_SERVICES with the new credentials, and the team subsequently adds a mandatory restage step to their credential rotation runbook.

Common mistakes

• Rebinding or recreating a service instance without restaging the application, leaving stale credentials active in the running container • Hardcoding service URLs or credentials instead of reading them from VCAP_SERVICES at runtime, breaking portability between environments • Scaling memory upward to fix a performance problem that is actually caused by inefficient code or a missing index, wasting entitled quota • Not checking manifest.yml into version control, leading to inconsistent or undocumented deployments across team members • Assuming `cf logs` retains history indefinitely, then losing critical crash diagnostics because no external log aggregation was configured

Best practices

• Keep manifest.yml files in version control alongside application code and treat them as part of the reviewed deployment artifact • Always restage or restart an application after any service binding change to ensure new credentials are active • Prefer horizontal scaling for resilience and only increase memory per instance when profiling shows genuine memory pressure • Forward application logs to a centralized log management service rather than relying solely on short-lived CF log buffers • Use distinct route names and a promotion strategy (blue-green or route remapping) to avoid downtime during redeployment

Interview angle

Interviewers commonly probe whether a candidate understands that VCAP_SERVICES is only refreshed on restage/restart, not on a simple bind alone, and whether they understand the difference between horizontal and vertical scaling and when each is appropriate. A strong candidate can also explain how manifest-driven deployment supports repeatability and safer promotion across dev/test/prod spaces.