What's New?​

Starting today, you can use your PIV/CAC card to authenticate through Login.gov when accessing Cloud.gov. Creating a Login.gov account is quick and easy, afterwards just your PIV/CAC card and you're ready to go.

Key Benefits​

Enhanced Security​

Login.gov authentication requires PIV/CAC, providing strong, phishing-resistant authentication that aligns with federal zero-trust security standards.

Simplified Access​

No need to remember another password or manage separate credentials. Your PIV/CAC is all you need.

Automatic Migration​

If you currently use Cloud.gov authentication, we'll automatically transfer your permissions when you first log in with Login.gov.

How Automatic Migration Works​

When you log in with Login.gov for the first time, our system will:

1. Detect if you have an existing Cloud.gov account with the same email address
2. Copy all your organization roles, space roles, and organization memberships to your new Login.gov account
3. Remove your old Cloud.gov account to prevent confusion
4. Preserve all your access and permissions seamlessly

Example: If you currently use Cloud.gov authentication with john.doe@my-agency.gov and log in with Login.gov using the same email address, all your roles will be automatically transferred.

Important: After migration, you'll need to log out and log back in to see your copied roles and permissions.

Who Is Impacted?​

✅ Action Required​

Users who currently select "Cloud.gov" under the "Agency Credentials" section of the login page.

✔️ No Action Needed​

If you already use your agency login (such as GSA, EPA, or FDIC), this change doesn't affect you. Continue using your existing authentication method.

Migration Eligibility​

🟢 Automatic Migration Available​

• Your Cloud.gov account email matches your Login.gov email address

🟡 Contact Support for Manual Migration​

• Email addresses don't match (including pif.gov and cio.gov accounts)

🔴 Cannot Be Migrated​

• Users without PIV/CAC cards

Already Have a Login.gov Account?​

Great! You're all set. When logging into Cloud.gov:

• PIV/CAC is the only MFA method allowed
• You won't need your Login.gov username or password
• Multiple email addresses are supported, to change which one is used review the additional documentation on Login.gov
• Just insert your PIV/CAC and authenticate

Don't have a Login.gov account yet? No problem! One will be created automatically when you first authenticate with your PIV/CAC.

Getting Started​

Ready to try Login.gov authentication? It's simple:

1. Navigate to https://login.fr.cloud.gov
2. Click "Sign in with Login.gov"
3. Insert your PIV/CAC and follow the prompts
4. That's it!

Need Help?​

If you have questions or need assistance with migration:

• Review our Login.gov authentication documentation
• Contact Cloud.gov support at support@cloud.gov
• For manual migration requests, include both your Cloud.gov and PIV/CAC email addresses

Looking Ahead​

This Login.gov integration is part of our ongoing commitment to improving security and user experience. In the future, we plan to deprecate the legacy Cloud.gov authentication option, but we'll provide plenty of notice and support throughout that transition.

On August 4th visual changes to the main login page will be made which will highlight the addition of Login.gov.

Start using Login.gov authentication today and experience the simplicity of PIV/CAC-based access to Cloud.gov!

Questions? Reach out to our support team or visit our documentation for more details about the Login.gov integration.

What is Falco?​

Falco is an open-source, cloud native security tool that detects real-time, anomalous behavior in running containers. Falco identifies potential security threats and abnormal activities. At its core, Falco is a monitoring and detection agent that observes events (such as Linux kernel events) and delivers real-time alerts based on custom rules. These custom rules are inherited from the Falco upstream, and maintained by the Cloud.gov Platform team. Falco helps Cloud.gov proactively defend systems, maintain compliance, and strengthen overall security posture. More details are available here: https://falco.org/.

Falco Integration in Cloud.gov​

Falco is installed on all host VMs running your applications. It monitors and evaluates kernel events against an established rule set. Findings based on these rules are displayed in OpenSearch.

Because Falco is integrated at the platform level, you do not need to take any action or change your applications to enable Falco.

What Types of Events Does Falco Monitor?​

Falco contains an extensive default rule set that looks for events including but not limited to:

• Privilege escalation using privileged containers
• Namespace changes using tools like setns
• Read/Writes to well-known directories such as /etc, /usr/bin, /usr/sbin, etc

For more details, see the Falco docs: https://falco.org/docs/#what-does-falco-check-for.

Using the Falco Dashboard​

A quick way to view Falco security events is to:

1. Log in to Cloud.gov Logs
2. Click on "Dashboards" in the left sidebar menu
3. Enter "Services" in the search bar
4. Follow the link for "Falco Overview"

How to Search Falco Logs in Cloud.gov Logs​

Falco logs are ingested into the logging system with the value @type: falco, which provides an easy way to filter them.

To find your Falco security events in the logging system:

1. Log in to Cloud.gov Logs
2. Click on "Discover" in the left sidebar menu
3. Add a filter for @type: falco to your log search
4. Apply additional filters on the Falco event fields as desired. For example, to filter for specific rule types, add a filter of falco_rule: [rule_name]

Falco Log Fields​

The fields available on Falco security event records are:

• falco_priority - Classification system to show the priority level of detected event(0 is Emergency,7 is debug)
• @message - Contains the details of the Falco finding
• falco_rule - Name of the Falco rule that generated the event (include this when contacting Cloud.gov Support)

