### Multi-app manifest.yml example

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

This example demonstrates a `manifest.yml` file for deploying multiple applications. Each application entry includes its name, path, resources, and specific configurations like `no-route` or `health-check-type`.

```yaml
---
applications:
- name: web-app
  path: ./web
  memory: 512M
  instances: 2
- name: worker-app
  path: ./worker
  memory: 256M
  instances: 1
  no-route: true
  health-check-type: process
```

--------------------------------

### Default manifest.yml example

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

This is an example of a basic `manifest.yml` file for a single application. It defines application name, resources, buildpacks, routes, environment variables, and services.

```yaml
---
version: 1
applications:
- name: my-app
  memory: 512M
  instances: 2
  buildpacks:
    - ruby_buildpack
  routes:
    - route: my-app.example.com
  env:
    RAILS_ENV: production
  services:
    - postgres-db
    - redis-cache
  health-check-type: http
  health-check-http-endpoint: /health
  timeout: 60
```

--------------------------------

### Custom Application Start Command

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Defines a custom command to start the application. For Docker apps, `sh -c` is used; for Buildpack apps, `bash -c` is used. Use `exec` for the final command in composite commands to handle signals properly.

```yaml
command: bundle exec rake VERBOSE=true
```

```yaml
command: bin/rake db:migrate && exec bin/rails server -p $PORT
```

--------------------------------

### Canary Deployment Setup

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Initiate a canary deployment by pushing the new version to a separate application with a small number of instances. This allows a small percentage of traffic to be routed to the new version for monitoring before a full transition.

```bash
# Deploy new version to separate app
cf push my-app-canary -n my-app-canary --instances 1

# Keep old version primary
# my-app: 5 instances (95% traffic)
# my-app-canary: 1 instance (5% traffic via manual routing)

# Monitor canary metrics
# If good, gradually shift traffic by creating routes
cf map-route my-app-canary example.com --hostname my-app

# Eventually transition fully
cf delete my-app (old version)
cf rename my-app-canary my-app
```

--------------------------------

### VCAP_SERVICES JSON Structure Example

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

An example of the JSON structure for the VCAP_SERVICES environment variable, showing credentials for PostgreSQL and Redis services.

```json
{
  "postgres": [
    {
      "binding_name": "my-database",
      "instance_name": "my-db",
      "label": "postgres",
      "name": "my-db",
      "plan": "standard",
      "provider": null,
      "syslog_drain_url": null,
      "tags": ["database", "sql"],
      "volume_mounts": [],
      "credentials": {
        "host": "db.example.com",
        "port": 5432,
        "username": "user123",
        "password": "secret456",
        "database": "my_database",
        "uri": "postgres://user123:secret456@db.example.com:5432/my_database"
      }
    }
  ],
  "redis": [
    {
      "binding_name": "cache",
      "instance_name": "my-cache",
      "label": "redis",
      "name": "my-cache",
      "plan": "free",
      "credentials": {
        "host": "cache.example.com",
        "port": 6379,
        "password": "cachepass",
        "uri": "redis://:cachepass@cache.example.com:6379"
      }
    }
  ]
}
```

--------------------------------

### Blue-Green Deployment Setup

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Set up a blue-green deployment by pushing the current version ('blue') and the new version ('green') as separate applications with distinct hostnames. This allows for testing the new version before an atomic route switch.

```bash
# Deploy current version as "blue"
cf push my-app-blue -n my-app

# Deploy new version as "green"  
cf push my-app-green -n my-app-green

# Test green version
curl my-app-green.example.com

# Map route to green (removes from blue)
cf map-route my-app-green example.com --hostname my-app
cf unmap-route my-app-blue example.com --hostname my-app

# Remove old version when satisfied
cf delete my-app-blue
```

--------------------------------

### Set Labels and Annotations via API

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

This example demonstrates how to set metadata, including labels and annotations, for a service instance using the Cloud Foundry V3 API.

