cloudfoundry · kiril-keranov · Sep 18, 2026 · Sep 18, 2026 · Sep 18, 2026 · Sep 18, 2026
diff --git a/README.md b/README.md
@@ -22,7 +22,9 @@ The following are _very_ simple examples for deploying the artifact types that w
 
 ## Configuration and Extension
 
-The buildpack default configuration can be overridden with an environment variable matching the configuration file you wish to override minus the `.yml` extension. It is not possible to add new configuration properties and properties with `nil` or empty values will be ignored by the buildpack (in this case you will have to extend the buildpack, see below). The value of the variable should be valid inline yaml, referred to as "flow style" in the yaml spec ([Wikipedia][] has a good description of this yaml syntax).
+Configurable framework and JRE settings are overridden through component-specific `JBP_CONFIG_*` environment variables (for example, `JBP_CONFIG_OPEN_JDK_JRE` and `JBP_CONFIG_DEBUG`). Consult each component's documentation for its exact variable name and supported fields. The value must be valid inline YAML, referred to as "flow style" in the YAML spec ([Wikipedia][] has a good description of this syntax).
+
+> **Note:** The Ruby buildpack's `config/*.yml` file-based configuration is not used by this buildpack.  All configuration is done through environment variables as described below.
 
 There are two levels of overrides: operator and application developer.
 