The complete list of Falco fields is available here: https://falco.org/docs/reference/rules/supported-fields/.

Retention​

Falco events are retained in the logging system for 1 year and in offline storage for 30 months.

When you deploy Java applications on Cloud.gov, the Java buildpack provides your JVM and other dependencies. The Cloud Foundry Java buildpack team has completed a major rewrite, version 5, which removes legacy code and introduces breaking changes to how Java apps are built and deployed.

Current status:

• Default buildpack: v4.76.0 (March 2025)
• New buildpack: v5.0.x series (in testing)
• Timeline: v4.76.0 will remain the Cloud.gov default until v5.1.0 GA release, date not yet known

Why You Should Act Now​

The Cloud Foundry team is actively addressing issues in the new buildpack, but they can only fix bugs they know about. By testing your applications now, you'll help identify issues before the upgrade becomes the default, ensuring a smoother transition for your team and the entire Cloud.gov community.

Step 1: Review the relevant documentation​

The following documents detail the changes, and provide additioanl context:

• 5.0.0 Release notes
• Cloud Foundry Community RFC

Step 2: Test Your Java Applications​

We strongly recommend that all Cloud.gov customers test their Java applications with the new buildpack. Early testing gives you time to address any compatibility issues before the migration, and may reveal bugs that need to be fixed upstream with Cloud Foundry.

Option A: Test Using the cf push Command​

Run the following command to deploy your app with the 5.0.2 buildpack (update to 5.0.3, etc., as those become available)

cf push MY_APP --buildpack https://github.com/cloudfoundry/java-buildpack/releases/download/v5.0.2/java-buildpack-cflinuxfs4-v5.0.2.zip

Option B: Test Using Your manifest.yml File​

Add the 5.0.2 buildpack specification to your manifest file:

    ...
    buildpacks:
      - https://github.com/cloudfoundry/java-buildpack/releases/download/v5.0.2/java-buildpack-cflinuxfs4-v5.0.2.zip
   ...

Then deploy as usual with cf push.

Pro tip: Test in a non-production environment first to validate behavior without undue risk.

Step 3: Report Any Issues You Encounter​

If you discover compatibility problems or unexpected behavior during testing:

• For buildpack-specific issues: Report them directly to the Cloud Foundry Java buildpack team at https://github.com/cloudfoundry/java-buildpack/issues
• Need help reporting an issue? Open a support request and our team will assist you in documenting and escalating the problem.

When reporting issues, include:

• Your application's Java version
• Relevant error messages or logs
• Steps to reproduce the problem
• Expected vs. actual behavior

Alternative: Pin Your Buildpack Version (If Needed)​

While we recommend adopting the v5.x buildpack as soon as it's generally available, you can temporarily pin your applications to an older version if you need more time to migrate. Use the same syntax shown above in the testing section to specify your preferred buildpack version.

Note: Pinning to older versions means you won't receive the latest security updates and features, so plan to upgrade as soon as feasible.

Timeline and Next Steps:

1. Now through v5.1.0 GA release: Test your applications and report issues
2. When v5.1.0 is released: Cloud.gov will make v5.x the default buildpack
3. After the transition: Continue monitoring your applications and update any version pins

Questions? Contact Cloud.gov support for assistance.

What's New?​

Cloud.gov now captures two essential network metrics for all application containers:

• Received network traffic (containermetric.rx_bytes): Total bytes received by your application container
• Transmitted network traffic (containermetric.tx_bytes): Total bytes sent by your application container

These metrics are derived from Diego container telemetry and are automatically collected alongside existing CPU, memory, and disk metrics.

Why This Matters​

Network metrics provide crucial insights for:

• Performance monitoring: Track network throughput and identify potential bottlenecks
• Troubleshooting: Correlate network activity with application behavior and performance issues
• Capacity planning: Make informed decisions about scaling based on actual network usage patterns

How to Access the New Metrics​

The network metrics are available in the logs-metrics-* index pattern in Cloud.gov Logs. Here are some useful queries:

View all network metrics for your app:​

@type: app_metric AND (containermetric.name: rx_bytes OR containermetric.name: tx_bytes)

Filter for received bytes only:​

@type: app_metric AND containermetric.name: rx_bytes

Filter for transmitted bytes only:​

@type: app_metric AND containermetric.name: tx_bytes

Combine with other filters:​

@type: app_metric AND containermetric.name: tx_bytes AND @cf.app: "your-app-name"

What You Can Do With This Data​

1. Create visualizations: Build dashboards showing network traffic patterns over time
2. Set up alerts: Monitor for unusual spikes in network activity
3. Analyze trends: Identify peak usage times and seasonal patterns
4. Correlate with other metrics: Compare network usage with CPU and memory to get a complete picture of application performance

New versions for RDS​

Version 16 for PostgreSQL databases is now supported and is now the default version for all PostgreSQL database plans.

See the RDS service documentation for more information.

Update RDS database versions​

Updating the version of your RDS databases is now supported, whereas previously database version upgrades had to be performed by Cloud.gov support.

To update a MySQL database to version 8.4:

cf update-service ${SERVICE_NAME} \
    -c '{"version": "8.4", "allow_major_version_upgrade": true}'

To update a PostgreSQL database to version 16:

cf update-service ${SERVICE_NAME} \
    -c '{"version": "16", "allow_major_version_upgrade": true}'

See the RDS service documentation for more information.

New engines and versions for Elasticache​

Valkey has been added as a supported engine for Elasticache services. Valkey 8.2 can now be specified as the target engine and version when creating or updating Elasticache services.

To create an Elasticache service using Valkey 8.2:

cf create-service aws-elasticache-redis \
    ${SERVICE_PLAN_NAME} \
    ${SERVICE_NAME} \
    -c '{"engine": "valkey", "engineVersion": "8.2"}'

See the Elasticache service documentation for more information.

Update Elasticache versions​

Updating the version of your Elasticache service is now supported, whereas previously Elasticache version upgrades had to be performed by Cloud.gov support.

To update an Elasticache service to use Valkey 8.2:

cf update-service ${SERVICE_NAME} \
    -c '{"engine": "valkey", "engineVersion": "8.2"}'

See the Elasticache service documentation for more information.

Available ElastiCache Metrics​

Memory and Storage Metrics​

Cache Utilization​

These metrics help identify how efficiently the cache is being used.

• Bytes Used For Cache, metric_name: BytesUsedForCache
• Cache Hit Rate, metric_name: CacheHitRate

Memory Capacity​

These metrics monitor memory consumption and potential memory-related issues.

• Database Memory Usage Percentage, metric_name: DatabaseMemoryUsagePercentage
• Database Capacity Usage Percentage, metric_name: DatabaseCapacityUsagePercentage
• Freeable Memory, metric_name: FreeableMemory
• Memory Fragmentation Ratio, metric_name: MemoryFragmentationRatio

System Resource Metrics​

CPU Utilization​

These metrics help identify processing load and potential performance bottlenecks.

• CPU Utilization, metric_name: CPUUtilization
• Engine CPU Utilization, metric_name: EngineCPUUtilization

Using the Services - ElasticCache Dashboard​

A quick way to view ElasticCache metrics is to:

1. Log in to the logging system
2. Click on "Dashboards" in the left sidebar menu
3. Enter "Services" in the search bar
4. Follow the link for "Services - ElasticCache"

How to Search Metrics in the Logging System​

Metrics are ingested into the logging system with the value @type: metrics, which provides an easy way to filter them.

To find your metrics in the logging system:

1. Log in to the logging system
2. Click on "Discover" in the left sidebar menu
3. Add a filter for @type: metrics to your log search

4. Apply additional filters on the metrics event fields as desired. For example, to filter for BytesUsedForCache, add a filter of metric_name: BytesUsedForCache:

Metrics Fields​

The fields available on elasticcache metrics records are:

• @cf.service_offering - Type of service being monitored
• @cf.service_plan - Specific service plan details
• metric.average - Numeric value of the metric
• metric_name - Name of the specific metric
• metric.unit - Unit of measurement
• metric.cluster_identifier - ElastiCache cluster and node.

Retention​

Metric events are retained in the logging system for 3 months and in offline storage for 30 months.

How you can use alerts​

You can use the alerting feature of Cloud.gov Logs to be alerted based on:

• The count of documents returned by a query for the given time period
• The average, sum, maximum, or minimum value of a field value for the given time period

For example, you can receive alerts when:

• There are elevated 404 response rates for your application
• Specific terms or phrases (e.g. errors, exceptions) appear in your logs
• Your database storage has reached a certain percentage

Documentation​

For information on how to configure log-based alerts, please visit the Alerting page in the Observability section of this website.

Example 1: Alerting on high disk usage for an RDS database​

To receive alerts when the percentage of storage used by an RDS database service exceeds a certain threshold (e.g. 85%):

1. Set up the notifications to configure what emails will receive alerts

2. Open the OpenSearch navigation menu, then select Alerting under OpenSearch Plugins

3. Click the Monitors link in the tabbed navigation near the top of the page

4. Click the Create monitor button near the top right of the page

5. On the Create monitor page, enter the following information in the Monitor details section:

   • Monitor name: Any descriptive name for this monitor (e.g. "MonitorHighRDSDiskUsage")
   • Monitor type: Per query monitor
   • Monitor defining method: Extraction query editor
   • Schedule: 1 hour

6. In the Select data section, enter the following details:

   • Indexes: logs-metrics*
   • Time Field: @timestamp

7. In the Query section, enter this query in the Define extraction query box, replacing <your-instance-name> with the name of the database service whose disk usage you want to monitor:

   {
     "size": 1,
     "query": {
       "bool": {
         "filter": [
           {
             "match_phrase": {
               "@cf.service_offering": {
                 "query": "aws-rds",
                 "slop": 0,
                 "zero_terms_query": "NONE",
                 "boost": 1
               }
             }
           },
           {
             "match_phrase": {
               "metric_name": {
                 "query": "FreeStorageSpace",
                 "slop": 0,
                 "zero_terms_query": "NONE",
                 "boost": 1
               }
             }
           },
           {
             "match_phrase": {
               "@cf.instance": {
                 "query": "<your-instance-name>",
                 "slop": 0,
                 "zero_terms_query": "NONE",
                 "boost": 1
               }
             }
           },
           {
             "range": {
               "@timestamp": {
                 "gte": "now-15m",
                 "lte": "now",
                 "include_lower": true,
                 "include_upper": true,
                 "format": "strict_date_optional_time"
               }
             }
           }
         ]
       }
     },
     "sort": [
       {
         "@timestamp": {
           "order": "desc",
           "unmapped_type": "boolean"
         }
       }
     ]
   }
   

8. In the Triggers section, click the Add trigger button

9. Under New trigger, enter the following information:

   • Trigger name: A descriptive name for the trigger

   • Severity level: Choose the severity level you want assigned to these alerts. The severity level can be included in the alert messages.

   • Trigger condition: Define a condition for the disk usage percentage that should trigger an alert, which is set to 85% in this example:

     ctx.results[0].hits.hits[0]._source.metric.usage_percentage > 85

10. Optionally, click the Preview condition response to see whether your condition would be triggered based on the current query results

11. Under Actions (1), customize the Notification details:

    • Action name: A descriptive name for this action (e.g. "EmailHighDiskUsageAlert")
    • Channels: Select the channel that you previously created for send emails to the desired recipients
    • Message subject: A custom message subject for the alert email
    • Message: The alert email contents

    To preview the alert email contents, you can click the Preview message checkbox which will generate a preview of the email directly below the Message box. Youcan also click the Send test message to actually send a test version of the message to the configure channel.

12. Click the Create button at the bottom of the page.

This monitor should send an email alert if and when the disk usage of your database instance exceeds 85%. If you expect alerts that you are not receiving, then search the RDS database metric logs to determine whether your database disk usage is exceeding the configured threshold.

Example 2: Alerting on SSH access to your applications​

To receive alerts whenever cf ssh is used to access one of your applications:

1. Set up the notifications to configure what emails will receive alerts

2. Open the OpenSearch navigation menu, then select Alerting under OpenSearch Plugins

3. Click the Monitors link in the tabbed navigation near the top of the page

4. Click the Create monitor button near the top right of the page

5. On the Create monitor page, enter the following information in the Monitor details section:

   • Monitor name: Any descriptive name for this monitor (e.g. "MonitorApplicationSSHAccess")
   • Monitor type: Per query monitor
   • Monitor defining method: Visual editor
   • Schedule: 30 minutes

6. In the Select data section, enter the following details:

   • Indexes: logs-app*
   • Time Field: @timestamp

7. In the Query section, customize the settings as shown:

   • Metrics: COUNT OF documents
   • Time range for the last: 30 minutes
   • Data filter
     • @type: audit_event
     • type: audit.app.ssh-authorized
     • @cf.org: <your-org>
       • Replace <your-org> with the organization you want to monitor.
     • @cf.space: <your-space>
       • Replace <your-space> with the space you want to monitor.
     • target.name: <your-app> - Optional, if you want to monitor for SSH access to a specific application
       

   Query configuration screenshot:

8. In the Triggers section, click the Add trigger button

9. Under New trigger, enter the following information:

   • Trigger name: A descriptive name for the trigger
   • Severity level: Choose the severity level you want assigned to these alerts. The severity level can be included in the alert messages.
   • Trigger condition: IS ABOVE 0

   The graph below Trigger condition will show whether your monitor would have triggered in the last query period specified by the monitor, which can be useful for validating your trigger condition.

10. Under Actions (1), customize the Notification details:

    • Action name: A descriptive name for this action (e.g. "ApplicationSSHAlert")
    • Channels: Select the channel that you previously created for send emails to the desired recipients
    • Message subject: A custom message subject for the alert email
    • Message: The alert email contents

    To preview the alert email contents, you can click the Preview message checkbox which will generate a preview of the email directly below the Message box. Youcan also click the Send test message to actually send a test version of the message to the configure channel.

11. Click the Create button at the bottom of the page.

This monitor should send an email alert if cf ssh is used in the organization and space that you configured anytime in a 30 minute period. If you expect alerts that you are not receiving, then search the audit event logs to see if there are SSH events meeting your monitoring condition.

The Cloud.gov team is updating how CloudWatch logs (e.g. brokered database logs) are ingested into Cloud.gov Logs. This change will provide quicker and more reliable access to CloudWatch logs and enable faster addition of new CloudWatch log groups for brokered services.

Temporary duplicate logs during transition​

To ensure a safe migration with no log outages, we will run both the old and new ingestion methods in parallel during the transition. This approach means you will temporarily see duplicate CloudWatch logs in your dashboards and searches.

How to identify the new logs​

The new CloudWatch logs can be identified by the @type: cloudwatch field. These logs will continue to appear in the logs-app* indices as before.

Timeline​

• Parallel ingestion period: The old and new ingestion methods will run simultaneously until November 12, 2025
• Old system shutdown: On November 12, 2025, the old ingestion method will be disabled

If any issues arise which require extending the parallel ingestion period, we will update this document.

Action required: Update your custom visualizations and dashboards​

During the transition period, please:

