Order of buildpacks for multi-buildpacks is not being respected in application manifests

### Issue

Starting with CAPI release 1.234.0 when applications which leverage multiple buildpacks in an app manifest is run, the order applied seems to be alphabetical to start with, then alternates in an inconsistent pattern.



### Context

This is using cf-deployment v56.0.1 with CAPI release pinned via an ops file to v1.234.0 to mitigate the postgres db migration issues.



### Steps to Reproduce

I have an application manifest that has two buildpacks referenced:

```
applications:
- name: cf-multi-buildpack-hello
  memory: 256M
  disk_quota: 512M
  buildpacks:
  - python_buildpack
  - nodejs_buildpack
  command: npm start
```

When I push the app, you can see that it does nodejs first THEN python:

```
Updating with these attributes...
  ---
  applications:
+ - name: cf-multi-buildpack-hello
    disk-quota: 512M
    memory: 256M
+   default-route: true
+   buildpacks:
+   - python_buildpack
+   - nodejs_buildpack
+   command: npm start
Manifest applied
Packaging files to upload...
Uploading files...
 1.08 KiB / 1.08 KiB [=================================================================================================================================================================================] 100.00% 1s

Waiting for API to complete processing files...

Staging app and tracing logs...
   Downloading python_buildpack...
   Downloading nodejs_buildpack...
   Downloaded python_buildpack
   Downloaded nodejs_buildpack
   Cell f3b3f020-4811-45df-8498-d23d5871e3d7 creating container for instance 57b2005d-d788-4c85-b892-d5510ce88ed5
   Security group rules were updated
   Cell f3b3f020-4811-45df-8498-d23d5871e3d7 successfully created container for instance 57b2005d-d788-4c85-b892-d5510ce88ed5
   Downloading app package...
   Downloaded app package (1.1K)
   -----> Nodejs Buildpack version 1.8.44
   -----> Bootstrapping python
   -----> Installing python 3.11.14
   Download [https://buildpacks.cloudfoundry.org/dependencies/python/python_3.11.14_linux_x64_cflinuxfs4_66f53248.tgz]
   -----> Installing binaries
   engines.node (package.json): unspecified
   engines.npm (package.json): unspecified (use default)
   **WARNING** Node version not specified in package.json or .nvmrc. See: http://docs.cloudfoundry.org/buildpacks/node/node-tips.html
   -----> Installing node 22.22.0
   Download [https://buildpacks.cloudfoundry.org/dependencies/node/node_22.22.0_linux_x64_cflinuxfs4_a73ffe6d.tgz]
   Using default npm version: 10.9.4
   -----> Installing yarn 1.22.22
   Download [https://buildpacks.cloudfoundry.org/dependencies/yarn/yarn_1.22.22_linux_noarch_any-stack_4911d0a6.tgz]
   Installed yarn 1.22.22
   -----> Creating runtime environment
   PRO TIP: It is recommended to vendor the application's Node.js dependencies
   Visit http://docs.cloudfoundry.org/buildpacks/node/index.html#vendoring
   NODE_ENV=production
   NODE_HOME=/tmp/contents3988342443/deps/0/node
   NODE_MODULES_CACHE=true
   NODE_VERBOSE=false
   NPM_CONFIG_LOGLEVEL=error
   NPM_CONFIG_PRODUCTION=true
   -----> Building dependencies
   Installing node modules (package.json)
   added 69 packages, and audited 70 packages in 1s
   16 packages are looking for funding
   run `npm fund` for details
   found 0 vulnerabilities
   npm notice
   npm notice New major version of npm available! 10.9.4 -> 11.13.0
   npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.13.0
   npm notice To update run: npm install -g npm@11.13.0
   npm notice
   **WARNING** Unmet dependencies don't fail npm install but may cause runtime issues
   See: https://github.com/npm/npm/issues/7494
   -----> Python Buildpack version 1.8.43
   -----> Supplying Python
   -----> Installing python 3.10.19
   Download [https://buildpacks.cloudfoundry.org/dependencies/python/python_3.10.19_linux_x64_cflinuxfs4_b9b2cdae.tgz]
   Using python's pip module
   pip 23.0.1 from /tmp/contents3988342443/deps/1/python/lib/python3.10/site-packages/pip (python 3.10)
   -----> Running Pip Install (Unvendored)
   python -m pip install -r /tmp/app/requirements.txt --ignore-installed --exists-action=w --src=/tmp/contents3988342443/deps/1/src --disable-pip-version-check --no-warn-script-location
   Collecting requests==2.28.0
   Downloading requests-2.28.0-py3-none-any.whl (62 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 62.8/62.8 kB 2.0 MB/s eta 0:00:00
   Collecting urllib3<1.27,>=1.21.1
   Downloading urllib3-1.26.20-py2.py3-none-any.whl (144 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 144.2/144.2 kB 5.7 MB/s eta 0:00:00
   Collecting charset-normalizer~=2.0.0
   Downloading charset_normalizer-2.0.12-py3-none-any.whl (39 kB)
   Collecting certifi>=2017.4.17
   Downloading certifi-2026.4.22-py3-none-any.whl (135 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 135.7/135.7 kB 6.4 MB/s eta 0:00:00
   Collecting idna<4,>=2.5
   Downloading idna-3.13-py3-none-any.whl (68 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 68.6/68.6 kB 5.7 MB/s eta 0:00:00
   Installing collected packages: urllib3, idna, charset-normalizer, certifi, requests
   Successfully installed certifi-2026.4.22 charset-normalizer-2.0.12 idna-3.13 requests-2.28.0 urllib3-1.26.20
   No start command specified by buildpack or via Procfile.
   App will not start unless a command is provided at runtime.
   Exit status 0
   Uploading droplet, build artifacts cache...
   Uploading droplet...
   Uploading build artifacts cache...
   Uploaded build artifacts cache (211.7M)
   Uploaded droplet (121.8M)
   Uploading complete
   Cell redacted stopping instance 57b2005d-d788-4c85-b892-d5510ce88ed5
   Cell redacted destroying container for instance 57b2005d-d788-4c85-b892-d5510ce88ed5

Waiting for app cf-multi-buildpack-hello to start...

Instances starting...
Instances starting...
Instances starting...
Instances starting...
Instances starting...

name:              cf-multi-buildpack-hello
requested state:   started
routes:            cf-multi-buildpack-hello.fr-stage.cloud.gov
last uploaded:     Wed 06 May 10:27:58 EDT 2026
stack:             cflinuxfs4
buildpacks:
	name               version   detect output   buildpack name
	python_buildpack   1.8.43    python          python
	nodejs_buildpack   1.8.44                    nodejs

type:            web
sidecars:
instances:       1/1
memory usage:    256M
start command:   npm start
     state     since                  cpu    memory       disk         logging        cpu entitlement   details   ready
#0   running   2026-05-06T14:28:18Z   0.0%   0B of 256M   0B of 512M   0B/s of 0B/s   0.0%                        true
```