```bash
cf curl /v3/service_instances/GUID \
  -X PATCH \
  -d '{
    "metadata": {
      "labels": {
        "env": "production",
        "team": "backend"
      },
      "annotations": {
        "owner": "team@example.com"
      }
    }
  }'
```

--------------------------------

### Access Environment Variables in Go

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Provides an example of accessing environment variables such as PORT and DATABASE_URL, and unmarshalling JSON-formatted VCAP_APPLICATION in Go. Requires the encoding/json package.

```go
import (
    "os"
    "encoding/json"
)

port := os.Getenv("PORT")
dbUrl := os.Getenv("DATABASE_URL")

// Parse JSON
var appMetadata map[string]interface{}/
json.Unmarshal([]byte(os.Getenv("VCAP_APPLICATION")), &appMetadata)
```

--------------------------------

### Instance Index Assignment Example

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/app-lifecycle-reference.md

Illustrates how Cloud Foundry assigns unique indices to multiple instances of the same application.

```text
App "my-app" with instances: 3
├─ Instance 0 (CF_INSTANCE_INDEX=0)
├─ Instance 1 (CF_INSTANCE_INDEX=1)
└─ Instance 2 (CF_INSTANCE_INDEX=2)
```

--------------------------------

### Start stopped application

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

This command starts a Cloud Foundry application that is currently in a stopped state. Replace `APP-NAME` with the actual name of your application.

```bash
cf start APP-NAME
```

```bash
cf start my-app
```

--------------------------------

### Service Binding with Custom Parameters

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/INDEX.md

Bind a service with custom parameters. This example shows binding a database instance with specific storage and backup configurations. Ensure the service supports these parameters.

```yaml
services:
  - name: database-instance
    parameters:
      storage_gb: 100
      backup_enabled: true
```

--------------------------------

### Restart application

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

This command stops and then immediately starts an application. It's useful for applying configuration changes or clearing in-memory state. Replace `APP-NAME` with your application's name.

```bash
cf restart APP-NAME
```

```bash
cf restart my-app
```

--------------------------------

### Implement Sticky Sessions with Express.js and Redis

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Example using Express.js and Redis to manage session data and set a session ID header for sticky sessions.

```javascript
// Express.js example
app.use(session({
  store: new RedisStore({url: process.env.REDIS_URL}),
  genid: () => crypto.randomUUID()
}))

app.use((req, res, next) => {
  res.set('X-Session-ID', req.sessionID)
  next()
})
```

--------------------------------

### Diagnose App Crashes Immediately

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/health-checks-reference.md

Use `cf logs` to view recent application logs and `cf app` to check the application's status when it crashes immediately after starting. This helps identify startup errors or timeout issues.

```bash
cf logs APP-NAME --recent
```

```bash
cf app APP-NAME
```

--------------------------------

### cf push without starting the application

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Push an application without starting its instances immediately. This allows for pre-deployment checks or configurations before the application becomes active.

```bash
cf push my-app --no-start
```

--------------------------------

### Configure App Startup Timeout via Manifest

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/health-checks-reference.md

Set the maximum time allowed for an app to become healthy after starting using the 'timeout' attribute in your manifest.yml.

```yaml
timeout: 120
```

--------------------------------

### Create Network Policies for Allowed Flows

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Use `cf add-network-policy` to define allowed communication paths between applications. This example shows a one-directional policy.

```bash
# 1. Define internal routes
cf map-route web apps.internal --hostname web
cf map-route backend apps.internal --hostname backend

# 2. Create network policies for allowed flows
cf add-network-policy web --destination-app backend

# 3. Apps can now communicate
# web.apps.internal → backend.apps.internal (allowed)
# backend.apps.internal → web.apps.internal (NOT allowed, one-directional)
```

--------------------------------

### HTTP Health Check Endpoint Examples

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/health-checks-reference.md

Illustrates the difference between a dedicated health check endpoint and one that includes business logic. Use a dedicated endpoint for faster, side-effect-free checks.

```bash
# Good: dedicated endpoint
GET /health -> 200 OK (fast, no side effects)

# Bad: health check affects business logic
GET /api/users -> 200 OK (slow if database down)
```