• Disregard duplicate logs in your searches and dashboards
• Update all visualizations and dashboards that use CloudWatch logs to reference the new logs (those with @type: cloudwatch)
• Prepare for the old duplicate logs to stop appearing after the transition period ends

For questions about this migration, please contact support@cloud.gov.

The URI (Uniform Resource Identifier) credential values generated for the Elasticache Redis service by the AWS broker has been changed. Previous versions of the broker generated a URI credential value that was incorrect for connecting to Elasticache instances over TLS.

Specifically, in the URI credential value, a URI scheme of redis:// (with s) was used, but when connecting over TLS a URI scheme of rediss:// is required (with ss). Going forward the AWS broker will use the TLS URI scheme.

Actions required​

You must unbind and rebind your application and the Elasticache Redis service so that you receive the new credentials that utilize the new URI scheme.

Questions​

If you have any questions, please contact support@cloud.gov.

While the CDN service and Custom domain service have not allowed the creation of new domain services for over four years, there are still domain services on these old brokers which were never migrated to the External domain service.

We have decided to fully retire the older services on February 1, 2026. We're here to support you in the transition, and aim to do so with minimal disruption to your operations.

Timeline​

How to know if you are affected​

If you are using service(s) on one of the old domain brokers, you will be contacted either by the Cloud.gov or the Cloud.gov Pages support teams. The email will specify which services are affected and include instructions on how to migrate your service(s).

All affected customers should receive a notification by Friday, October 10, 2025.

If you want to check for yourself whether you are using one of deprecated services, you can use this shell script (replacing your-org with your actual organization name):

MY_ORG="your-org"
ORG_GUID=$(cf org --guid "$MY_ORG")
PLAN_GUIDS=$(cf curl "/v3/service_plans?names=custom-domain,cdn-route" | jq -r '[.resources[].guid] | join(",")')
cf curl "/v3/service_instances?organization_guids=$ORG_GUID&service_plan_guids=$PLAN_GUIDS" | jq '.resources[] |.name'

The script will return the names of any service instances on the deprecated brokers, if there are any.

How to migrate your service(s)​

The notification email from Cloud.gov will include specific instructions for how to migrate your service(s), but in general, there are two migration paths:

• Automated migration
• Manual migration

Whether you can use automated migration or manual migration is based upon whether the domain(s) for your service(s) are apex domains.

Automated migration for non-apex domains​

Follow the steps on documentation for migrating domain service(s) to create or update your DNS records to the values expected by the external domain broker. Once you complete these steps, your domains will automatically be migrated to external domain services with no downtime.

Manual migration for apex domains​

Migrating service(s) for apex domains requires coordination between DNS updates and the provisioning of new CDN services, so performing these migrations is best done on a scheduled call with the Cloud.gov support team or Cloud.gov Pages support team.

You can schedule a call to perform your migration by contacting Cloud.gov support at support@cloud.gov or Cloud.gov Pages support at pages-support@cloud.gov.

Questions​

If you have any questions, please contact support@cloud.gov.

In order to reduce infrastructure cost, container metrics storage has been updated to a 90-day retention policy. Container metrics are not subject to M-21-31 logging requirements, so this change does not affect M-21-31 compliance.

The new retention policy for container metrics is implemented as follows:

• Metrics from August 11, 2025 and earlier - All container metrics from August 11th, 2025 and earlier will remain available for a year with the last one rolling off on August 11th, 2026.
• Metrics for August 12, 2025 and afterwards - Starting August 12th, 2025, metrics will follow the 90-day retention policy, meaning metrics from August 12th, 2025 will be deleted on November 13th, 2025. This rolling 90-day deletion pattern will continue for all subsequent metrics.

New retention and visualizations for AWS metrics​

AWS metrics (RDS databases, S3 buckets, etc) are being transitioned to a new 90-day retention policy. Implementing this retention policy also required changing how these metrics are stored in the logging system.

With the changes to the storage of these metrics, the visualizations of these metrics have to be updated as well. To ensure continuity of access to your AWS metrics data, the rollout of the updated visualizations will be handled as follows:

• Visualizations (e.g. Opensearch/Elasticsearch CPUUtilization) will be updated to read metrics from the new storage pattern.
• Legacy visualizations will be added to display metrics data from before the cutover to the new storage pattern. These visualizations will be named with a - Old suffix (e.g., Opensearch/Elasticsearch CPUUtilization - Old).
  • Legacy visualizations will continue to receive data during the transition until the new system has accumulated 90 days of historical data.

Improvements to AWS metrics ingestion​

The Cloud.gov team is also updating the tools for ingesting AWS metrics into the logging system. The benefits of the updated ingestion pattern are:

• Consistent Daily Metrics: Daily S3 bucket size reporting with constant interval.
• Near Real-Time Updates: AWS metrics will stay updated to within the last 4 minutes of metric collection time
• Increased OpenSearch Integration: The new system will allow for easier addition of new AWS metrics to OpenSearch.

For questions about this migration, please contact support@cloud.gov.

A read replica is a read-only copy of your database which automatically replicates the data in your primary database. You can offload read-heavy tasks to a read replica while your primary database handles writes. Isolating read operations to the replica reduces the load and lock contention on your primary database.

Use cases for a read replica include:

• Generating reports from your data
• Serving data for API requests
• Performing analytics queries

How to create a read replica service​

To create a new database service with a read replica:

cf create-service aws-rds micro-psql-replica <your-service-name>

To update an existing database to a read replica plan:

cf update-service <your-service-name> -p micro-psql-replica

See the database service documentation for more information on how to create or update database services.

Read replicas are supported for all aws-rds plans. To add a read replica to an existing instance, use the replica plan corresponding to its current plan. For example, an instance using the medium-gp-psql plan should update to medium-gp-psql-replica.

To see the list available of replica plans (which all end in -replica):

cf marketplace -e aws-rds

While your database service is being created or updated to add a read replica, running cf service <your-service-name> should report on the status of the create or update operation:

...
Showing status of last operation:
   status:    create in progress
   message:   Waiting for database to be available. Current status: in progress (attempt 6 of 60)
   started:   2025-07-01T18:28:22Z
   updated:   2025-07-01T18:28:22Z

Using your read replica​

Once you have created or updated a service with a read replica, you need to bind that service to an application to get the credentials to access it.

See the database service documentation for general guidance on how to bind database services to an application.

In particular, note the extra replica_uri and replica_host values that are available for any database service with a read replica.

If you updated an existing database service from a non-replica plan to a replica plan, then you will need to un-bind and re-bind that service to include the credentials for accessing the read replica. As always, when binding or re-binding a service to an application, you should then restage the application.

Using these credentials in your application code or other tools, you should be able to connect to your read replica database and use it. Remember that read replica databases are read-only, so you cannot write to them.

Questions​

If you have any questions, please contact support@cloud.gov.

However, updating all the remaining codebases within the Cloud Foundry ecosystem to use the v3 API has been taking the community longer than expected. This includes code that Cloud.gov is dependent upon. We are working with the community to resolve these dependencies, or to deploy v3 API alternatives.

We will announce a new 90-day deprecation timeline later in 2025, once all internal dependencies are resolved.

Questions​

If you have any questions, please contact support@cloud.gov.

• Comprehensive Elasticsearch/OpenSearch domain metrics to help teams monitor system performance and resource utilization for brokered domains
• A new metric that allows teams to easily track the size of their S3 buckets

Available S3 Metrics​

Storage and Capacity Metrics​

• Bucket Size in Bytes, metric_name: BucketSizeBytes

Available OpenSearch/Elasticsearch Metrics​

System Resource Metrics​

CPU Utilization​

These metrics help identify processing load and potential performance bottlenecks.

• Overall domain CPU usage, metric_name: CPUUtilization
• Master node CPU usage, metric_name: MasterCPUUtilization

Memory Pressure​

These metrics monitor memory consumption and other potential memory-related issues.

• JVM Memory Pressure, metric_name: JVMMemoryPressure
• Old Generation JVM Memory Pressure, metric_name: OldGenJVMMemoryPressure
• Master Node Memory Pressure, metric_name: MasterJVMMemoryPressure
• Old Generation Master Node Memory Pressure, metric_name: MasterOldGenJVMMemoryPressure

Storage and Capacity Metrics​

Free Storage Space​

This metric helps track storage capacity and plan for scaling.

• Available storage in gigabytes, metric_name: FreeStorageSpace

Threadpool Performance​

Write Queue Metrics​

• Write Queue Count, metric_name: ThreadpoolWriteQueue
• Write Queue Rejected Requests, metric_name: ThreadpoolWriteRejected

Search Queue Metrics​

These metrics monitor background processing and potential system overload:

• Search Queue Count, metric_name: ThreadpoolSearchQueue
• Search Queue Rejected Requests, metric_name: ThreadpoolSearchRejected

Using the Services - S3 Dashboard​

A quick way to view domain metrics is to:

1. Log in to the logging system
2. Click on "Dashboards" in the left sidebar menu
3. Enter "Services" in the search bar
4. Follow the link for "Services - S3"

Using the Services - Elasticsearch/OpenSearch Dashboard​

A quick way to view domain metrics is to:

1. Log in to the logging system
2. Click on "Dashboards" in the left sidebar menu
3. Enter "Services" in the search bar
4. Follow the link for "Services - Elasticsearch/OpenSearch"

How to Search Metrics in the Logging System​

Metrics are ingested into the logging system with the value @type: metrics, which provides an easy way to filter them.

To find your metrics in the logging system:

1. Log in to the logging system
2. Click on "Discover" in the left sidebar menu
3. Add a filter for @type: metrics to your log search

4. Apply additional filters on the metrics event fields as desired. For example, to filter for domain FreeStorageSpace, add a filter of metric_name: FreeStorageSpace:

Metrics Fields​

The fields available on metrics records are:

• @cf.service_offering - Type of service being monitored
• @cf.service_plan - Specific service plan details
• metric.average - Numeric value of the metric
• metric_name - Name of the specific metric
• metric.unit - Unit of measurement

How Metrics Are Ingested into the Logging System​

An automated job runs every 10 minutes to pull metric events from the platform and ingest them into the logging system. AWS limits most metrics to a 2-minute delay. Thus, there could be up to a 12-minute delay before metric logs appear in the logging system.