@@ -119,11 +121,19 @@ To learn how to configure various properties of the buildpack, follow the "Confi
 
 The buildpack supports extension through the use of Git repository forking. The easiest way to accomplish this is to use [GitHub's forking functionality][] to create a copy of this repository. Make the required extension changes in the copy of the repository. Then specify the URL of the new repository when pushing Cloud Foundry applications. If the modifications are generally applicable to the Cloud Foundry community, please submit a [pull request][] with the changes. More information on extending the buildpack is available [here](docs/extending.md).
 
+## GA Status
+
+**v5.1.0 is the first generally available (GA) release of the Go-based Java Buildpack.**
+
+This release is declared GA in accordance with [RFC-0050][] and supersedes the experimental Go buildpack releases in the 5.0.x line.  The Ruby-based buildpack (4.x) is no longer receiving feature updates; operators are encouraged to migrate to v5.1.0 or later.
+
+[RFC-0050]: https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0050-java-buildpack-migration-to-golang.md
+
 ## Ruby vs Go Migration Status
 
 This Go-based buildpack is a migration from the original Ruby-based Cloud Foundry Java Buildpack. For comprehensive information about the migration status, component parity, and architectural differences:
 
-* **[Ruby vs Go Buildpack Comparison](ruby_vs_go_buildpack_comparison.md)** - Technical deep-dive into how dependency extraction differs between Ruby and Go implementations
+* **[Ruby vs Go Buildpack Comparison](RUBY_VS_GO_BUILDPACK_COMPARISON.md)** - Technical deep-dive into how dependency extraction differs between Ruby and Go implementations
 
 **⚠️ Important Migration Note:** The Go buildpack does **NOT** support the Ruby buildpack's `repository_root` configuration approach for custom JREs (via `JBP_CONFIG_*` environment variables). Custom JREs now require forking the buildpack and modifying `manifest.yml`. See [Custom JRE Usage](docs/custom-jre-usage.md) for details.
 
@@ -375,15 +385,14 @@ For detailed guidelines about setting up and running tests please check this [Te
 ## License
 This buildpack is released under version 2.0 of the [Apache License][].
 
-[`config/` directory]: config
 [Apache License]: http://www.apache.org/licenses/LICENSE-2.0
 [Cloud Foundry]: http://www.cloudfoundry.org
 [contributor guidelines]: CONTRIBUTING.md
 [disables `remote_downloads`]: docs/extending-caches.md#configuration
 [Environment Variables]: http://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#env-block
 [GitHub's forking functionality]: https://help.github.com/articles/fork-a-repo
-[Grails]: http://grails.org
-[Groovy]: http://groovy.codehaus.org
+[Grails]: https://grails.apache.org/
+[Groovy]: https://groovy-lang.org/
 [Play Framework]: http://www.playframework.com
 [pull request]: https://help.github.com/articles/using-pull-requests
 [Pull requests]: http://help.github.com/send-pull-requests

diff --git a/RUBY_VS_GO_BUILDPACK_COMPARISON.md b/RUBY_VS_GO_BUILDPACK_COMPARISON.md
@@ -1,10 +1,12 @@
 # Ruby vs Go Java Buildpack: Comprehensive Architectural Comparison
 
-**Date**: January 5, 2026  
-**Migration Status**: Complete (Production Ready)  
-**Ruby Buildpack**: /home/ramonskie/workspace/tmp/orig-java (Legacy)  
+**Date**: September 18, 2026  
+**Migration Status**: Complete — v5.1.0 is the first generally available (GA) release ([RFC-0050][])  
+**Ruby Buildpack**:  [main-before-go-migration](https://github.com/cloudfoundry/java-buildpack/tree/backup/main-before-go-migration) (Legacy)  
 **Go Buildpack**: Current repository (Active Development)
 
+[RFC-0050]: https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0050-java-buildpack-migration-to-golang.md
+
 ---
 
 ## Executive Summary
@@ -2245,6 +2247,8 @@ required memory 1269289K is greater than 750M available for allocation
 
 ## 11. Conclusion
 
+**v5.1.0 is the first generally available (GA) release of the Go-based Java Buildpack**, declared GA in accordance with [RFC-0050][]. It supersedes the experimental 5.0.x releases; the Ruby-based buildpack (4.x) is no longer receiving feature updates.
+
 The Go-based Java buildpack is a **production-ready, feature-complete** migration from the Ruby buildpack, achieving:
 
 - ✅ **92.9% component parity** (52/56 components)

diff --git a/adoption-migration-details.md b/adoption-migration-details.md
@@ -36,11 +36,11 @@ Applications compiled with Java 8 should generally run on Java 17 without issues
 - Tomcat 9 by default
 - Java 1.8.x by default
 
-**Starting with the Go-based Java Buildpack, they will be switched to:**
+**With the Go-based Java Buildpack, the defaults are:**
 - Tomcat 10
 - Java 17
 
-**This change will take effect only after redeploy or restage.**
+**These new defaults apply after redeploy or restage.**
 
 ## How to Maintain Current Versions
 
@@ -70,16 +70,16 @@ This section highlights significant breaking changes introduced in the Go-based
 
 ### Custom JRE Usage
 
-Custom JRE usage will be supported only as documented in the [Custom JRE Usage Guide](custom-jre-usage.md).
+Custom JRE usage is supported only as documented in the [Custom JRE Usage Guide](docs/custom-jre-usage.md).
 
 ### Changed Default Configuration
 
 - **SpringAutoReconfigurationFramework is now disabled by default.** Please note that `SpringAutoReconfigurationFramework` is deprecated, and the recommended alternative is [java-cfenv](https://github.com/pivotal-cf/java-cfenv).
-- **JRE selection based on `JBP_CONFIG_COMPONENTS` is deprecated.** The Go-based buildpack supports JRE selection based on `JBP_CONFIG_<JRE_TYPE>` as described in the [README](https://github.com/cloudfoundry/java-buildpack/blob/feature/go-migration/README.md#jre-selection).
+- **JRE selection based on `JBP_CONFIG_COMPONENTS` is deprecated.** The Go-based buildpack supports JRE selection based on `JBP_CONFIG_<JRE_TYPE>` as described in the [README](README.md#jre-selection).
 
 ### Frameworks Not Included
 
-The following frameworks will not be migrated to the Go buildpack:
+The following frameworks were not migrated to the Go buildpack:
 
 - **Takipi Agent (OverOps)**: Removed because the agent has moved behind a licensed login wall, making it inaccessible for automated buildpack integration.
 - **Java Security**: Rarely used and custom security policies should be implemented at the platform level or within application code.
@@ -176,7 +176,7 @@ The Ruby buildpack only added `-XX:ActiveProcessorCount=$(nproc)` in the OpenJDK
 
 If you encounter issues during migration or have questions:
 1. Review the [buildpack documentation](../README.md)
-2. Check the [RFC document](https://github.com/cloudfoundry/community/pull/1392) for detailed technical information
+2. Check [RFC-0050](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0050-java-buildpack-migration-to-golang.md) for detailed technical information
 3. Open an issue in the [Java Buildpack repository](https://github.com/cloudfoundry/java-buildpack)
 
 ## Summary Checklist

diff --git a/docs/framework-app_dynamics_agent.md b/docs/framework-app_dynamics_agent.md
@@ -33,15 +33,7 @@ To provide more complex values such as the `tier-name`, using the interactive mo
 ## Configuration
 For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
 
-The framework can be configured by modifying the [`config/app_dynamics_agent.yml`][] file in the buildpack fork. The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
-
-| Name | Description
-| ---- | -----------
-| `default_application_name` | This is omitted by default but can be added to specify the application name in the AppDynamics dashboard. This can be overridden by an `application-name` entry in the credentials payload. If neither are supplied the default is the `application_name` as specified by Cloud Foundry.
-| `default_node_name` | The default node name for this application in the AppDynamics dashboard. The default value is an expression that will be evaluated based on the `instance_index` of the application. This can be overridden by a `node-name` entry in the credentials payload.
-| `default_tier_name` | This is omitted by default but can be added to specify the tier name for this application in the AppDynamics dashboard. This can be overridden by a `tier-name` entry in the credentials payload. If neither are supplied the default is the `application_name` as specified by Cloud Foundry.
-| `repository_root` | The URL of the AppDynamics repository index ([details][repositories]).
-| `version` | The version of AppDynamics to use. Candidate versions can be found in [this listing][].
+The framework has no user-configurable options.  The AppDynamics agent version is managed by the buildpack manifest.  See [Additional Resources](#additional-resources) below for application-level configuration options.
 
 ### Additional Resources
 The framework can be configured by providing custom configuration files.
@@ -100,10 +92,6 @@ The Java buildpack will take the `app_root` + `APPD_CONF_DIR` directory and atte
 Any files that exist will be copied to the configuration directory. The buildpack does not fail if files are missing.
 
 
-[`config/app_dynamics_agent.yml`]: ../config/app_dynamics_agent.yml
 [AppDynamics Java Agent Configuration Properties]: https://docs.appdynamics.com/display/PRO42/Java+Agent+Configuration+Properties
 [AppDynamics Service]: http://www.appdynamics.com
 [Configuration and Extension]: ../README.md#configuration-and-extension
-[repositories]: extending-repositories.md
-[this listing]: https://packages.appdynamics.com/java/index.yml
-[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-aspectj_weaver_agent.md b/docs/framework-aspectj_weaver_agent.md
@@ -16,11 +16,18 @@ Tags are printed to standard output by the buildpack detect script
 ## Configuration
 For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
 
-The framework can be configured by creating or modifying the [`config/aspectj_weaver_agent.yml`][] file in the buildpack fork.
+The framework can be configured by setting the `JBP_CONFIG_ASPECTJ_WEAVER_AGENT` environment variable.  The value must be valid inline YAML.
 
 | Name | Description
 | ---- | -----------
-| `enabled` | Whether to enable the AspectJ Runtime Weaving agent.
+| `enabled` | Whether to enable the AspectJ Runtime Weaving agent.  Defaults to `true`.
+
+### Example
+
+Disable the AspectJ weaver agent:
+
+```yaml
+JBP_CONFIG_ASPECTJ_WEAVER_AGENT: '{enabled: false}'
+```
 
-[`config/aspectj_weaver_agent.yml`]: ../config/aspect_weaver_agent.yml
 [Configuration and Extension]: ../README.md#configuration-and-extension
diff --git a/docs/framework-client_certificate_mapper.md b/docs/framework-client_certificate_mapper.md
@@ -18,20 +18,23 @@ Tags are printed to standard output by the buildpack detect script
 ## Configuration
 For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
 
-The framework can be configured by modifying the [`config/client_certificate_mapper.yml`][] file in the buildpack fork.  The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+The framework can be configured by setting the `JBP_CONFIG_CLIENT_CERTIFICATE_MAPPER` environment variable.  The value must be valid inline YAML.
 
 | Name              | Description
 |-------------------| -----------
-| `repository_root` | The URL of the Container Customizer repository index ([details][repositories]).
-| `version`         | The version of Container Customizer to use. Candidate versions can be found in [this listing][].
+| `enabled` | Whether to enable the Client Certificate Mapper.  Defaults to `true`.
+
+### Example
+
+Disable the client certificate mapper:
+
+```yaml
+JBP_CONFIG_CLIENT_CERTIFICATE_MAPPER: '{enabled: false}'
+```
 
 ## Servlet Filter
 The [Servlet Filter][] added by this framework maps the `X-Forwarded-Client-Cert` to the `javax.servlet.request.X509Certificate` Servlet attribute for each request.  The `X-Forwarded-Client-Cert` header is contributed by the Cloud Foundry Router and contains the any TLS certificate presented by a client for mututal TLS authentication.  This certificate can then be used by any standard Java security framework to establish authentication and authorization for a request.
 
-[`config/client_certificate_mapper.yml`]: ../config/client_certificate_mapper.yml
 [Configuration and Extension]: ../README.md#configuration-and-extension
-[repositories]: extending-repositories.md
 [Servlet Filter]: https://github.com/cloudfoundry/java-buildpack-client-certificate-mapper
-[this listing]: http://download.pivotal.io.s3.amazonaws.com/container-security-provider/index.yml
-[version syntax]: extending-repositories.md#version-syntax-and-ordering
 [library repository]: https://github.com:cloudfoundry/java-buildpack-client-certificate-mapper.git
diff --git a/docs/framework-container_customizer.md b/docs/framework-container_customizer.md
@@ -16,15 +16,6 @@ Tags are printed to standard output by the buildpack detect script
 ## Configuration
 For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
 
-The framework can be configured by modifying the [`config/container_customizer.yml`][] file in the buildpack fork.  The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
-
-| Name | Description
-| ---- | -----------
-| `repository_root` | The URL of the Container Customizer repository index ([details][repositories]).
-| `version` | The version of Container Customizer to use. Candidate versions can be found in [this listing][].
+The framework has no user-configurable buildpack options.  The Container Customizer version is managed by the buildpack manifest.
 
 [Configuration and Extension]: ../README.md#configuration-and-extension
-[`config/container_customizer.yml`]: ../config/container_customizer.yml
-[repositories]: extending-repositories.md
-[this listing]: http://download.pivotal.io.s3.amazonaws.com/container-customizer/index.yml
-[version syntax]: extending-repositories.md#version-syntax-and-ordering
diff --git a/docs/framework-container_security_provider.md b/docs/framework-container_security_provider.md
@@ -16,24 +16,37 @@ Tags are printed to standard output by the buildpack detect script
 ## Configuration
 For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][].
 
-The framework can be configured by modifying the [`config/container_security_provider.yml`][] file in the buildpack fork.  The framework uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there.
+The framework can be configured by setting the `JBP_CONFIG_CONTAINER_SECURITY_PROVIDER` environment variable.  The value must be valid inline YAML.
 
 | Name | Description
 | ---- | -----------
-| `repository_root` | The URL of the Container Customizer repository index ([details][repositories]).
-| `version` | The version of Container Customizer to use. Candidate versions can be found in [this listing][].
 | `key_manager_enabled` | Whether the container `KeyManager` is enabled.  Defaults to `true`.
 | `trust_manager_enabled` | Whether the container `TrustManager` is enabled.  Defaults to `true`.
 
+### Examples
+
+Disable the `KeyManager`:
+
+```yaml
+JBP_CONFIG_CONTAINER_SECURITY_PROVIDER: '{key_manager_enabled: false}'
+```
+
+Disable the `TrustManager`:
+
+```yaml
+JBP_CONFIG_CONTAINER_SECURITY_PROVIDER: '{trust_manager_enabled: false}'
+```
+
 ## Security Provider
 The [security provider][] added by this framework contributes two types, a `TrustManagerFactory` and a `KeyManagerFactory`.  The `TrustManagerFactory` adds an additional new `TrustManager` after the configured system `TrustManager` which reads the contents of `/etc/ssl/certs/ca-certificates.crt` which is where [BOSH trusted certificates][] are placed.  The `KeyManagerFactory` adds an additional `KeyManager` after the configured system `KeyManager` which reads the contents of the files specified by `$CF_INSTANCE_CERT` and `$CF_INSTANCE_KEY` which are set by Diego to give each container a unique cryptographic identity.  These `TrustManager`s and `KeyManager`s are used transparently by any networking library that reads standard system SSL configuration and can be used to enable system-wide trust and [mutual TLS authentication][].
 
+The path read by the `TrustManager` defaults to `/etc/ssl/certs/ca-certificates.crt` but can be overridden by setting the `CF_CA_CERTS` environment variable to an alternate file path.
+
+> **Note:** This is distinct from — but complementary to — Cloud Foundry's [Trusted System Certificates][] feature (`CF_SYSTEM_CERT_PATH`, `/etc/cf-system-certificates`).  Diego's executor merges operator-deployed trusted system certificates into `/etc/ssl/certs`, so they are automatically picked up by the `TrustManager`'s default path without any additional configuration.
+
 
-[`config/container_security_provider.yml`]: ../config/container_security_provider.yml
 [BOSH trusted certificates]: https://bosh.io/docs/trusted-certs.html
 [Configuration and Extension]: ../README.md#configuration-and-extension
 [mutual TLS authentication]: https://en.wikipedia.org/wiki/Mutual_authentication
-[repositories]: extending-repositories.md
 [security provider]: https://github.com/cloudfoundry/java-buildpack-security-provider
-[this listing]: http://download.pivotal.io.s3.amazonaws.com/container-security-provider/index.yml
-[version syntax]: extending-repositories.md#version-syntax-and-ordering
+[Trusted System Certificates]: https://docs.cloudfoundry.org/devguide/deploy-apps/trusted-system-certificates.html