After successful deployment of the app, if I ask the CLI to generate a manifest, it has changed the order of the buildpacks:

```
cf create-app-manifest cf-multi-buildpack-hello
Creating an app manifest from current settings of app cf-multi-buildpack-hello in org redacted / space redacted as redacted...
Manifest file created successfully at /redacted/cf-multi-buildpack-hello_manifest.yml
OK

cf-multi-buildpack-app % cat cf-multi-buildpack-hello_manifest.yml
---
applications:
- name: cf-multi-buildpack-hello
  lifecycle: buildpack
  buildpacks:
  - nodejs_buildpack
  - python_buildpack
  stack: cflinuxfs4
  features:
    ssh: true
    revisions: true
    service-binding-k8s: false
    file-based-vcap-services: false
  routes:
  - route: cf-multi-buildpack-hello.redacted
    protocol: http1
    options: {}
  processes:
  - type: web
    instances: 1
    memory: 256M
    disk_quota: 512M
    log-rate-limit-per-second: -1
    command: npm start
    health-check-type: port
    readiness-health-check-type: process
```

Repushing the application and then rerunning create-app-manifest you can see the results alternate the order of the buildpacks:

```
cat cf-multi-buildpack-hello_manifest.yml
---
applications:
- name: cf-multi-buildpack-hello
  lifecycle: buildpack
  buildpacks:
  - python_buildpack
  - nodejs_buildpack
  stack: cflinuxfs4
  features:
    ssh: true
    revisions: true
    service-binding-k8s: false
    file-based-vcap-services: false
  routes:
  - route: redacted
    protocol: http1
    options: {}
  processes:
  - type: web
    instances: 1
    memory: 256M
    disk_quota: 512M
    log-rate-limit-per-second: -1
    command: npm start
    health-check-type: port
    readiness-health-check-type: process
```

### Expected Result

I would expect the order of the buildpacks in the app manifest to be respected during the deploy

I would expect that the order of the buildpacks does not alternate after performing additional push/restage commands in which the manifest.yml file is NOT changed.

### Current Result

See steps to reproduce

### Possible Fix

Attempting to roll back to CAPI 1.231.0, will update the issue with these results

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Order of buildpacks for multi-buildpacks is not being respected in application manifests #5090

Issue

Context

Steps to Reproduce

Expected Result

Current Result

Possible Fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Order of buildpacks for multi-buildpacks is not being respected in application manifests #5090

Description

Issue

Context

Steps to Reproduce

Expected Result

Current Result

Possible Fix

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions