+
+
Median Build Times (in minutes) for Digital.gov by Month
+
Digital.gov was taking seventeen minutes to build on cloud.gov Pages with most of the time spent uploading new files. After the October release of publishing improvements, build times were reduced to about seven or eight minutes.
+
+!["Chart - Faster Builds"]({{site.baseurl}}/img/content/cloud-gov-pages-faster-builds-1.svg)
+
+
+ Median Build Times for Digital.gov by Month
+
+
+ |
+ June |
+ July |
+ August |
+ September |
+ October |
+ November |
+ December |
+ January |
+ February |
+
+
+
+
+ Median build times in minutes |
+ 15.1 |
+ 15.8 |
+ 16.8 |
+ 17.1 |
+ 17.1 |
+ 8.5 |
+ 7.1 |
+ 7.1 |
+ 6.8 |
+
+
+
+
Source: internal cloud.gov Pages analytic data
+
+
+## Caching build dependencies
+
+Sites were installing all required custom software dependencies on each build. This process commonly takes about two or
+three minutes. We replaced this step with a new, opt-out, caching strategy:
+
+- If your dependencies didn’t change from the previous build, we’ll re-download the prior package from a secure cache.
+ This takes about fifteen seconds
+- If your dependencies did change, which doesn’t happen often, we’ll re-install them.
+- Because downloading dependencies from a cache can create some errors, we have
+ an [option to opt-out](https://cloud.gov/pages/documentation/cache-dependencies/#configuration).
+
+We just recently added this change, so we’re still waiting to see the full metrics on how it’s improved build time. But
+many sites using the popular [Jekyll framework](https://jekyllrb.com/) have seen their build time reduced by about three
+minutes. You can see the effect of both of these changes in our median build time since June of last year:
+
+
+
+
Median Build Times (in minutes) for cloud.gov Pages Sites by Month
+
Sites were taking about six minutes to build in mid-2022. Publishing improvements in October helped reduce the time by about two minutes. Caching improvements in January reduced the build time by about another minute.
+
+!["Chart - Faster Builds 2"]({{site.baseurl}}/img/content/could-gov-pages-faster-builds-2.svg)
+
+
+ Median Build Times for cloud.gov Pages Sites by Month
+
+
+ |
+ June |
+ July |
+ August |
+ September |
+ October |
+ November |
+ December |
+ January |
+ February |
+
+
+
+
+ Median build times in minutes |
+ 5.2 |
+ 5.9 |
+ 5.5 |
+ 5.7 |
+ 5.6 |
+ 4.5 |
+ 3.5 |
+ 3.3 |
+ 2.7 |
+
+
+
+
Source: internal cloud.gov Pages analytic data
+
+
+Please [let us know](mailto:inquiries@cloud.gov) if these new features have helped you out or you’d like to try [cloud.gov Pages](https://cloud.gov/pages).
diff --git a/content/news/articles/2023-03-08-cloud-gov-pages-cve-2022-28923.md b/content/news/articles/2023-03-08-cloud-gov-pages-cve-2022-28923.md
new file mode 100644
index 0000000..ec90454
--- /dev/null
+++ b/content/news/articles/2023-03-08-cloud-gov-pages-cve-2022-28923.md
@@ -0,0 +1,9 @@
+---
+layout: layouts/post
+tags: news
+title: Cloud.gov Pages Fix CVE-2022-28923
+date: 2023-03-08
+excerpt: After reports of an open redirection vulnerability on cloud.gov Pages sites, we updated our platform's proxy to handle possible vulnerable requests.
+---
+
+On Tuesday March 7th, 2023, we received reports that cloud.gov Pages sites were susceptible to an open redirection vulnerability which could allow a nefarious actor to redirect users to phishing websites via crafted URLs. You can read about the NIST [CVE-2022-28923](https://nvd.nist.gov/vuln/detail/CVE-2022-28923) for more information. After verifying the reports, we released an update to our proxy in the afternoon of Tuesday March 7th, 2023 to handle any nefarious URL's with a 404 response. We also invalidated the CDN caches on customer's production domains to remove any potentially cached redirects.
diff --git a/content/news/articles/2023-03-16-release-notes.md b/content/news/articles/2023-03-16-release-notes.md
new file mode 100644
index 0000000..fc8e50d
--- /dev/null
+++ b/content/news/articles/2023-03-16-release-notes.md
@@ -0,0 +1,133 @@
+---
+layout: layouts/post
+tags: news
+date: 2023-03-16
+title: "March 16th cloud.gov Change Log"
+excerpt: The cloud.gov team is working on providing change logs so everyone can see new features and updates. Happy March Madness!
+---
+
+# Change Log
+
+## Customer Facing Changes
+---
+### Binary Buildpack - v1.1.3 up from v1.1.2
+* Updating github-config
+ * Uncached buildpack SHA256: 5523f4077d792b386671421f31899f409ea8ce5b8ae781cb4f84358cd138b5fd
+ * Uncached buildpack SHA256: 5dd66be045a50d1e4f1dc12e317e85add9fbe74734b3f9882a8a02578b66809f
+ * Uncached buildpack SHA256: 50836f839547c13d6ef435d87ce8e2b4863fdfe32343a26514d321cc8455d177
+ * Uncached buildpack SHA256: 1f72560521b626e5012934f39f62d31192f6bf8c3b6ec5a91f5216ff1e36b5ae
+
+### CFLinuxfs3 - 0.356.0 up from 0.352.0
+* USN-5923-1 USN-5923-1: LibTIFF vulnerabilities
+* USN-5767-3 USN-5767-3: Python vulnerability
+* USN-5921-1 USN-5921-1: rsync vulnerabilities
+* USN-5871-2 USN-5871-2: Git regression
+* USN-5900-1 USN-5900-1: tar vulnerability
+* USN-5891-1 USN-5891-1: curl vulnerabilities
+* USN-5870-1 USN-5870-1: apr-util vulnerability
+* USN-5871-1 USN-5871-1: Git vulnerabilities
+* USN-5855-1 USN-5855-1: ImageMagick vulnerabilities
+
+### CFLinuxfs4 - 0.72.0 up from 0.64.0
+* USN-5923-1 USN-5923-1: LibTIFF vulnerabilities
+* USN-5921-1 USN-5921-1: rsync vulnerabilities
+* USN-5908-1 USN-5908-1: Sudo vulnerability
+* USN-5900-1 USN-5900-1: tar vulnerability
+* USN-5901-1 USN-5901-1: GnuTLS vulnerability
+* USN-5891-1 USN-5891-1: curl vulnerabilities
+* USN-5885-1 USN-5885-1: APR vulnerability
+
+### Dotnet-Core-Buildpack - 2.4.8 up from 2.4.7
+* Add dotnet-runtime 6.0.14, remove dotnet-runtime 6.0.13 (#748)
+* Add dotnet-aspnetcore 6.0.14, remove dotnet-aspnetcore 6.0.13 (#747)
+* Add dotnet-runtime 7.0.3, remove dotnet-runtime 7.0.2 (#746)
+* Add dotnet-aspnetcore 7.0.3, remove dotnet-aspnetcore 7.0.2 (#745)
+* Add dotnet-sdk 7.0.200, remove dotnet-sdk 7.0.102 (#744)
+* Add dotnet-sdk 6.0.406, remove dotnet-sdk 6.0.405 (#742)
+* Add node 18.14.2, remove node 18.14.0 (#743)
+ for stack(s) cflinuxfs3, cflinuxfs4
+* Update libbuildpack-dynatrace (#691)
+* Removes compatibility table that only exists for brats tests and replaces it with simpler logic
+
+### Go-Buildpack 1.10.6 up from 1.10.4
+* Add go 1.20.1
+for stack(s) cflinuxfs3, cflinuxfs4
+
+### Nginx-Buildpack 1.2.1 up from 1.2.0
+* Bump github.com/Dynatrace/libbuildpack-dynatrace from 1.5.1 to 1.5.2 (#186)
+* Updating github-config
+
+### NodeJS Buildpack v1.8.6 up from v1.8.5
+* Add node 18.14.1, remove node 18.12.1 for stack(s) cflinuxfs4, cflinuxfs3
+* Add node 16.19.1, remove node 16.18.1 for stack(s) cflinuxfs3, cflinuxfs4
+* Add node 14.21.3, remove node 14.21.1 for stack(s) cflinuxfs3, cflinuxfs4
+* Update Node 16.x deprecation date (Nodejs update on SSL deprecation) ref
+
+### PHP buildpack v4.6.0 up fron v4.5.0
+* Add composer 2.5.4, remove composer 2.5.2 for stack(s) cflinuxfs4, cflinuxfs3
+* Bump newrelic to 10.6.0.318
+* Add appdynamics 23.2.0-684, remove appdynamics 22.12.1-677 for stack(s) cflinuxfs4, cflinuxfs3
+* Add cflinuxfs4 stack support
+
+## Platform Changes
+---
+### Cf-cli release - v1.44 up from v1.41
+| Major version |Prior version | Current version
+| -----| -----| -----|
+| v8 | 8.5.0 | 8.6.0
+|v7 | 7.5.0 | 7.6.0
+|v6 | 6.53.0 | 6.53.0
+
+### CF-Networking - v3.23.0 up from v3.22.0
+* Bump to go 1.20.1
+* Update healthchecker to 0.4.0
+* Increase startup delay default to 30 seconds PR
+
+### Diego Release - v2.72.0 up from v2.71.0
+* Envoy bump to 1.25.1
+* Metric tags can be updated for running containers
+* Support for configurable entrypoints in buildpackapplifecycle (cloudfoundry/buildpackapplifecycle#58)
+
+### Garden-Runc 1.25.0 up from 1.23.0
+* Bump runc version to 1.1.4
+* Bump containerd version to 1.6.19
+* Fix #233
+* Remove xfs-progs blob from release by @winkingturtle-vmw in #243
+* Build iptables with musl and disable sharing by @winkingturtle-vmw in #251
+* Build containerd from guardian by @winkingturtle-vmw in #253
+* Bring back xfsprogs by @winkingturtle-vmw in #254
+* Bump to go 1.20
+* Update healthchecker to 0.4.0
+* Increase startup delay default to 30 seconds PR
+
+### Loggregator-Agent 7.1.0 up from 7.0.0
+* Add app-id and drain url in the error message
+* Sanitize ProcID in syslog messages so messages with utf-8 in the source_type are not dropped
+
+### Nats 56 up from 54
+* Built with go 1.19.4
+
+### Prometheus 28.0.0 up from 27.2.2
+* prometheus features can be enabled using spec prometheus.enable_features (#455, thanks @chitoku-k )
+* cloudfoundry and bosh dashboards are fixed for Grafana 9 (fixes #453, #456, thanks @psycofdj)
+* bump cf_exporter to v1.0.0 and rework job config (#457, #458, thanks @benjaminguttmann-avtq @psycofdj )
+* ops-file manifests/operators/enable-cf-api-v3.yml has been deleted, use of v3 API is implied in new version of exporter
+* nginx is aware of hosts file changes (#454, thanks @dark5un)
+* various bumps (thanks @benjaminguttmann-avtq)
+ * Stackdriver Exporter to v0.13.0
+ * Redis Exporter to v1.48.0
+ * Memcached Exporter to 0.11.2
+ * InfluxDB Exporter to v0.11.3
+ * HAProxy Exporter to v0.15.0
+ * Graphite Exporter to 0.13.3
+ * Grafana to 9.4.3
+ * Prometheus to v2.42.0
+
+### Routing 0.259.0 up from 0.257.0
+* Update healthchecker to 0.4.0
+* Increase startup delay default to 30 seconds PR
+* Upgrade golang to 1.20.1
+* No changes from last version.
+* Fixing CI so that artifacts are generated correctly for github release.
+
+
diff --git a/content/news/articles/2023-03-28-cflinuxfs3-deprecation.md b/content/news/articles/2023-03-28-cflinuxfs3-deprecation.md
new file mode 100644
index 0000000..86348c4
--- /dev/null
+++ b/content/news/articles/2023-03-28-cflinuxfs3-deprecation.md
@@ -0,0 +1,99 @@
+---
+layout: layouts/post
+tags: news
+date: 2023-03-28
+title: "Deprecation of cflinuxfs3"
+excerpt: Ubuntu 22.04 stack (cflinuxfs4) buildpacks are here and Ubuntu 18.04 (cflinuxfs3) are retiring, test and upgrade your apps now!
+---
+
+
+> ***Important Update - 4/27/2023*** : The original instructions indicated that a `cf restage` will move apps to cflinuxfs4. It does not, you have to `cf push -s STACK_NAME` your application.
+
+> ***Important Update - 5/16/2023*** : The deprecation dates for cflinuxfs3 have been pushed out from the original date of 5/10/2023 to the dates now seen in the document.
+
+# Deprecation of cflinuxfs3
+
+## Ubuntu 22.04 stack (cflinuxfs4) buildpacks are here and Ubuntu 18.04 (cflinuxfs3) are retiring: Test and upgrade your apps now!
+
+
+The base OS image used by your cloud.gov applications is called a "stack". The stack we’ve provided to date is called `cflinuxfs3`, and it’s based on Ubuntu 18.04 LTS, released originally in mid 2018 with continuous security updates since then. `cflinuxfs4` is a new OS image based on Ubuntu 22.04 LTS, and it’s already available for your use. We’ll be making cflinuxfs4 the default stack in cloud.gov on April 27th. In addition, Ubuntu 18.04 will likely no longer receive security updates in May, so we will stop supporting cflinuxfs3 in cloud.gov May 10th.
+
+### Who is impacted?
+
+If you push your Cloud Foundry applications as Docker containers with `cf push --docker-image `, these changes do not impact you.
+
+However, most cloud.gov customers deploy their applications using buildpacks, and their apps don’t have any dependency on the particular OS version that runs them. If that describes you, this upgrade will probably be a miraculous non-event… You can request the new stack at your next cf push with a stack parameter and carry on as you always have.
+
+However, there may be exceptions! For example, you may have used the `apt-buildpack` to ensure that a particular library or utility is installed when your app is deployed. In that case, you might run into problems if the location or name of that dependency has changed between Ubuntu 18.04 and Ubuntu 22.04. You'll also want to be sure to use the newest [v0.3.0](https://github.com/cloudfoundry/apt-buildpack/releases/tag/v0.3.0) version of this release which supports cflinuxfs4.
+
+### What should you do now?
+
+If you are using buildpacks to build your apps, you should try out the new cflinuxfs4 stack before we make it the default on April 27th. Check out the [Cloud Foundry stack docs](https://docs.cloudfoundry.org/devguide/deploy-apps/stacks.html) to see how. To change your stack and re-push your app, run the following command:
+
+```shell
+cf push MY-APP -s cflinuxfs4
+```
+
+### What happens if your testing fails?
+
+
+If you find problems, you can continue using the deprecated cflinuxfs3 stack until you’ve resolved any issues and are ready to transition your apps. After April 27th you can use the following command to temporarily use the older stack:
+
+```shell
+cf push MY-APP -s cflinuxfs3
+```
+
+
+However, this is only a temporary solution because cflinuxfs3 will be removed as an option after May 10th. Plan to make the switch soon so you’re not up against the deadline!
+
+
+### Checking your progress
+
+#### Option 1 - Use the Dashboard UI for individual apps
+
+You can use the Stratos UI dashboard at `https://dashboard.fr.cloud.gov/` and navigate to "Applications > select an app > Build info" to see what stack version each of your applications is using. If it says "cflinuxfs3" you still need to upgade your stack by repushing your application with the stack paramter.
+
+#### Option 2 - Use the CF cli for all apps
+
+To quickly see the which of your applications are still using `cflinuxfs3`, the following script can be used. Note that it requires you to be logged in with the CF cli, target an org and have `jq` installed:
+
+
+
+```shell
+cf curl "/v3/apps?per_page=5000&include=space.organization" | jq '(.included.spaces | INDEX(.guid)) as $spaces | (.included.organizations | INDEX(.guid)) as $orgs | [ .resources[] | select(.lifecycle.data.stack == "cflinuxfs3") | {app: .name, org:$orgs[$spaces[.relationships.space.data.guid].relationships.organization.data.guid].name ,space: $spaces[.relationships.space.data.guid].name , lifecycle} ]'
+```
+
+
+(Note of thanks to the folks at SAP who created that command at [https://blogs.sap.com/2023/02/16/deprecation-of-cloud-foundry-stack-cflinuxfs3-and-migration-to-cflinuxfs4/](https://blogs.sap.com/2023/02/16/deprecation-of-cloud-foundry-stack-cflinuxfs3-and-migration-to-cflinuxfs4/) )
+
+
+
+### Timeline
+
+| When | What | Available Stacks | Default Stack |
+| ----------------|-------------|------------------|---------------|
+| **March 23** | Roll out all cflinuxfs4 buildpacks | cflinuxfs3, cflinuxfs4 | cflinuxfs3
+| **March 23 - April 27** | Developers test and update apps to use cflinuxfs4 | cflinuxfs3, cflinuxfs4 | cflinuxfs3
+| **April 27** | Support ends for cflinuxfs3. All new apps pushed will use cflinuxfs4 by default, existing apps will need to be migrated. | cflinuxfs3, cflinuxfs4 | **cflinuxfs4**
+| **April 27 - June 29** | Explicitly opt to use cflinuxfs3 if you need more time | cflinuxfs3, cflinuxfs4 | **cflinuxfs4**
+| **June 29** | cflinuxfs3 buildpacks will be retired from the platform, apps needing cflinuxfs3 buildpacks will need to reference them via URL on the cf push | cflinuxfs3, cflinuxfs4 | **cflinuxfs4**
+| **Sept 28** | Only cflinuxfs4 will be available, this is a breaking change for apps not updated to use cflinuxfs4 | cflinuxfs4 | **cflinuxfs4**
+
+
+
+### Platform Buildpacks
+
+| Buildpack Name | Version | Exists for Both Stacks |
+|----------------|---------|--------|
+| staticfile_buildpack | v1.6.0 | Yes
+| java_buildpack | v4.54 | Yes
+| ruby_buildpack | v1.9.3 | Yes
+| dotnet_core_buildpack | v2.4.8 | Yes
+| nodejs_buildpack | v1.8.7 | Yes
+| go_buildpack | v1.10.6 | Yes
+| python_buildpack | v1.8.8 | Yes
+| php_buildpack | v4.6.1 | Yes
+| binary_buildpack | v1.1.3 | Yes
+| nginx_buildpack | v1.2.1 | Yes
+| r_buildpack | v1.2.0 | Yes
+
diff --git a/content/news/articles/2023-04-19-opensearch-maintenance.md b/content/news/articles/2023-04-19-opensearch-maintenance.md
new file mode 100644
index 0000000..9b986de
--- /dev/null
+++ b/content/news/articles/2023-04-19-opensearch-maintenance.md
@@ -0,0 +1,29 @@
+---
+layout: layouts/post
+tags: news
+date: 2023-04-19
+title: "Off-peak windows now defined for all brokered Elasticsearch/Opensearch domains"
+excerpt: We have configured off-peak windows for software updates on all brokered Elasticsearch/Opensearch domains to minimize service disruption.
+---
+
+## Background
+
+[Periodically, AWS pushes out required software updates for Elasticsearch/Opensearch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/service-software.html). While these updates are applied using a blue/green deployment to minimize disruption, it is still possible for customers to experience partial downtime or outages for their domains during the upgrade.
+
+To give customers more control over when updates are applied to their domains, [in February 2023 AWS released a new feature for Elasticsearch/Opensearch domains called off-peak windows](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/off-peak.html). Off-peak windows are a daily 10-hour block of time defined by customers to control when software updates can be scheduled.
+
+While AWS automatically enables and defines off-peak windows for domains **created after February 16 2023**, any domains created before this date do not have off-peak windows defined.
+
+## What we did
+
+[To give all of our customers the benefit of off-peak windows, **the cloud.gov team enabled off-peak windows for any domains where they were not already enabled**](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/off-peak.html#off-peak-enable). A default off-peak window of `00:00 UTC - 10:00 UTC` was applied to these domains.
+
+**All Elasticsearch/Opensearch domains managed by cloud.gov now have off-peak windows enabled.**
+
+Furthermore, for many of the domains which had newly created off-peak windows, there were already pending updates scheduled for outside the off-peak window. So the cloud.gov team also **rescheduled all pending updates to occur within the off-peak window**.
+
+## Conclusion
+
+As part of fulfilling our mission to deliver secure, scalable cloud services to our customers, we hope that enabling off-peak windows will minimize Elasticsearch/Opensearch service disruptions from software updates.
+
+If you have any questions about these changes, don't hesitate to contact us at [support@cloud.gov](mailto:support@cloud.gov).
diff --git a/content/news/articles/2023-04-27-cflinuxfs3-deprecation-update.md b/content/news/articles/2023-04-27-cflinuxfs3-deprecation-update.md
new file mode 100644
index 0000000..d450701
--- /dev/null
+++ b/content/news/articles/2023-04-27-cflinuxfs3-deprecation-update.md
@@ -0,0 +1,63 @@
+---
+layout: layouts/post
+tags: news
+date: 2023-04-27
+title: "Upgrading App to cflinuxfs4 Important Update"
+excerpt: Ubuntu 22.04 stack (cflinuxfs4) buildpacks are here and you likely need to upgrade your existing apps to use the new stack!
+---
+
+# Deprecation of cflinuxfs3
+
+## Ubuntu 22.04 stack (cflinuxfs4) buildpacks are here and Ubuntu 18.04 (cflinuxfs3) are retiring: upgrade your apps now!
+
+
+The base OS image used by your cloud.gov applications is called a "stack". The stack we’ve provided to date is called `cflinuxfs3`, and it’s based on Ubuntu 18.04 LTS, released originally in mid 2018 with continuous security updates since then. `cflinuxfs4` is a new OS image based on Ubuntu 22.04 LTS, and is now default stack in cloud.gov. Ubuntu 18.04 will likely no longer receive security updates in May, so we will stop supporting cflinuxfs3 in cloud.gov May 10th.
+
+### Who is impacted?
+
+If you push your Cloud Foundry applications as Docker containers with `cf push --docker-image `, these changes do not impact you.
+
+However, most cloud.gov customers deploy their applications using buildpacks, and their apps don’t have any dependency on the particular OS version that runs them. If that describes you and you have existing applications running on cloud.gov, this upgrade will impact you and you'll need to update the stack on your applications.
+
+
+### What should you do now for existing apps?
+
+
+For existing applications which were created under `cflinuxfs3` you will need to update the stack declaration to `cflinuxfs4`, there are two common ways of doing this detailed below. The options below only have to be run once for each application on `cflinuxfs3`, once the stack is set for an application, it is persistent until changed with any of these two steps.
+
+1. Push the app manually and specify the stack with the cf cli:
+
+ ```shell
+ cf push MY-APP -s cflinuxfs4
+ ```
+
+2. Use the `stack-auditor` cf cli plugin to change the stack without having to push the application. Documentation for using this plugin is at [https://docs.cloudfoundry.org/adminguide/stack-auditor.html#change-stacks](https://docs.cloudfoundry.org/adminguide/stack-auditor.html#change-stacks), the basic workflow is:
+
+ - Install the plugin
+ - Use the `cf` cli to target the org and space for your existing application
+ - Run `cf change-stack APP-NAME cflinuxfs4` to change the app to the `cflinuxfs4` stack
+
+ Each application will take about a minute or so to run the `cf change-stack...` command depending on the size of the droplet.
+
+
+### What should you do now for new apps?
+
+For any new applications, simply run a `cf push` to pick up the new `cflinuxfs4` stack:
+
+```shell
+cf push MY-APP
+```
+
+
+
+### Timeline
+
+| When | What | Available Stacks | Default Stack |
+| ----------------|-------------|------------------|---------------|
+| **March 23** | Roll out all cflinuxfs4 buildpacks | cflinuxfs3, cflinuxfs4 | cflinuxfs3
+| **March 23 - April 27** | Developers test and update apps to use cflinuxfs4 | cflinuxfs3, cflinuxfs4 | cflinuxfs3
+| **April 27** | Support ends for cflinuxfs3. All new apps pushed will use cflinuxfs4 by default, existing apps will need to be migrated. | cflinuxfs3, cflinuxfs4 | **cflinuxfs4**
+| **April 27 - June 29** | Explicitly opt to use cflinuxfs3 if you need more time | cflinuxfs3, cflinuxfs4 | **cflinuxfs4**
+| **June 29** | cflinuxfs3 buildpacks will be retired from the platform, apps needing cflinuxfs3 buildpacks will need to reference them via URL on the cf push | cflinuxfs3, cflinuxfs4 | **cflinuxfs4**
+| **Sept 28** | Only cflinuxfs4 will be available, this is a breaking change for apps not updated to use cflinuxfs4 | cflinuxfs4 | **cflinuxfs4**
+
diff --git a/content/news/articles/2023-05-01-release-notes.md b/content/news/articles/2023-05-01-release-notes.md
new file mode 100644
index 0000000..10e9cab
--- /dev/null
+++ b/content/news/articles/2023-05-01-release-notes.md
@@ -0,0 +1,195 @@
+---
+layout: layouts/post
+tags: news
+date: 2023-05-01
+title: "May 1st cloud.gov Change Log"
+excerpt: The cloud.gov team is working on providing change logs so everyone can see new features and updates.
+---
+
+# Change Log
+
+## Customer Facing Changes
+---
+
+### `cflinuxfs3` Retirement
+
+`cflinuxfs4` is now the default for all new applications. For existing applications, app maintainers should use `cf push APP_NAME -s cflinuxfs4` or the CF Stack Auditor plugin. Additional details can be found at [https://cloud.gov/2023/04/27/cflinuxfs3-deprecation-update/](https://cloud.gov/2023/04/27/cflinuxfs3-deprecation-update/)
+
+### Binary Buildpack - v1.1.4 up from v1.1.3
+* Update libbuildpack
+ * Uncached buildpack SHA256: bd2bb05de690ef0cbe6efbf9e1c66b6085dc8efa3ebc186d7202b9e9d54ebd28
+ * Uncached buildpack SHA256: 988d1392de4cffbe26d2be4e9a4487a26f7b16b1b5a27fba98e07266d1883562
+ * Uncached buildpack SHA256: c8689ae3a2b3471f16fbdcac65581690bf9aa5f0d8103cb20d00d93f74837e6e
+ * Uncached buildpack SHA256: 97d7643f51d1b9a7f64d3135d264b03168a5e644f7b31531351f94a951d7a4f5
+
+* tests: replace ruby webserver with a simple netcat program, cflinuxfs4 1.x does not come with ruby on the stack
+
+
+### CFLinuxfs3 - 0.362.0 up from 0.356.0
+* USN-6028-1 USN-6028-1: libxml2 vulnerabilities
+* USN-6005-1 USN-6005-1: Sudo vulnerabilities
+* USN-5995-1 USN-5995-1: Vim vulnerabilities
+* USN-5964-1 USN-5964-1: curl vulnerabilities
+* USN-5963-1 USN-5963-1: Vim vulnerabilities
+* USN-5960-1 USN-5960-1: Python vulnerability:
+* USN-5952-1 USN-5952-1: OpenJPEG vulnerabilities
+* USN-5928-1 USN-5928-1: systemd vulnerabilities
+
+
+
+### CFLinuxfs4 - 1.5.0 up from 0.72.0
+
+This release removes Ruby and Python from the stack. These dependencies were previously installed to support the PHP and Java buildpacks which are written in those languages. Those buildpacks have now been released with versions that bring their own Ruby or Python dependency and therefore these are now being removed from the stack.
+
+* USN-6005-1 USN-6005-1: Sudo vulnerabilities
+* USN-5995-1 USN-5995-1: Vim vulnerabilities
+* USN-5855-3 USN-5855-3: ImageMagick regression
+* USN-5964-1 USN-5964-1: curl vulnerabilities
+* USN-5963-1 USN-5963-1: Vim vulnerabilities
+* USN-5960-1 USN-5960-1: Python vulnerability
+* USN-5855-2 USN-5855-2: ImageMagick vulnerabilities
+* USN-5928-1 USN-5928-1: systemd vulnerabilities
+
+
+### Dotnet-Core-Buildpack - 2.4.10 up from 2.4.8
+
+* Update libbuildpack
+* Bump github.com/onsi/gomega from 1.27.2 to 1.27.6
+* Bumps github.com/onsi/gomega from 1.27.2 to 1.27.6.
+* Add node 18.15.0, remove node 18.14.2 (#755) for stack(s) cflinuxfs4, cflinuxfs3
+* Add dotnet-aspnetcore 6.0.15, remove dotnet-aspnetcore 6.0.14 (#763) for stack(s) cflinuxfs4, cflinuxfs3
+* Add dotnet-runtime 6.0.15, remove dotnet-runtime 6.0.14 (#762) for stack(s) cflinuxfs4, cflinuxfs3
+* Add dotnet-sdk 6.0.407, remove dotnet-sdk 6.0.406 (#761) for stack(s) cflinuxfs4, cflinuxfs3
+* Add dotnet-sdk 7.0.202, remove dotnet-sdk 7.0.200 (#760) (#750) for stack(s) cflinuxfs4, cflinuxfs3
+* Add dotnet-aspnetcore 7.0.4, remove dotnet-aspnetcore 7.0.3 (#759) for stack(s) cflinuxfs4, cflinuxfs3
+* Add dotnet-runtime 7.0.4, remove dotnet-runtime 7.0.3 (#758) for stack(s) cflinuxfs4, cflinuxfs3
+
+### Go-Buildpack 1.10.8 up from 1.10.6
+* Bump github.com/cloudfoundry/switchblade from 0.2.0 to 0.3.0
+* Add go 1.19.8, remove go 1.19.6 for stack(s) cflinuxfs4, cflinuxfs3
+* Add go 1.20.3, remove go 1.20.1 for stack(s) cflinuxfs3, cflinuxfs4
+* Bump libbuildpack to pull in retry with exponential backoff.
+* Deprecate go1.18
+
+### Java-Buildpack 4.57 up from 4.56
+* This release fixes a bug with the Container Security Provider library, in which a race condition could result in mismatched private-key and certificate pairs when Diego rotated these credentials for the container. [See this issue for more details](https://github.com/cloudfoundry/java-buildpack-security-provider/issues/8).
+* This release also contains the following:
+ * The Azul Zing JRE contained a bug when generating the Java Opts, fixed with #1008 (thanks to @schelini)
+ * Update to the geode_store dependency (thanks to @BenjaminPerryRoss)
+For a more detailed look at the changes in 4.57, please take a look at the [commit log](https://github.com/cloudfoundry/java-buildpack/compare/v4.56...v4.57). The packaged version of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to this release.
+
+
+### Nginx-Buildpack 1.2.2 up from 1.2.1
+* Add nginx 1.23.4, remove nginx 1.23.3 for stack(s) cflinuxfs3, cflinuxfs4 (https://www.pivotaltracker.com/story/show/184817118)
+* Update libbuildpack
+* Bump github.com/miekg/dns from 1.1.52 to 1.1.53
+* Bump github.com/onsi/gomega from 1.26.0 to 1.27.5
+
+### NodeJS Buildpack v1.8.9 up from v1.8.6
+* Add node 16.20.0, remove node 16.19.0 for stack(s) cflinuxfs4, cflinuxfs3
+* Don't run yarn check which creates a duplicate cache. Instead, we can add the --check-files flag to the yarn install command and get the same outcome.
+* Bring our own Python for node-gyp
+* Add node 18.15.0, remove node 18.13.0 for stack(s) cflinuxfs4, cflinuxfs3
+* Uncached buildpack SHA256: adde57eaf1aa543c2a12565a0a211dfddb8d591333d47ab0eeb744f1afe6ced3
+* Uncached buildpack SHA256: c964c655974ec1e5b85d88d317372f9fd2276727538a175d5067c040f89c480c
+
+
+
+### PHP buildpack v4.6.4 up from v4.6.0
+* update go modules
+* bump default nginx version
+* Add nginx 1.23.4, remove nginx 1.23.3 (#857) for stack(s) cflinuxfs4, cflinuxfs3
+* Install bootstrapped Ruby into php-buildpack specific location (#855)
+* Add composer 2.5.5, remove composer 2.5.4 for stack(s) cflinuxfs4, cflinuxfs3
+* BYO Ruby (Required by the buildpack)
+* Add httpd 2.4.56, remove httpd 2.4.55 (#845) for stack(s) cflinuxfs3, cflinuxfs4 (https://www.pivotaltracker.com/story/show/184641061)
+
+
+### Python buildpack v1.8.9 up from v1.8.8
+* Add python 3.10.11, remove python 3.10.10 for stack(s) cflinuxfs3, cflinuxfs4
+* Add python 3.11.3, remove python 3.11.2 for stack(s) cflinuxfs4, cflinuxfs3
+* Add setuptools 67.6.1, remove setuptools 67.4.0 for stack(s) cflinuxfs4, cflinuxfs3
+* Add pipenv 2023.3.20, remove pipenv 2023.2.18 for stack(s) cflinuxfs4, cflinuxfs3
+* Fix problem with AppDynamics hook (now it supports user-provided services)
+
+### R buildpack v1.2.1 up from v1.2.0
+* Update libbuildpack
+
+### Ruby buildpack v1.10.1 up from v1.9.4
+* Add bundler 2.4.11, remove bundler 2.4.10 for stack(s) cflinuxfs4, cflinuxfs3 (#784)
+* Add rubygems 3.4.11, remove rubygems 3.4.10 for stack(s) cflinuxfs4, cflinuxfs3 (#783)
+* Add ruby 3.1.4, remove ruby 3.1.2 for stack(s) cflinuxfs4, cflinuxfs3 (#782)
+* Add ruby 3.2.2, remove ruby 3.2.0 for stack(s) cflinuxfs4, cflinuxfs3 (#776)
+* Add ruby 3.0.6, remove ruby 3.0.4 for stack(s) cflinuxfs3 (#775)
+* Remove support for Ruby 2.7 (#773)
+* Bump github.com/onsi/gomega from 1.27.4 to 1.27.5 (#768)
+* Add rubygems 3.4.10, remove rubygems 3.4.8 (#769) for stack(s) cflinuxfs4, cflinuxfs3
+* Add bundler 2.4.10, remove bundler 2.4.8 (#770) for stack(s) cflinuxfs4, cflinuxfs3
+
+
+### Staticfile buildpack v1.6.2 up from v1.6.1
+* Add nginx 1.23.4, remove nginx 1.23.3 for stack(s) cflinuxfs3, cflinuxfs4 (https://www.pivotaltracker.com/story/show/184817130)
+* Update libbuildpack
+* Bump github.com/onsi/gomega from 1.27.5 to 1.27.6
+
+
+## Platform Changes
+---
+
+### CAPI - v1.150.0 up from v1.480.0
+
+* CC API Version: 2.201.0 and 3.136.0
+* CAPI Release
+ * Bump Ruby to 3.2.2
+ * Ensure Post Backup Unlock always restarts local workers #289
+ * Use bosh link for cloud_controller_worker stacks #299
+* Dependency Bumps
+ * Bump Ruby to 3.2.2
+ * bump rubocop from 1.48.1 to 1.49.0 in /spec
+ * bump Golang to go1.20.3
+* Cloud Controller
+ * Add generic Korifi error cloudfoundry/cloud_controller_ng#3205
+ * Add db indexes for better performance cloudfoundry/cloud_controller_ng#3108
+
+
+
+### Garden-Runc 1.27.0 up from 1.25.0
+* Bump ginkgo to v2 and lager to v3
+* Built with go 1.20.3
+* Bump runc version to 1.1.4
+* Bump containerd version to 1.6.19
+
+### Log-Cache 3.0.1 up from 3.0.0
+* Bump dependencies
+
+
+### Loggregator 107.0.3 up from 107.0.2
+* Upgrade to go 1.20.2
+* Bump dependencies
+* Remove unused metron_endpoint.dropsonde_port property in #534
+
+### Loggregator-Agent 7.2.0 up from 7.1.0
+* Bump golang.org/x/net from 0.8.0 to 0.9.0 in /src by @dependabot in #283
+* Add mtls options to aggregate drains. by @Benjamintf1 in #276
+* switch gorilla with chi by @Benjamintf1 in #285
+* Upgrade to go 1.20.2
+
+### Node-exporter 5.1.0 up from 5.0.0
+* bump Node-Exporter to v1.5.0
+* Deprecate node_exporter.collector.filesystem.ignored_mount_points in favor of node_exporter.collector.filesystem.mount_points_exclude
+* Deprecate node_exporter.collector.filesystem.ignored_fs_types in favor of node_exporter.collector.filesystem.fs_types_exclude
+
+### UAA 76.10.0 up from 76.8.0
+* Features
+ * Bump to UAA v76.10.0
+ * add support for TLSv1.3 by @adam-jian-zhang in #539
+ * Add 2 new options signingAlg and signingCert to JWT token policy.
+* Dependency bumps
+ * Upgrade Newrelic to version 8.1.0
+ * Upgrade Tomcat to version 9.0.74
+ * Upgrade Bellsoft JDK to version 11.0.19+7
+ * Bump github.com/cloudfoundry/bosh-utils from 0.0.360 to 0.0.361 in /src/acceptance_tests by @dependabot in #564
+ * Bump rspec-core from 3.12.1 to 3.12.2 by @dependabot in #567
+ * Bump rspec-expectations from 3.12.2 to 3.12.3 by @dependabot in #568
+
+
diff --git a/content/news/articles/2023-05-16-cflinuxfs3-buildpack-deprecation.md b/content/news/articles/2023-05-16-cflinuxfs3-buildpack-deprecation.md
new file mode 100644
index 0000000..034234e
--- /dev/null
+++ b/content/news/articles/2023-05-16-cflinuxfs3-buildpack-deprecation.md
@@ -0,0 +1,70 @@
+---
+layout: layouts/post
+tags: news
+date: 2023-05-16
+title: "Deprecation Notice for cflinuxfs3 stack and cflinuxfs3 Buildpacks"
+excerpt: cflinuxfs4 buildpacks are here and cflinuxfs3 buildpacks are retiring, upgrade your apps now!
+---
+
+
+
+# Deprecation Notice for cflinuxfs3 stack and cflinuxfs3 Buildpacks
+
+
+The base OS image used by your cloud.gov applications is called a "stack". The stack we’ve provided to date is called `cflinuxfs3`, and it’s based on Ubuntu 18.04 LTS, released originally in mid 2018 with continuous security updates since then. `cflinuxfs4` is a new OS image based on Ubuntu 22.04 LTS, and is now default stack in cloud.gov.
+
+### Important Dates
+Ubuntu 18.04 will likely no longer receive security updates in May, so we will stop supporting the cflinuxfs3 stack and buildpacks in cloud.gov. What this means is:
+
+ - On **June 29th, 2023** the platform will no longer provide cflinuxfs3 buildpacks. Applications will need to reference an external buildpack to continue to push updated versions of cflinuxfs3 applications. Existing cflinuxfs3 applications will continue to restart without intervention.
+ - On **September 28th, 2023**, all support for cflinuxfs3 will end and all applications still on this stack will stop and cannot be started unless migrated to cflinuxfs4.
+
+
+Ubuntu 18.04 will likely no longer receive security updates in May, so we will stop supporting cflinuxfs3 in cloud.gov May 10th.
+
+### Who is impacted?
+
+If you push your Cloud Foundry applications as Docker containers with `cf push --docker-image `, these changes do not impact you.
+
+However, most cloud.gov customers deploy their applications using buildpacks, and their apps don’t have any dependency on the particular OS version that runs them. If that describes you and you have existing applications running on cloud.gov, this upgrade will impact you and you'll need to update the stack on your applications.
+
+
+### What should you do now for existing apps?
+
+
+For existing applications which were created under `cflinuxfs3` you will need to update the stack declaration to `cflinuxfs4`, there are two common ways of doing this detailed below. The options below only have to be run once for each application on `cflinuxfs3`, once the stack is set for an application, it is persistent until changed with any of these two steps.
+
+1. Push the app manually and specify the stack with the cf cli:
+
+ ```shell
+ cf push MY-APP -s cflinuxfs4
+ ```
+
+2. Use the `stack-auditor` cf cli plugin to change the stack without having to push the application. Documentation for using this plugin is at [https://docs.cloudfoundry.org/adminguide/stack-auditor.html#change-stacks](https://docs.cloudfoundry.org/adminguide/stack-auditor.html#change-stacks), the basic workflow is:
+
+ - Install the plugin
+ - Use the `cf` cli to target the org and space for your existing application
+ - Run `cf change-stack APP-NAME cflinuxfs4` to change the app to the `cflinuxfs4` stack
+
+ Each application will take about a minute or so to run the `cf change-stack...` command depending on the size of the droplet.
+
+
+### What should you do now for new apps?
+
+For any new applications, simply run a `cf push` to pick up the new `cflinuxfs4` stack:
+
+```shell
+cf push MY-APP
+```
+
+### How do you push a cflinuxfs3 app with an external buildpack?
+
+Until September 28th, 2023, you can use an external buildpack to push apps to the cflinuxfs3 stack by referencing a URL in a `cf push` command. As an example, to push a Ruby app using 2.7.6 on cflinuxfs3:
+
+```shell
+cf push MY-APP -b https://github.com/cloudfoundry/ruby-buildpack/releases/download/v1.9.4/ruby-buildpack-cflinuxfs3-v1.9.4.zip -s cflinuxfs3
+```
+
+Many of the external buildpacks can be found on Github at [https://github.com/cloudfoundry?q=buildpacks&type=all&language=&sort=](https://github.com/cloudfoundry?q=buildpacks&type=all&language=&sort=)
+
+
diff --git a/content/news/articles/2023-05-30-cloud-gov-pages-jekyll-ruby-upgrade.md b/content/news/articles/2023-05-30-cloud-gov-pages-jekyll-ruby-upgrade.md
new file mode 100644
index 0000000..2bae558
--- /dev/null
+++ b/content/news/articles/2023-05-30-cloud-gov-pages-jekyll-ruby-upgrade.md
@@ -0,0 +1,55 @@
+---
+layout: layouts/post
+tags: news
+title: Upgrading a Jekyll site to Ruby 3.1
+date: 2023-05-24
+excerpt: "Ruby 2.7 has reached “end of life” so we’re providing instructions on how to upgrade your Jekyll site to use Ruby 3.1. Cloud.gov Pages will continue supporting Ruby 2.7 builds for six months, but then only Ruby 3 versions will be supported."
+---
+
+Ruby 2.7 has reached “end of life” so we’re providing instructions on how to upgrade your Jekyll site to use Ruby 3.1. Cloud.gov Pages will continue supporting Ruby 2.7 builds for six months, but then only Ruby 3 versions will be supported.
+
+The main difficulty with upgrading a site to use a newer version of Ruby is that one or more of your required Gems could break when changing Ruby versions. This is notably the case for `jekyll-assets`. If you don’t have that dependency, this could be a relatively straightforward upgrade. We recently upgraded our own [Jekyll template repo](https://github.com/cloud-gov/pages-uswds-jekyll) which you can check out for reference.
+
+## Instructions for sites without jekyll-assets
+
+If you don’t see `jekyll-assets` in your `Gemfile` or `Gemfile.lock`, you don’t have a dependency on `jekyll-assets` and you might be able to upgrade to Ruby 3.1 with just a few steps:
+- Create a file called `.ruby-version` in your site folder which contains the string `3.1`. If you already have this file, you can replace the previous version with `3.1`
+- If you have any other site-specific scripts which specify the ruby version, update these as well.
+- Add or change your specified Ruby version (e.g. `ruby '~> 3.1'`).Delete your previous `Gemfile.lock` and regenerate by running `bundle install`
+ - If this command adds a new `PLATFORM` to your `Gemfile.lock`, and it’s anything other than `ruby`, remove it with the following command:
+ - `bundle lock --remove-platform example_platform_name`. For example `bundle lock --remove-platform arm64-darwin-21`
+- Commit and push all these changes to see if the cloud.gov Pages build succeeds!
+
+## Instructions for sites with jekyll-assets
+
+Jekyll Assets is a helpful gem for compiling SASS, JS, and image files into your final jekyll build. Unfortunately it is unmaintained and hasn’t been updated in three years. It also doesn’t support Ruby 3. So if you remove it, you’ll need alternative ways to make sure your SASS, JS, and image files are included in your site build correctly.
+We’ve documented the migration process in a [PR to our deprecated jekyll template](https://github.com/cloud-gov/pages-uswds-jekyll/pull/314) and included the main steps below. Your site may have specific customizations which make some of these steps not applicable.
+- Create a file called `.ruby-version` in your site folder which contains the string `3.1`. If you already have this file, you can replace the previous version with `3.1`.
+- If you have any other site-specific scripts which specify the ruby version, update these as well.
+- Remove `jekyll-assets` from your `Gemfile`. Add or change your specified Ruby version (e.g. `ruby '~> 3.1'`). Delete your previous `Gemfile.lock` and regenerate by running `bundle install`
+ - If this command adds a new `PLATFORM` to your `Gemfile.lock`, and it’s anything other than `ruby`, remove it with the following command:
+ - `bundle lock --remove-platform example_platform_name`. For example `bundle lock --remove-platform arm64-darwin-21`
+ - You may need to add `ruby` as a platform, as `bundle` now requires at least one platform, using `bundle lock --add-platform ruby`
+
+- [The hard step] Replace the primary functionality of jekyll-assets:
+ - First move everything from the `_assets` folder to the `assets` folder
+ - Remove any uses of the {% raw %}`{% asset %}`{% endraw %} liquid tag or `asset_url` function in your content. This tag and function provided a way to find a given asset in any of multiple specified site folders. You’ll likely want to replace this with {% raw %} `{{site.baseurl}}/img/example.png` or `{{ /assets/example.png | relative_url }}`{% endraw %} where `example.png` is the name of the example file.
+ - Move all SASS partials to a new folder called `_sass`. You can leave the entrypoint SASS file (styles.scss) in `assets/css` but you’ll need to add [two sets of triple dashes to the start of the file](https://jekyllrb.com/docs/assets/).
+ - Add our two helper jekyll plugins to the `_plugins` folder:
+ - [`asset-helper.rb`](https://github.com/cloud-gov/pages-uswds-jekyll/blob/main/_plugins/asset-helper.rb) copies USWDS assets from the `node_modules` folder into your `assets` folder
+ - [`autoprefixer.rb`](https://github.com/cloud-gov/pages-uswds-jekyll/blob/main/_plugins/autoprefixer.rb) roughly recreates the functionality of `jekyll-autoprefixer` and adds vendor prefixes to CSS rules
+ - You’ll need to update `_config.yml` to reflect passing configuration options to our new plugins instead of `jekyll-assets`. You can see an [example configuration change in our template PR](https://github.com/cloud-gov/pages-uswds-jekyll/pull/314/files#diff-ecec67b0e1d7e17a83587c6d27b6baaaa133f42482b07bd3685c77f34b62d883).
+ - Add a new empty file called `.gitkeep` in `assets/uswds` and then add these three lines to `.gitignore` to ignore temporary USWDS assets during the build:
+
+ ```shell
+ assets/uswds/*
+ !assets/uswds/.gitkeep
+ assets/js/uswds*
+ ```
+ - There are a few css variables you might need to change:
+ - [`theme-font-path` and `theme-image-path`](https://github.com/cloud-gov/pages-uswds-jekyll/pull/314/files#diff-9c2164c6dbe14003458901df1f193e2ac22a958d6fef21a16a439cda577945b9L20-L22)
+ - [`theme-hero-image`](https://github.com/cloud-gov/pages-uswds-jekyll/pull/314/files#diff-e2364fbc077a3a2cae9a0614a089904cff29c043b49ed1627690eebfa6a88522R99)
+
+ Note that these upgrades will temporarily make your site builds slower (but more secure!). We're working on an alternative build container which uses Ruby 3.1 as its default. Please reach out to us at [pages-support@cloud.gov](mailto:pages-support@cloud.gov) with any questions about this process.
+
+
diff --git a/content/news/articles/2023-06-01-compliance-office-hours.md b/content/news/articles/2023-06-01-compliance-office-hours.md
new file mode 100644
index 0000000..f3e897c
--- /dev/null
+++ b/content/news/articles/2023-06-01-compliance-office-hours.md
@@ -0,0 +1,11 @@
+---
+layout: layouts/post
+tags: news
+title: Announcing Compliance Office Hours
+date: 2023-06-01
+excerpt: "Cloud.gov will dedicate the last office hours meeting of every month to compliance-related questions starting June 27."
+---
+
+Cloud.gov holds a weekly Office Hours meeting every Tuesday at 3pm ET for customers to ask questions and share their experiences on the platform. Starting this June, the last Tuesday of the month will be focused on security and compliance. Members of the cloud.gov Compliance team will be in attendance to answer your questions and hear your feedback.
+
+The link to join Office Hours is published in the cloud.gov monthly newsletter. To join the newsletter mailing list or be added directly to the Office Hours meeting, please contact inquiries@cloud.gov. We hope to see you there!
diff --git a/content/news/articles/2023-06-05-aws-ending-support-mysql-57.md b/content/news/articles/2023-06-05-aws-ending-support-mysql-57.md
new file mode 100644
index 0000000..b29d767
--- /dev/null
+++ b/content/news/articles/2023-06-05-aws-ending-support-mysql-57.md
@@ -0,0 +1,89 @@
+---
+layout: layouts/post
+tags: news
+title: Upgrade your databases - AWS ending support for MySQL 5.7 in January/February 2024.
+date: 2023-06-05
+excerpt: "AWS is ending support for MySQL 5.7 databases starting in January/February 2024. Read on for instructions for how to upgrade your brokered databases."
+---
+
+[AWS RDS is ending support for MySQL versions 5.7.x starting in January/February 2024](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Concepts.VersionMgmt.html).
+
+> **Please note:** AWS has updated the end of support for MySQL 5.7 databases to January/February 2024. A previous version of this post said that support for MySQL 5.7 was ending December 2023.
+
+## What this means for you
+
+As a cloud.gov customer, if you are running a MySQL 5.7 database, then you will need to upgrade that database to at least MySQL version 8.0 by January/February 2024. **Affected customers will receive direct outreach from the cloud.gov team.**
+
+To upgrade your database from MySQL 5.7 to 8.0, see the [guidance below](#how-to-upgrade).
+
+If you do not upgrade your database by January/February 2024, then AWS will automatically upgrade your database to the next supported major version (currently 8.0) during the next maintenance window for your database.
+
+## Important dates
+
+|When|What|
+|-|-|
+| **June 5, 2023** | MySQL 5.7 databases can no longer be created on cloud.gov |
+| **June 5 2023 - January/February 2024** | Window for customers to self-upgrade their MySQL databases to 8.0 |
+| **January/February 2024** | MySQL 5.7 databases are fully deprecated by AWS. Any remaining databases are auto-upgraded to the next supported major version. |
+
+## Updates to brokered database plans
+
+As of today, June 5, 2023, it is no longer possible to create an RDS database using MySQL version 5.7 for any of the `mysql` plans in the marketplace. By default, version "8.0" will be used for new MySQL databases.
+
+You can find more information about creating/updating RDS databases on [our database services documentation](({{ site.baseurl }}/docs/services/relational-database)).
+
+## How to upgrade
+
+To upgrade your existing MySQL 5.7 database to MySQL 8.0:
+
+1. Target your organization and space:
+
+ ```shell
+ cf target -o