--------------------------------

### List service instances in the current space

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use `cf services` to get a summary of all service instances in the current space, including their names, associated services, plans, bound applications, and last operation status.

```bash
cf services
```

--------------------------------

### Check Application Status After Binding

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

After binding a service to an application, check the application's status using `cf app` to ensure it has started correctly. A restart might be necessary for the binding to take effect.

```bash
cf app my-app
```

--------------------------------

### Update Application Code with `cf push`

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

To update an application's code, modify the source files and then run `cf push`. This process creates a new droplet, starts new instances, and stops the old ones.

```bash
# Edit source code
vim app.js

# Deploy
cf push my-app
```

--------------------------------

### Create User-Provided Service Instance

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use this command to create a user-provided service instance. You can provide credentials interactively, as an inline JSON string, or specify a syslog drain URL.

```bash
cf create-user-provided-service INSTANCE-NAME [-p CREDENTIALS] [-l SYSLOG-DRAIN-URL] [-r ROUTE-SERVICE-URL]
```

```bash
# Interactive prompt for credentials
cf create-user-provided-service my-external-api
```

```bash
# Inline JSON credentials
cf create-user-provided-service my-api \
  -p '{"api_key": "secret123", "api_url": "https://api.example.com"}'
```

```bash
# Syslog drain
cf create-user-provided-service log-drain \
  -l syslog://logs.example.com:514
```

--------------------------------

### Initial Application Deployment

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Deploy an application with a specified configuration, including name, instance count, memory, and routes. This is the first step in a rolling deployment.

```yaml
---
applications:
- name: my-app
  instances: 3
  memory: 512M
  routes:
    - route: my-app.example.com
```

--------------------------------

### Configure App Startup Timeout via CLI

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/health-checks-reference.md

Use the '--app-start-timeout' flag with the 'cf push' command to configure the app startup timeout.

```bash
cf push APP-NAME --app-start-timeout 120
```

--------------------------------

### List available services in the marketplace

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use `cf marketplace` to view all available services, their plans, descriptions, and the brokers that provide them.

```bash
cf marketplace
```

--------------------------------

### Specify Application Name

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Sets the name for the application. The name must be unique within the space and cannot start with a dash.

```yaml
---
applications:
- name: my-web-app
```

--------------------------------

### Deploy entire manifest

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

This command deploys all applications defined in the `manifest.yml` file located in the current directory. Ensure the manifest file is present and correctly configured.

```bash
cf push
```

--------------------------------

### Push app with custom manifest

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Use this command to deploy an application using a manifest file located at a custom path. Ensure the path to the manifest is correct.

```bash
cf push -f path/to/custom-manifest.yml
```

--------------------------------

### Create a new service instance

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use `cf create-service` to provision a new service instance. You must specify the service name, plan, and a unique instance name. Optional parameters allow for custom configuration and tags.

```bash
cf create-service postgres standard my-db

cf create-service postgres standard my-db \
  -c '{
    "storage_gb": 100,
    "backup_enabled": true
  }'

cf create-service postgres standard my-db -t "production,database"
```

--------------------------------

### List Available Domains

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Use this command to list all available domains for creating routes.

```bash
cf domains
```

--------------------------------

### Set Application Timeout

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Configure the `timeout` attribute to specify the maximum seconds allowed between an application start and its first healthy response. This is related to the health check type.

```yaml
timeout: 80
```

--------------------------------

### Log Application Instance Identity

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Logs application information, including instance GUID, index, and IP address, to help correlate logs with specific application instances.

```bash
logger.info("Starting", {
  instance_id: ENV['CF_INSTANCE_GUID'],
  instance_index: ENV['CF_INSTANCE_INDEX'],
  instance_ip: ENV['CF_INSTANCE_IP']
})
```

--------------------------------

### List All Routes

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Display a list of all routes in the current space, including their space, host, domain, type, and associated apps.

```bash
cf routes
```

--------------------------------

### Python Environment Variable Service Discovery

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Access service connection details from environment variables in Python. This example demonstrates connecting to a Redis cache using host and port defined in the environment.

```python
import redis
cache = redis.Redis(
  host=os.environ['CACHE_HOST'],
  port=int(os.environ['CACHE_PORT'])
)
```

--------------------------------

### cf push with Docker image

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Deploy an application directly from a Docker image. Provide the image URI and optionally Docker registry credentials.

```bash
cf push my-app --docker-image myregistry/myimage:v1.0
```

--------------------------------

### Basic cf push command

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Use this command to deploy or update an application with default settings. The application name is required.

```bash
cf push my-app
```

--------------------------------

### Increase Health Check Timeout

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/health-checks-reference.md

If your application takes a long time to start, increase the health check invocation timeout using `cf set-health-check`. Ensure the application listens on the `$PORT` environment variable.

```bash
cf set-health-check APP-NAME port --invocation-timeout 5
```

--------------------------------

### Create a Cloud Foundry Service Key

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use this command to generate credentials for manual access to a service instance. You can optionally provide key-specific parameters in JSON format.

```bash
cf create-service-key INSTANCE-NAME KEY-NAME
```

```bash
cf create-service-key my-db backup-credentials
```

```bash
cf create-service-key my-db admin-key -c '{"role": "admin"}'
```

--------------------------------

### Create Administrative Service Key for Backup

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Create a service key with administrative privileges to facilitate backups. This key's credentials can then be used with external backup utilities.

```bash
cf create-service-key my-db backup-admin \
  -c '{"role": "admin"}'
```

```bash
cf service-key my-db backup-admin
```

--------------------------------

### Create HTTP Route with Path

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Create an HTTP route with a specific hostname and a context path. Ensure apps serve requests on the context path as routing does not strip it.

```bash
cf create-route example.com --hostname store --path products
```

```bash
cf create-route example.com --hostname store --path orders
```

```bash
cf create-route example.com --hostname store
```

--------------------------------

### Create Manual Service Key

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Manually create a service key using `cf service-key` to validate credentials and access the service directly. This is useful for troubleshooting access issues.

```bash
cf service-key INSTANCE-NAME my-key
```

--------------------------------

### Python App-Level Load Balancing

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Perform load balancing at the application level by retrieving and distributing requests across multiple service instance IP addresses. This uses Python's socket module to get address information.

```python
import socket
addresses = socket.getaddrinfo('backend.apps.internal', 8080)
# Distribute requests across addresses
```

--------------------------------

### Add Service Binding

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Bind a service to an application using `cf bind-service` and then restart the application to apply the changes.

```bash
cf bind-service my-app new-database
cf restart my-app
```

--------------------------------

### Configure Application Lifecycle

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Define the application lifecycle, which dictates the staging and running approach. Valid values are 'buildpack', 'cnb', and 'docker'.

```yaml
lifecycle: buildpack
```

--------------------------------

### List Network Policies

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Display all configured network policies for your applications. This command shows the source, destination, protocol, and ports for each policy.

```bash
cf network-policies
```

```bash
Source    Destination  Type  Ports
web-app   backend      tcp   8080
web-app   cache        tcp   6379
frontend  logging      udp   5140
```

--------------------------------

### Access Environment Variables in Node.js

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Demonstrates how to access standard environment variables like PORT and DATABASE_URL, and parse JSON-formatted variables such as VCAP_APPLICATION and VCAP_SERVICES in Node.js.

```javascript
const port = process.env.PORT;
const dbUrl = process.env.DATABASE_URL;

// Parse JSON env vars
const vcapApp = JSON.parse(process.env.VCAP_APPLICATION || '{}');
const vcapServices = JSON.parse(process.env.VCAP_SERVICES || '{}');
```

--------------------------------

### Map Custom Port to App (V3 API)

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Use the V3 API to map a custom port to an application. This requires platform configuration to allow multiple ports.

```bash
cf curl /v3/apps/GUID/routes \
  -X POST \
  -d '{
    "relationships": {
      "app": {"data": {"guid": "GUID"}}
    },
    "host": "my-app",
    "port": 8080
  }'
```

--------------------------------

### View Service Binding CLI

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

This command displays detailed information about a specific service binding, including metadata, credentials, and associated applications.

```bash
cf service-binding SERVICE-INSTANCE [--name BINDING-NAME]
```

--------------------------------

### Deploy Application with Variables File

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Push your application to Cloud Foundry using the `cf push` command with the `--vars-file` flag to specify the location of your variables file. This ensures that the variables are substituted into the manifest during deployment.

```bash
cf push --vars-file /PATH/vars.yml
```

--------------------------------

### Deploy single app from multi-app manifest

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Use this command to deploy a specific application defined within a multi-application manifest file. Replace `web-app` with the name of the application you wish to deploy.

```bash
cf push web-app
```

--------------------------------

### Bind Service to App CLI

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use this command to bind a service instance to an application. You can optionally provide custom parameters or a binding name.

```bash
cf bind-service APP-NAME INSTANCE-NAME [-c PARAMETERS] [--binding-name NAME]
```

```bash
cf bind-service my-app production-db
```

```bash
cf bind-service my-app production-db --binding-name primary-db
```

--------------------------------

### View Application State with CF CLI

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/app-lifecycle-reference.md

Use the 'cf app' command to view the current state, instance status, URLs, services, and resource allocation of an application.

```bash
cf app APP-NAME
```

--------------------------------

### Specify Application Path

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Define the directory containing the application code. This path becomes the location where the buildpack Detect script runs. The default is the current directory.

```yaml
path: /path/to/app/bits
```

--------------------------------

### cf push with multiple buildpacks

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Deploy an application using multiple buildpacks. Cloud Foundry will attempt to use them in the order provided.

```bash
cf push my-app -b ruby_buildpack -b java_buildpack
```

--------------------------------

### List Cloud Foundry Service Keys

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Display all service keys that have been created for a given service instance.

```bash
cf service-keys INSTANCE-NAME
```

--------------------------------

### Access Environment Variables in Java

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Illustrates how to access environment variables like PORT and DATABASE_URL, and parse JSON-formatted VCAP_APPLICATION in Java. Requires a JSONObject implementation.

```java
String port = System.getenv("PORT");
String dbUrl = System.getenv("DATABASE_URL");

// Parse JSON
String vcapApplication = System.getenv("VCAP_APPLICATION");
JSONObject appMetadata = new JSONObject(vcapApplication);
```

--------------------------------

### Listen on PORT Environment Variable

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Applications must listen on the port specified by the PORT environment variable. Default to 3000 for Node.js, 5000 for Python, or 8080 for Go if PORT is not set. Ensure the app listens on all interfaces (0.0.0.0).

```bash
# Node.js
const port = process.env.PORT || 3000;
app.listen(port);
```

```bash
# Python
port = os.environ.get('PORT', 5000)
app.run(port=port)
```

```bash
# Go
port := os.Getenv("PORT")
if port == "" {
    port = "8080"
}
http.ListenAndServe(":
```

--------------------------------

### Configure Multiple Processes

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Define configurations for apps running multiple processes, such as web UIs and workers. Each process requires a type and command, with optional memory and disk quota settings.

```yaml
processes:
- type: web
  command: start-web.sh
  disk_quota: 512M
  health-check-http-endpoint: /healthcheck
  health-check-type: http
  health-check-invocation-timeout: 10
  instances: 3
  memory: 500M
  timeout: 10
- type: worker
  command: start-worker.sh
  disk_quota: 1G
  health-check-type: process
  instances: 2
  memory: 256M
  timeout: 15
```

--------------------------------

### Configure Number of App Instances

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Specify the number of application instances to run. A minimum of two instances is recommended for high availability during platform maintenance.

```yaml
instances: 2
```

--------------------------------

### Create HTTP Route with Host Name

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Use this command to create a new HTTP route with a specified hostname and domain. The hostname creates a subdomain for the route.