Retention​

Metric events are retained in the logging system for 3 months and in offline storage for 30 months.

While audit events can be queried from the platform via an API, they are only retained by the platform for 31 days by default.

To simplify customer access to audit events and to satisfy M-21-31 guidelines for the retention of these logs, audit events are now available in the Cloud.gov logging system.

Using the Audit - Overview dashboard​

A quick way to view audit events is to:

1. Log in to the logging system
2. Click on "Discover" in the left sidebar menu
3. Enter "Audit" in search bar, as shown below, then follow the link for "Audit - Overview"

The example "Audit - Overview" dashboard below shows sample audit events for restarting an app, and then SSH'ing to it. When using this dashboard, bear in mind that events may be delayed by 15 minutes.

How to search audit events in the logging system​

Audit events are all ingested into the logging system with a value of @type: audit_event, which provides an easy way to filter for them.

To find your audit events in the logging system:

1. Log in to the logging system

2. Click on "Discover" in the left sidebar menu

3. Add a filter for @type: audit_event to your log search

   

4. Adjust the view of the results as desired

   

5. Apply additional filters on the audit event fields as desired. For example, to filter for app restart events, add a filter of type: audit.app.restart:

   

Audit event fields​

The fields available on audit event records are:

• guid - GUID for the audit event
• type - the type of audit event recorded
• actor.guid - GUID of the actor for the event
• actor.type - Type of the actor for the event (e.g. user, process)
• actor.name - Name of the actor for the event
• target.guid - GUID of the target for the event
• target.type - Type of the target for the event (e.g. app, service)
• target.name - Name of the target for the event
• data.* - Additional information about the event. The fields are different for each type of event.
• created_at - Time when the audit event was created
• updated_at - Time when the audit event was last updated

How audit events are ingested into the logging system​

An automated job runs every 15 minutes to pull the audit events from the platform and ingest them into the logging system. Thus, there could be up to a 15-minute delay before any audit event logs appear in the logging system.

Retention​

Audit events are retained in the logging system for 12 months and in offline storage for an additional 18 months.

Relevant NIST controls​

Audit events stored in the logging system satisify NIST controls in the AU control family, specifically:

• AU-02
• AU-11

Managed cache policies​

One of the benefits of external domain CDN services is caching, which can reduce load on your origin server by responding to requests with content served directly from the cache.

CloudFront, the underlying AWS service for external domain services, offers many options for controlling how and when content from your origin server is cached.

To simplify the management of your CloudFront distribution's caching behavior, AWS offers managed cache policies.

The following managed cache policies are now supported for external domain CDN services:

• Managed-CachingDisabled
• Managed-CachingOptimized
• Managed-CachingOptimizedForUncompressedObjects
• UseOriginCacheControlHeaders
• UseOriginCacheControlHeaders-QueryStrings

To specify a cache policy when creating a new CDN service:

cf create-service external-domain domain-with-cdn \
    -c '{"cache_policy": "Managed-CachingOptimized"}'

Please refer to the external domain services page for further documentation of the behavior of the cache_policy parameter.

Managed origin request policies​

CloudFront offers the ability to specify which properties (headers, cookies, query parameters) are included when forwarding a request to an origin server.

To simplify the configuration of which request properties are forwarded from CloudFront to an origin server, AWS offers managed origin request policies.

The following origin request policies are supported for external domain CDN services:

• Managed-AllViewer
• Managed-AllViewerAndCloudFrontHeaders-2022-06

To specify an origin request policy when creating a CDN service:

cf create-service external-domain domain-with-cdn \
    -c '{"origin_request_policy": "Managed-AllViewer"}'

Please refer to the external domain services page for further documentation of the behavior of the origin_request_policy parameter.

When Cloud.gov app developers interact with our the platform, they do so via the Cloud Foundry API at [https://api.fr.cloud.gov>]. Currently that API works for both version 2 (with /v2 paths) and version 3 (with /v3 paths).

The v2 API has been in deprecated status with the Cloud Foundry Foundation since 2021, and in 2025 the Cloud Foundry development teams will stop supporting v2. At Cloud.gov we will continue to support v2 for through June 6, 2025, per our deprecation policy.

What this means for our customers​

This only impacts developers on the Cloud.gov Platform, not Cloud.gov Pages. This should not impact any applications running on Cloud.gov, but it may impact how you deploy and manage your applications.

Your team should check that all of the following have been updated to v3-compatible versions, if applicable:

• CF Client, cf-cli. You can check your version with cf version.

  • Versions v7.7.1 and v8.7.1 are the minimum supported versions.
  • In early 2025, unsupported clients will trigger an alert like this:
    🚨 [WARNING] Outdated CF CLI version - please upgrade: https://github.com/cloudfoundry/cli/releases/latest 🚨
  • You may continue using unsupported clients until v2 is discontinued.
  • If you need to reinstall/upgrade your client, follow our documentation

• cf-cli plugins. Our Cloud.gov documentation references a number of useful plugins, their current v3 Plugin Status is detailed in the table below.

  • For "pending" plugins, periodically check the linked GitHub issues for status.
  • For plugins with no update pending, seek an alternative.

• CF API client libraries such as cf-java-client, go-cfclient, or cf-python-client:

  • Review your deployment and management scripts for such libraries
  • Ensure you've updated to a v3-compatible library

• Terraform:

  • Use the v3 CloudFoundry Terraform provider
  • The original community-supported Terraform provider is not v2-compatible.

• Scripts that directly use cf curl:

  • Review the scripts and ensure you're using paths that start with /v3/
  • The API has changed so review the v3 API docs

Plugin Status​

Deprecation timeline​

Update 2025-06-17: This deprecation timeline is no longer in effect. See V2 API end-of-life delayed

• January 2025: Cloud.gov will start publishing statistics on usage of v2 vs v3 endpoints to track progress to decommissioning.
  • v2 CF CLI clients will trigger an alert that they need updating.
• February 2025: Cloud.gov will publish our v2 "brownout" schedule. Brownouts are when we intentionally disable the v2 endpoint for a published period of time so developers can test their development and release procedures.
  • We will schedule brownouts to accommodate customer releases, so please respond to any suggested brownout schedule.
• March, April, May 2025: Cloud.gov will hold published v2 brownouts. These will increase in duration as we approach end-of-life.
• June 7, 2025: Cloud.gov will permanently disable v2.

The Cloud.gov team may accelerate this schedule if v2 usage has ceased, or if maintaining v2 poses risks to platform operation.

Updates​

Updates to this page, or links to additional documentation will be listed below:

• 2025-06-18: See V2 API end-of-life delayed

If you have any questions about updating your Node.js version or are experiencing any problems, please contact us at pages-support@cloud.gov.

The significance of the update requires a cutover from the current system to the new one that will take place on the following timeline:

• December 3: The new system will be generally available at https://logs-beta.fr.cloud.gov.
• December 10: The current logging system will be renamed to [https://logs-deprecated.fr.cloud.gov], and new system will be available at [https://logs.fr.cloud.gov]
• January 7, 2025: The deprecated logging system will be decommissioned.

Improvements and differences​

The current logging system is based on a branch of the Elastic ELK stack that has not seen new features for several years. Our updated system is based on OpenSearch, a fork of the ELK stack, so much of the user interface should be familiar. Improvements and differences include:

• Twelve months of live access to system logs
  • The current system only has access to 6 months
  • Meets M-21-31 requirements for live logging access
• Better tenant isolation: The updated system uses OpenSearch Organizations and a new authorization system to improve multitenancy. The new architecture resolves a variety of errors for customers.
• Better performance, better security, and better upgrade paths
• New: Logs for brokered RDS database instances are now available. Please note that only databases which are configured to publish their logs to CloudWatch will have their logs ingested into our new logging system.
• New: JSON log parsing. JSON logs are now ingested using the flat_object field type in OpenSearch. The flat_object field type allows for searching nested fields of a JSON object using dot notation but does not require the overhead of custom fields in the index, which is more performant and prevents custom logs from being dropped because of index field limits.
• Coming Soon:
  • Support for alerting, and routing alerts to external systems

Actions you may need to take​

No action is needed to ensure that your logs will be available: All log entries emitted by your containers and applications will be available in the new system. Any integrations you have with external logging services remain the same.

Select tenancy: When you log in, you will be required to select which tenant (Cloud.gov organization) you want to work in. Any visualizations and dashboards you create will only be visible to other people with access to the same tenant and underlying organization in Cloud.gov

We recommend you take the following actions:

• Migrate saved searches and dashboards: While all the log entries are being migrated for you, you will need to migrate customizations you have made. We will provide documentation next week.
• Update bookmarks: Saved bookmarks that work with the old system will not work with the new system. You will need to update your bookmarks, as we'll detail in our transition documentation.
• Take a tour: If you can, try out the new system in December while you can compare functionality to the old system. Consider attending the Cloud.gov Logs workshop the week on December 10.
• Ask for help: Report any undocumented issues you encounter, or questions you may have, to support@cloud.gov.

Support we're providing during this transition​

• Documentation: We are completing our review of updated documentation and will be publishing them in the coming days. Links to the documentation will be in upcoming emails and Cloud.gov News.
• Workshop: We are preparing a Cloud.gov Logs workshop for December 10 to cover what's new, what's changed, and how to use the system effectively. We'll provide registration information in future updates.
• Regular communication: We will be sending weekly emails on this transition through the end of the calendar year.
• Additional support: We have additional staff ready in December to respond to logging-related support requests

Deprecation notice​

The Cloud.gov deprecation policy calls for a longer transition period between services than we're employing here, unless continuing that service poses risks to the platform. Since the current logging system uses components that are reaching EOL, continued operation poses security and compliance risks, and we are moving to decommission the service by January 10, 2025.

Updates​

December 6, 2024: Changes to expect with the December 2024 logging update

Adding these protections furthers our goal to provide a secure and reliable platform for Cloud.​gov customers. By documenting these protections, we hope to increase transparency about how your applications are protected.

If you have any questions about these new protections or if you think that they may be inadvertently affecting your legitimate traffic on the platform, please contact us at support@cloud.gov. As always, thanks for being a Cloud.​gov customer!