WIP: How do I make sure to retain custom buildpacks when I upgrade Tanzu Platform for Cloud Foundry?
search cancel

WIP: How do I make sure to retain custom buildpacks when I upgrade Tanzu Platform for Cloud Foundry?

book

Article ID: 404956

calendar_today

Updated On:

Products

VMware Tanzu Platform - Cloud Foundry

Issue/Introduction

Custom buildpacks are not automatically retained or migrated as part of a standard Tanzu Platform for Cloud Foundry upgrade. The upgrade process primarily focuses on updating the platform components (e.g., Cloud Controller, Diego, and system buildpacks) and does not inherently carry over user-defined custom buildpacks.

Resolution

Key Considerations for Custom Buildpacks During Upgrades
  1. Default Behavior and Retention:
    • Custom buildpacks are not automatically retained or migrated as part of a standard Tanzu Platform for Cloud Foundry upgrade. The upgrade process primarily focuses on updating the platform components (e.g., Cloud Controller, Diego, and system buildpacks) and does not inherently carry over user-defined custom buildpacks.
    • If your custom buildpacks are stored in an external repository (e.g., a Git repository) or uploaded to the platform via the Cloud Foundry Command Line Interface (cf CLI) with cf create-buildpack, they will not be automatically re-applied or re-uploaded during an upgrade. You must manually re-upload or reconfigure them post-upgrade.
  2. Pre-Upgrade Preparation:
    • The documentation from Broadcom’s techdocs (e.g., "Creating custom buildpacks for Cloud Foundry," published 2025-06-03) emphasizes that custom buildpacks should be managed separately from the platform. It suggests using the Buildpack Packager to create and version custom buildpacks, which can then be reapplied after an upgrade.
    • Before upgrading, it’s recommended to back up your custom buildpacks (e.g., their manifests and binaries) and document their configurations. This ensures you can restore them post-upgrade.
  3. Post-Upgrade Actions:
    • After an upgrade, you need to re-upload custom buildpacks using cf create-buildpack or update their references if they are sourced from an external repository. The platform will not retain the previous buildpack state unless explicitly reintroduced.
    • The techdocs also note that upgrading to stacks like cflinuxfs4 (based on Ubuntu 22.04) may require migrating apps and custom buildpacks to be compatible with the new stack. If your custom buildpacks are tied to an older stack (e.g., cflinuxfs3), they may need to be rebuilt or adjusted to work with the upgraded environment.
  4. Best Practices:
  5. Considerations
    • Downtime: Be aware that restaging an app will cause downtime. Use strategies like blue-green deployments to minimize downtime for production applications.
    • Testing: After restaging, carefully test your applications to ensure they function as expected with the new buildpack.
    • Rollback: Be prepared to rollback to a previous version if issues occur after restaging. Blue-green deployments offer a straightforward rollback mechanism.
    • Dependencies: Be cautious of apps that link statically to libraries provided in the root file system. These apps may need manual restaging to pick up stack changes.
    • Buildpack Release Notes: Always review the release notes for new buildpack versions to understand changes and potential impacts on your applications.
    • Environment Variables: If your buildpack consumes environment variables, ensure those variables are properly configured before restaging. 

 

Additional Information