```bash
cf create-route example.com --hostname my-app
```

--------------------------------

### Map Routes via Manifest File

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Define multiple routes for an application within its `manifest.yml` file under the `routes` key. This allows for declarative route management.

```yaml
---
applications:
- name: my-app
  routes:
  - route: example.com
  - route: www.example.com
  - route: example.com/products
```

--------------------------------

### Create HTTP Route with Path

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Creates an HTTP route with a specified domain, hostname, and a context path for more granular routing.

```APIDOC
## Create HTTP Route with Path

### Description
Creates an HTTP route with a specified domain, hostname, and a context path. The routing matches the exact path, and applications must handle requests on this path.

### Command
```bash
cf create-route DOMAIN --hostname HOST --path PATH
```

### Parameters
#### Path Parameters
- **DOMAIN** (string) - Required - Domain name
- **HOST** (string) - Required - Host name
- **PATH** (string) - Required - Context path (leading slash optional)

### Example
```bash
cf create-route example.com --hostname store --path products
cf create-route example.com --hostname store --path orders
cf create-route example.com --hostname store
```

### Route Matching
Exact path match preferred, then host+domain match.

### Constraints
- Different paths in the same space must use the same host/domain.
- Private domains can have paths in different spaces.
- Apps must serve requests on the context path (routing does not strip path).
```

--------------------------------

### Scale Application Multiple Dimensions

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Simultaneously adjust the instance count, memory limit, and disk quota for an application in a single command.

```bash
cf scale my-app -i 3 -m 512M -k 1G
```

--------------------------------

### Delete and Redeploy Application

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Delete an existing application and redeploy it, potentially a previous version. This is a recovery step for critical issues.

```bash
cf delete my-app
cf push my-app-old  # If available
```

--------------------------------

### Binding Service Instances to an App

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Specify service instances to bind to your application. This includes simple names, or more complex configurations with parameters and custom binding names.

```yaml
services:
- postgres-db
- name: redis-cache
- name: message-queue
  parameters:
    queue_mode: transient
- name: api-service
  binding_name: external-api
```

--------------------------------

### Access Environment Variables in Ruby

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Demonstrates how to access environment variables like PORT and DATABASE_URL, and parse JSON-formatted VCAP_APPLICATION and VCAP_SERVICES in Ruby. Uses the built-in JSON library.

```ruby
port = ENV['PORT']
db_url = ENV['DATABASE_URL']

# Parse JSON
vcap_app = JSON.parse(ENV['VCAP_APPLICATION'] || '{}')
vcap_services = JSON.parse(ENV['VCAP_SERVICES'] || '{}')
```

--------------------------------

### Access Environment Variables in Python

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Shows how to retrieve environment variables including PORT and DATABASE_URL, and parse JSON-formatted VCAP_APPLICATION and VCAP_SERVICES in Python. Defaults are provided for PORT.

```python
import os
import json

port = os.environ.get('PORT', 5000)
db_url = os.environ.get('DATABASE_URL')

# Parse JSON env vars
vcap_app = json.loads(os.environ.get('VCAP_APPLICATION', '{}'))
vcap_services = json.loads(os.environ.get('VCAP_SERVICES', '{}'))
```

--------------------------------

### Specify Deployment Stack

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Set the `stack` attribute to define the root filesystem for running your application. Use `cf stacks` to list available stacks.

```yaml
stack: cflinuxfs4
```

--------------------------------

### Bind Service with Custom Parameters

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Configure service binding with specific parameters by passing a JSON object using the -c flag. The service broker interprets these parameters based on its implementation.

```bash
cf bind-service my-app my-db \
  -c '{"read_replica": true, "backup_retention": 30}'
```

--------------------------------

### Test DNS Resolution from a Container

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Verify that your application container can resolve internal and external domain names using `host` and `nslookup`.

```bash
host backend.apps.internal
nslookup cache.apps.internal
```

--------------------------------

### Configure Metadata Labels and Annotations

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Tag applications with additional information using labels and annotations. This allows for custom key-value pairs to categorize or provide context for applications.

```yaml
metadata:
  annotations:
    contact: "bob@example.com jane@example.com"
  labels:
    sensitive: true
    environment: production
```

--------------------------------

### Set Tags for Service Instance

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use this command to add or update tags for a service instance, which helps in categorizing and labeling.

```bash
cf create-service postgres standard my-db -t "production,backup,critical"
```

```bash
cf update-service my-db -t "maintenance-mode,deprecated"
```

--------------------------------

### View Active Network Policies

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

List all configured network policies for your application using the `cf network-policies` command.

```bash
cf network-policies
```

--------------------------------

### Create Wildcard Route

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Create a wildcard route using an asterisk (*) for the hostname. This route acts as a fallback for any subdomain not explicitly mapped.

```bash
cf create-route example.com --hostname '*'
```

--------------------------------

### Check Route Availability

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Verify if a specific route exists by checking its domain, hostname, path, and port. The command indicates whether the route is present.

```bash
cf check-route example.com --hostname store --path products
```

--------------------------------

### Basic Web Application Manifest

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/INDEX.md

Use this manifest for a standard web application. It defines memory, instances, buildpacks, routes, health checks, environment variables, and services.

```yaml
---
applications:
- name: my-web-app
  memory: 512M
  instances: 2
  buildpacks:
    - ruby_buildpack
  routes:
    - route: my-app.example.com
  health-check-type: http
  health-check-http-endpoint: /health
  timeout: 60
  env:
    RAILS_ENV: production
  services:
    - postgres-db
    - redis-cache

```

--------------------------------

### Enable Bidirectional Communication with Network Policies

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

To enable two-way communication between applications, create network policies in both directions using `cf add-network-policy`.

```bash
# A → B
cf add-network-policy app-a --destination-app app-b

# B → A
cf add-network-policy app-b --destination-app app-a
```

--------------------------------

### Listen on Custom Port (Python)

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Configure a Python application to listen on the port specified by the PORT environment variable, defaulting to 5000 if not set.

```python
port = int(os.environ.get('PORT', 5000))
app.run(port=port)
```

--------------------------------

### Restage application

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

This command rebuilds the application's droplet from its source code and then restarts it. This is useful for applying dependency updates or buildpack environment changes. Note that this causes full downtime as all instances stop during the rebuild. Replace `APP-NAME` with your application's name.

```bash
cf restage APP-NAME
```

```bash
cf restage my-app
```

--------------------------------

### List Routes

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Lists all routes within the current space, displaying details like space, host, domain, type, and associated apps.

```APIDOC
## List Routes

### Description
Lists all routes within the current space, showing details such as space, host, domain, type, and the applications mapped to each route.

### Command
```bash
cf routes
```

### Output Columns
- `space`: Space containing route
- `host`: Host name (blank for no-host routes)
- `domain`: Domain name
- `type`: Route type (`http` or `tcp`)
- `apps`: App names mapped to route

### Example Output
```
space           host          domain           type   apps
dev-space       my-app        example.com             my-app
dev-space       store         example.com            products
dev-space       store         example.com            orders
dev-space                      example.com      tcp    tcp-app
```
```

--------------------------------

### Configure Hash-Based Load Balancing

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Configure hash-based load balancing for routes in your manifest file. Specify the load balancing algorithm and the header to use for hashing.

```yaml
routes:
- route: example.com
  options:
    loadbalancing: hash
    hash_header: User-ID
    hash_balance: 1.25
```

--------------------------------

### Map a New Route via CLI

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Use `cf map-route` to associate a new route with an existing application.

```bash
cf map-route my-app example.com --hostname new-name
```

--------------------------------

### View Route Details

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Retrieve and display detailed attributes for a specific route, including domain, host, port, path, protocol, and destinations.

```bash
cf route example.com --hostname my-app
```

--------------------------------

### Database Service Binding in Manifest

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/INDEX.md

Bind a database service to your application using the manifest file. The service name 'postgres-db' is used here. Credentials will be available in the VCAP_SERVICES environment variable.

```yaml
services:
  - name: postgres-db
    
# Credentials available in VCAP_SERVICES:
# vcap_services['postgres'][0]['credentials']['uri']
```

--------------------------------

### Use CF_INSTANCE_GUID for Correlation

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Utilize CF_INSTANCE_GUID for logging and correlation IDs to uniquely identify an application instance.

```bash
instance_guid = os.environ.get('CF_INSTANCE_GUID')
# Use for logging, correlation IDs, etc.
logger.info(f"Instance: {instance_guid}")
```

--------------------------------

### Configure Readiness Health Checks via Manifest

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/health-checks-reference.md

Use this configuration in your manifest.yml file to set readiness health check parameters.

```yaml
readiness-health-check-type: http
readiness-health-check-http-endpoint: /ready
readiness-health-check-invocation-timeout: 5
readiness-health-check-interval: 10
```

--------------------------------

### View details of a specific service instance

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

Use `cf service INSTANCE-NAME` to retrieve detailed information about a particular service instance, including its type, plan, description, bound applications, metadata, and dashboard URL.

```bash
cf service INSTANCE-NAME
```

--------------------------------

### View Application Environment Variables

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/environment-variables-reference.md

Displays all environment variables associated with a Cloud Foundry application, including user-provided variables, VCAP_APPLICATION, VCAP_SERVICES, and running environment details.

```bash
cf env APP-NAME
```

--------------------------------

### Access Application via HTTP

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Access your application using its public URL via HTTP. This is a basic way to verify application accessibility.

```bash
curl https://my-app.example.com
```

--------------------------------

### Enable Hash-Based Session Affinity

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/networking-reference.md

Configure routes to use hash-based load balancing for session affinity. Requires specifying a header for hashing.

```yaml
routes:
- route: example.com
  options:
    loadbalancing: hash
    hash_header: X-Session-ID
```

--------------------------------

### Access Application via SSH

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Connect to an application instance via SSH if enabled. This allows for direct debugging and inspection of the running environment.

```bash
cf ssh my-app
```

--------------------------------

### Bind Shared Service Instance

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/services-reference.md

After a service instance has been shared to another space, applications in that space can bind to it. Ensure you target the correct space before binding.

```bash
# Target other space
cf target -s other-space

# Bind shared service
cf bind-service my-app shared-service-instance
```

--------------------------------

### Configure Docker Image Deployment

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/manifest-attributes.md

Specifies configuration for deploying a Docker image. Requires an image name and optionally a username. If a username is provided, the password must be set via the `CF_DOCKER_PASSWORD` environment variable. This attribute is mutually exclusive with `buildpacks` and `path`.

```yaml
docker:
  image: docker-image-repository/docker-image-name
  username: docker-user-name
```

--------------------------------

### Map Route During `cf push`

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Configure routes directly within the `cf push` command using the `-d` (domain), `--hostname`, and `--path` flags. This simplifies deployment by defining routes at push time.

```bash
cf push my-app -d example.com --hostname my-app
```

--------------------------------

### Create TCP Route with Random Port

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/routing-reference.md

Create a TCP route in a specified space and domain, requesting an available port automatically.

```bash
cf create-route my-space tcp.example.com --random-port
```

--------------------------------

### Delete Application with Options

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/deployment-operations-reference.md

Use `cf delete` to remove an application. The `-f` flag forces deletion without confirmation, and the `-r` flag also deletes mapped routes. Deletion is permanent.

```bash
cf delete APP-NAME [-f] [-r]
```

```bash
cf delete my-app -f -r
```

--------------------------------

### Push App with Health Check Configuration

Source: https://github.com/cloudfoundry/docs-dev-guide/blob/master/_autodocs/health-checks-reference.md

Configure health check type and startup timeout when pushing a new application or updating an existing one. Changes take effect upon app restart.

```bash
cf push APP-NAME \
  --health-check-type LIVENESS-HEALTH-CHECK-TYPE \
  --app-start-timeout TIMEOUT
```