--- title: "Known issues in Cloud Platform" date: "2024-02-14T06:18:38+00:00" summary: "Stay informed about Cloud Platform issues, including PHP, Memcache, UI, version control, and external services. Troubleshoot and find workarounds." image: type: "page" url: "/acquia-cloud-platform/known-issues-cloud-platform" id: "a9d1a81d-2fec-48c4-ad3c-43176cf94bbb" --- Table of contents will be added Cloud Platform versions Cloud Platform documentation refers to both the Cloud Classic and Cloud Next versions of this product, unless otherwise noted. This page describes the known issues in Cloud Platform generally and Cloud Classic specifically. For known issues that are specific to Cloud Next, see [Known issues in Cloud Next](/acquia-cloud-platform/known-issues-cloud-next "Known issues in Cloud Next"). Known issues with PHP and Memcache ---------------------------------- ### Issue with vendored packages in PHP 8.4 Using PHP 8.4 may cause deprecation warnings and Composer conflicts with certain Drupal and Drush combinations, such as Drupal 10.4.5 with Drush 13.4. This occurs due to incompatibilities with vendored packages or conflicting package versions. ### New environments provision with Cloud Platform default PHP version If a new Cloud Platform environment is provisioned by a CI/CD process, such as [Acquia Pipelines](/acquia-cloud-platform/features/pipelines) or [Acquia Code Studio](/acquia-cloud-platform/add-ons/code-studio/overview "Overview"), the new environment is provisioned with the default Cloud Platform PHP version. The new environment does not inherit the PHP settings from the source environment or CI/CD build. For more information on the default PHP version, visit [default Cloud Platform PHP version](/acquia-cloud-platform/manage-apps/php#cloud-php-version-used). _Workaround_: You must set your desired PHP version for the new environment. You can configure the PHP version through the [Cloud Platform user interface](/acquia-cloud-platform/manage-apps/php) or the command line. * **Cloud Platform user interface**: Modify the PHP version for your application at the environment level with the [configuration settings](/acquia-cloud-platform/manage-apps/php) after the new environment is deployed. * **Command line**: Change the PHP version with the following [Acquia CLI](/acquia-cloud-platform/add-ons/acquia-cli) command: acli app:task-wait "$(acli api:environments:update $TARGET_ENV_ID --lang_version=8.1)" Note If your Drupal application contains deprecated code, changes to the PHP version after deployment might cause initial failure notices. ### PHP 8.4 is compatible with Drupal 10.4 and higher, as well as Drupal 11.1 and higher PHP 8.4 is only compatible with Drupal 10.4 and higher and Drupal 11.1 and higher. Drupal 7 is incompatible with PHP 8.4. ### PHP 8.3 is compatible with Drupal 10.2 or higher  PHP 8.3 is compatible only with Drupal 10.2 or higher. For more information, see [https://www.drupal.org/docs/getting-started/system-requirements/php-requirements](https://www.drupal.org/docs/getting-started/system-requirements/php-requirements). ### `pcntl_fork()` is not supported in live code and can cause stability issues with PHP 8 and later. Using the `pcntl_fork()` function with PHP 8 and later in website code can leak PHP processes. This crashes the site slowly. Acquia recommends that you do not use this function, as it might be disabled eventually. However, you can use it in CLI PHP scripts. * * * Known issues in the Cloud Platform user interface ------------------------------------------------- ### Cloud Platform notification API does not display real-time results The Cloud Platform [notification API](/acquia-cloud-platform/develop-apps/api/notifications) does not display real-time results. It typically returns a response within seconds, but sometimes can take several minutes to reflect the current state of the platform. ### Cloud Platform displays a zlib “freed prematurely” message when inspecting tasks When inspecting the output of any successful or failed task, the final line is: `zlib(finalizer): the stream was freed prematurely`. This message can be ignored. ### XML is not an acceptable file type in Support tickets The acceptable file listing on the [customer-facing ticket submission page](/service-offerings/contacting-acquia-support "Contacting Acquia Support") lists XML as an acceptable file type, but XML files are not accepted for upload. _Workaround_: Place the XML in a `.zip` file, and then attach the `.zip` file to the ticket. ### The active domain for an environment cannot be changed The [active domain](/acquia-cloud-platform/manage-apps/domains/active) for an environment defaults to the first bare domain name, with or without the `www` prefix, and cannot be changed. Environments that have no top-level custom domains use the [Acquia default domain](/acquia-cloud-platform/manage-apps/domains) as the active domain. ### Environment variables that start with `$` followed by a number are removed When you use [environment variables](/acquia-cloud-platform/develop-apps/env-variable) in the Cloud UI, starting a sequence with `$` followed by a number removes the first two characters. For example, adding `$23456` as an environment variable results in `3456`. _Workaround_: When you use the environment variable in your code, manually prepend the first two characters to the variable. Acquia recommends that you validate your code to prevent any application issues when the issue is resolved. * * * Known issues with version control --------------------------------- ### Git checkouts fail after reporting non-existent changes to binary files Git checkouts fail with the following error when non-text files contain a specific byte sequence and are not explicitly defined as binary files: `Your local changes to the following files would be overwritten by checkout. Please, commit your changes or stash them.` _Workaround_: Edit the following section of your `.gitattributes` file: # Auto-detect text files, ensure they use LF. * text=auto eol=lf and then make one of the following changes: * Remove the line that begins with `*`. * Remove the `eol=lf` text. * Ensure that a specification line is added for every binary file extension used in your repository. ### Deployed branches or tags cannot be deleted Cloud Platform does not allow you to delete branches that are currently deployed to an environment. If you try to delete a branch from the command line, an error message like the following displays: remote: Operation rejected: remote: Git branch or tag test_branch cannot be deleted because it is currently deployed to testsite.prod ### Cloud Platform displays an error message when pushing code to Git When attempting to push code, some users may encounter error messages like the following example if the `root` account owns a directory, instead of the `siteuser` account: remote: error: insufficient permission for adding an object to repository database ./objects To correct the ownership settings for the directory, [create a Support ticket](/service-offerings/support#contact-acquia-support). ### Deployment keys must be associated with a user account Cloud Platform does not support the use of deployment keys (_machine keys_) that are not associated with an individual user account. All SSH keys must be associated with a user account. _Workaround_: Create a user account to associate the deploy key as described in [Deployment keys and Cloud Platform](/acquia-cloud-platform/manage-apps/command-line/ssh/getting-started/add-key#cloud-machine-keys). * * * Known issues with the Acquia Connector -------------------------------------- ### Unable to log in through Acquia Connector You might get a 404 error when you log in through Acquia Connector. _Workaround_: You must assign the `Access to legacy product keys` permission to your role and re-authenticate yourself. ### Non-hosted applications have access issue while using Acquia Connector with Search In non-hosted applications, only users with admin privileges can click the **Sign in with Acquia** option for authentication to the search functionality. Non-admin user roles like team lead and developer cannot access this option. ### Acquia Connector 8.x-1.17 causes error during cron runs Upgrading to Acquia Connector 8.x-1.17 introduces the following error and may interfere with cron runs: Call to a member function getEditable() on null _Workaround_: Acquia recommends that you revert to [Acquia Connector 8.x-1.16](https://www.drupal.org/project/acquia_connector/releases/8.x-1.16). See [Upgrading to acquia\_connector-8.x-1.17 can throw error “Call to a member function getEditable() on null” during cron runs](https://acquia.my.site.com/s/article/360040664174-Upgrading-to-acquia-connector-8-x-1-17-can-throw-error-Call-to-a-member-function-getEditable-on-null-during-cron-runs) for more information. ### Acquia Connector requests can time out Drupal websites connected to Acquia subscription will send heartbeat requests during each cron run. By default, cron runs at the beginning of each hour, which can cause the Acquia subscription service to receive thousands of simultaneous connections across all subscriber websites. This causes some requests to time out. _Workaround_: If your subscription service is experiencing timeouts, Acquia recommends that you [modify your cron runs](/acquia-cloud-platform/manage-apps/cron) to not begin at the start of the hour. ### The Acquia Connector module conflicts with Remote stream wrapper module The Acquia Connector module has a conflict with the [Remote stream wrapper](https://www.drupal.org/project/remote_stream_wrapper) module, which is listed on the [Modules to use with caution on Cloud Platform](/acquia-cloud-platform/develop-apps/drupal-apps/module-caution) page. _Workaround_: Apply this [patch](https://www.drupal.org/node/2891977), available on Drupal.org. * * * Known issues with Drush ----------------------- Note The [current Drupal version](https://docs.acquia.com/service-offerings/guide/software-life-cycle#supported-drupal-version) requires Drush version 11 or later. Newer versions of Drush, that is, version 11 and later, must be installed through Composer. Acquia does not manage the update to the newer versions. For more information, see [About Drush on Cloud Platform](https://docs.acquia.com/acquia-cloud-platform/manage-apps/command-line/drush). ### Drush aliases (YAML format) downloaded from cloud throw warnings for PHP 8.0 Using the Drush aliases from the Drush page in the Cloud Platform user interface might generate warnings with certain Drush commands if the site is running PHP 8.0. dev: root: /var/www/html/d9forcl57747.dev/docroot ac-site: d9forcl57747 ac-env: dev ac-realm: devcloud uri: d9forcl57747abapnfzmsu.devcloud.acquia-sites.com dev.livedev: parent: '@d9forcl57747.dev' root: /mnt/gfs/d9forcl57747.dev/livedev/docroot host: d9forcl57747abapnfzmsu.ssh.devcloud.acquia-sites.com user: d9forcl57747.dev paths: drush-script: drush9 The preceding block shows a sample Drush alias in the YAML format. If you run the `drush uli` command from your terminal, you might encounter the following warnings and deprecated messages: $ vendor/bin/drush @default.dev uli [warning] Undefined property: Drush\Commands\core\LoginCommands::$uri ExecTrait.php:38 [warning] does not appear to be a resolvable hostname or IP, not starting browser. You may need to use the --uri option in your command or site alias to indicate the correct URL of this site. Deprecated: Required parameter $args follows optional parameter $command in /usr/local/drush9/vendor/drush/drush/includes/batch.inc on line 115 Deprecated: Required parameter $options follows optional parameter $command in /usr/local/drush9/vendor/drush/drush/includes/batch.inc on line 115 http://d9forcl57747.dev.acquia-sites.com/user/reset/1/1635526597/49RN0AE6RAINusSIxmSzRJgfoJmp3suVhdSFl2Vz2L0/login The `drush uli` command works and returns the desired output even with the warnings. If these warnings block your development, remove the following segment from the yaml file: paths: drush-script: drush9 ### The current Drupal version is incompatible with certain Acquia Drush commands The [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version) is not compatible with the following legacy commands: * `ah-db-backup`: Drush command for creating a database backup from the command line. * `ah-db-import`: Drush command for importing databases from the command line. For more information, visit [Downloading database backups from the command line](/acquia-cloud-platform/manage-apps/back-up/cli) or [Importing your database](/acquia-cloud-platform/create-apps/import/manual/manual-db). * `ah-site-archive-import`: Drush command for importing a website archive file, as described in [Importing an existing application using Drush](/acquia-cloud-platform/create-apps/import/archive/drush). * `drush archive-dump`: Drush command for creating a complete archive file of your application, as described in [Taking backups](/acquia-cloud-platform/manage-apps/back-up). You must use Composer to build websites running the [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version). You cannot use Drush to update your Drupal websites. ### Using Drush 9 may display error messages If you are using Drush 9 in a Platform environment, Cloud Platform may display the following errors, such as: * `Fatal error: require(): Failed opening required '/var/www/site-php//D8--[sitename]-settings.inc'` * `Drush command terminated abnormally due to an unrecoverable error.` _Workaround_: To determine if this Drush 9-based behavior is affecting your use of the product, execute the following commands from a command prompt: drush9 php-eval 'var_export($_ENV['AH_SITE_NAME'] , true);' printenv 'AH_SITE_NAME' These values must be equal. If they are not: 1. Edit your website’s `settings.php` file. 2. Before the [Acquia require](/acquia-cloud-platform/manage-apps/code/require-line) line, add `$_SERVER['PWD']=DRUPAL_ROOT;`. 3. Save the `settings.php` file. ### Drush aliases are downloaded only for active on-demand environments Drush aliases for Cloud Platform CD environments are downloaded only if the environment is active. ### Do not install Drush in your home directory Installing Drush in your user directory can cause unexpected task failures. Acquia recommends that you require a site-local Drush as part of your codebase, not your home directory, and run your commands with a specific major version of Drush, as described in [Using Drush on Cloud Platform](/acquia-cloud-platform/manage-apps/command-line/drush#drush-cloud). ### An error message is displayed while running Drush 12 commands Cloud Platform displays the following error message while running Drush 12 commands: `/bin/bash: /app/vendor/drush: No such file or directory` The Drush alias files that Cloud Platform generates are not compatible with Drush 12. _Workaround_: Update the Drush alias files as follows: paths: drush-script: '/var/www/html/${AH_SITE_NAME}/vendor/bin/drush' * * * Known issues with external services ----------------------------------- ### Legacy alerts from New Relic fail with the removal of TLS 1.0 Legacy alerts from New Relic fail with the removal of TLS 1.0 from Acquia systems. For help in updating your alerts, visit [Introduction to alerts and applied intelligence](https://docs.newrelic.com/docs/alerts-applied-intelligence/overview/). ### Website duplication may cause rsync issues Website duplication can cause [rsync](/acquia-cloud-platform/manage-apps/files/transfer-files/rsync) issues in the distributed file system which results in the following [log](/acquia-cloud-platform/monitor-apps/logs) error: rsync warning: some files vanished before they could be transferred (code 24)at main.c(1183) [sender=3.1.1] Could not rsync from [error] _Workaround_: [Create a Support ticket](/service-offerings/support#contact-acquia-support) and specify the affected files listed in the rsync error. * * * Known issues with the Cloud Platform CDN ---------------------------------------- ### Cloud Platform CDN is not compatible with custom Varnish configurations The Cloud Platform CDN does not support the use of [custom Varnish configurations](/acquia-cloud-platform/performance/varnish/custom) (custom VCLs) with Cloud Platform-hosted applications. Attempting to do so can cause Cloud Platform Enterprise to experience conflicting caching behavior. * * * Other notable known issues -------------------------- ### Self-service SSL certificates overwrite Acquia’s default certificate When requesting the Acquia default domain, the subscriber’s self-service SSL certificate loads instead of the Acquia SSL certificate that covers the Acquia default domains. This behavior causes an SSL error in the browser. Install and activate two or more custom certificates on any affected environment to remove this error on the Acquia default domain. ### Emergency-level logging broadcasts logged data to open SSH sessions If a Drupal module logs information with the [RFC 5424](https://tools.ietf.org/html/rfc5424) severity of `emergency`, syslog broadcasts the information to open SSH sessions. These broadcasts can disrupt commands in progress, as indicated in the following example: Broadcast message from systemd-journald@staging-000.prod.hosting.acquia.com _Workaround_: Either modify the module’s logging function to decrease the message’s severity from `emergency` to another level, or disable the module’s logging feature. ### Some Drupal modules are not supported on Cloud Platform The design of the Acquia platform can sometimes cause incompatibilities with Drupal contributed modules. Drupal modules not supported on Cloud Platform are listed in [Modules and applications incompatible with Cloud Platform](/acquia-cloud-platform/develop-apps/drupal-apps/module-incompatibilities). Other modules usable on Cloud Platform with caution or special configuration are listed in [Modules to use with caution on Cloud Platform](/acquia-cloud-platform/develop-apps/drupal-apps/module-caution). ### You must rebuild caches after updating Drupal Subscribers upgrading their websites to newer versions of the [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version), must rebuild website caches after the upgrading. Unexpected errors and problems with some page displays may occur until you rebuild caches. ### Running `update.php` on the current Drupal version can display error messages Attempting to run `update.php` on the [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version) fails with the following error message: In order to run update.php you need to either be logged in as admin or have set $settings['update_free_access'] _Workaround_: Use one of the following methods: * Run `drush updb` to complete database updates. * Whenever you must run `update.php`, use your browser’s cookie manager to grab the session cookie from your current authenticated Drupal session, and then remove the leading `S` from the session name. * If you are running updates on your Dev or Stage environments, temporarily disable HTTPS while running updates. * Edit your `settings.php` file to temporarily set `$settings['update_free_access']` to `TRUE` during your updates. * **ADVANCED**: Add the following code to your `update.php` file (directly following the `use` statements) to force Drupal to acknowledge the `X-Forwarded-Proto` value when determining if the request must be treated as HTTPS: if (isset($_SERVER["HTTP_X_FORWARDED_PROTO"]) && $_SERVER["HTTP_X_FORWARDED_PROTO"] == "https") { $_SERVER['HTTPS'] = 'on'; } ### Altering the `$databases` array causes connection errors Websites that alter the `$databases` array in `settings.php` to enable third-party database connections may experience connection errors when the connection setup is delayed in `settings.php`. ### You cannot import a local website archive using the product interface The Cloud Platform user interface does not support importing a website archive from a local file. Instead, you can [import a site archive from a URL](/acquia-cloud-platform/create-apps/import/archive/archive-import) or [import using Drush](/acquia-cloud-platform/importing-existing-application-using-drush "Importing an existing application using Drush"). ### All Twig cache files for an environment are stored in a single directory Clearing a website’s Twig caches clears the Twig caches for all websites hosted by that environment. For more information about how Cloud Platform stores Twig caches, visit [Twig caches](/acquia-cloud-platform/manage-apps/files/twig). _Resolution for Site Factory subscribers_: Upgrade your installed version of the [Site Factory Connector module](https://www.drupal.org/project/acsf) to either version 8.x-1.59 and later, or version 8.x-2.59 or later (for Drush 9 support). ### Websites running the current Drupal version can have theme change issues with Twig caches When you change themes and perform a code deployment on Cloud Platform applications running the [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version), you might experience issues where cached [Twig templates](/acquia-cloud-platform/manage-apps/files/twig) fall out of sync on different web infrastructure. The problem arises from having separate copies of the compiled Twig templates on each web infrastructure and a related [Drupal core issue](https://www.drupal.org/node/2752961). _Workaround_: When you make changes to themes in Cloud Platform Enterprise applications running the [current Drupal version](/service-offerings/guide/software-life-cycle#supported-drupal-version), connect to each web infrastructure, and run the following command to remove the outdated Twig templates: drush @[sitename].[prod] --uri=http://[site_URL]/ ev '\Drupal\Core\PhpStorage\PhpStorageFactory::get("twig")->deleteAll();' ### The AuthUserFile directive in .htaccess is not supported The `AuthUserFile` directive in the Apache `.htaccess` file sets the name of a text file containing a list of users and passwords for user authentication. Cloud Platform does not support `AuthUserFile`, since its value must be either an absolute path or a path relative to the infrastructure root, and will not work across different Cloud Platform environments. ### The SymLinksIfOwnerMatch option in .htaccess is not supported Due to the configuration of directory ownership and permissions for your Cloud Platform application’s codebase and files directories, the `SymLinksIfOwnerMatch` option in your application’s `.htaccess` file prevents your web infrastructure from accessing any of the assets in your files directory. You must use the `FollowSymLinks` option instead. ### Previous versions of Cloud Platform used `LOGNAME` differently Do not use the `LOGNAME` environment variable to determine sitegroup or [sitename](/definitions/sitename) in your `.htaccess` file or in other custom scripts. _Workaround_: Use the `AH_SITE_NAME`, `AH_SITE_GROUP`, or `AH_SITE_ENVIRONMENT` [environment variables](/acquia-cloud-platform/develop-apps/env-variable) if you need environment-aware variables in your scripts. ### Using mysqldump on MySQL 5.7 results in error If you run mysqldump on MySQL 5.7, the following error occurs: mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces _Workaround_: If you do not need to dump the tablespace information, invoke `mysqldump` with the _–no-tablespaces_ option. ### Issue with inactive load balancer when using log forwarding When log forwarding is configured with a destination that includes an IP allowlist, the Cloud Platform user interface might display an error message for the inactive load balancer that indicates a connection issue or incorrect configuration. This occurs because the inactive load balancer uses a dynamic IP address until it becomes active. However, log forwarding from the primary or active load balancer functions correctly. ### Issue with Fibers in Drupal 11.3 and later The New Relic APM PHP extension is incompatible with Drupal 11.3 and later due to [missing support](https://docs.newrelic.com/docs/apm/agents/php-agent/getting-started/php-agent-compatibility-requirements/#fibers ) for the [Fibers PHP](https://www.php.net/manual/en/language.fibers.php) feature. Drupal 11.3 and later use Fibers to improve performance. Therefore, requests using Fibers are not displayed accurately in New Relic. Any sub-requests may not be traced, and transaction data may not be accurate. Known issues in Cloud Classic ----------------------------- ### Certain operations fail in PHP 8.4 for FedRAMP applications PHP 8.4 includes OpenSSL 3.x, which has strict TLS security requirements. This impacts all operations that require SSL connectivity. For example, when you attempt to perform system backups in FedRAMP applications, you might get the following error: AWS HTTP error: cURL error 35: TLS connect error: error:03000072:digital envelope routines::decode error _Workaround_: If FIPS is enabled for your application, do not upgrade to PHP 8.4. ### Download link for MySQL slow query logs does not work You might not be able to download the MySQL slow query log through the Cloud Platform user interface. _Workaround_: You can check the MySQL slow query log stream and note the queries that cause issues. When you optimize a few of such queries, the log size is reduced. Thereafter, you can retry downloading the MySQL slow query log. ### Manually deleted backups appear as active in the Cloud Platform user interface for up to 24 hours If you delete a backup manually, the backup continues to appear in the list on the Databases page for about 24 hours. ### Using the Cloud Platform API to download backups with ELBs present results in failures When downloading database backups using the [Cloud Platform API v2](http://cloudapi-docs.acquia.com/), users experience failures if an Elastic Load Balancer (ELB) is present. _Workaround_: If the ELB is not in use, [create a Support ticket](/service-offerings/support#contact-acquia-support) and request to have the ELB removed. ### The server resize Cancel button does not always work as expected In the legacy Cloud Platform interface, when a user selects **Resize** > **Cancel**, occasionally the **Cancel** button does not dismiss the dialog box. ### Database backup downloads fail while using latest version of Chrome For Chrome version 87 or later, [mixed content downloads were disabled](https://blog.chromium.org/2020/02/protecting-users-from-insecure.html). Owing to this, database backup downloads initiated in the Cloud user interface fail in some cases. _Workaround_: The Cloud Platform user interface displays the _http_ version of the db backup download URL. You can specify this URL in a new browser window to restart the download. ### Using Midnight Commander can cause file service interruptions Cloud Platform Enterprise subscribers who use GNU Midnight Commander can experience service interruptions when trying to access their GFS mount. Acquia currently recommends that you do not use Midnight Commander with your Acquia-hosted websites. ### Unable to perform database backups following the VCL access list update After adding an access control list to your [Varnish configuration file](/acquia-cloud-platform/performance/varnish/custom), you may not be able to download database backups through the Cloud user interface. It happens because while limiting access to your sites, your access control list also limits access to your Acquia default domain, such as example.prod.acquia-sites.com, that is required for database downloads to function. To perform database backups: 1. In the access control list of your VCL, add the IP addresses that can download backups. 2. Perform database downloads through the Cloud API. ### Certificate signing requests do not work with Node.js classic applications You cannot generate [certificate signing requests](/acquia-cloud-platform/manage-apps/ssl/csr) (CSRs) for [Node.js classic](/acquia-cloud-platform/add-ons/node-js/node-js-classic "Node JS Classic") applications through the Cloud Platform user interface. _Workaround_: Upload [SSL certificates](/acquia-cloud-platform/manage-apps/ssl/cert) manually. ### Multi-region failover does not support multisites The Cloud Platform [multi-region failover service](/acquia-cloud-platform/manage-apps/multiregion) supports only a single database per environment. ### Issues occur with certain applications and methods after enabling FIPS in Cloud Classic applications When you enable FIPS in a Cloud Classic environment, certain applications and methods might break. For example, Ruby might fail with the following error: `FIPS mode is enabled, bundler can't use the CompactIndex API` _Workaround_: Modify your application to use only FIPS-approved cryptographic methods and avoid using methods like md5 that are prohibited in FIPS. For more information about FIPS-approved cryptographic methods, see [supported methods](https://docs.oracle.com/cd/E36784_01/html/E54953/fips-ok-1.html#scrolltoc). ### Inaccurate storage reporting in the Cloud Platform user interface Stack Metrics in the Cloud Platform user interface might display incorrect storage value. This value might be different from what you see when accessing the platform through SSH. _Workaround:_ Use SSH to access `/mnt/gfs` to get the accurate data. ### SQLite extensions not supported SQLite extensions are not supported on Cloud Platform. Cloud Platform is optimized for a managed MySQL-compatible database layer. Applications that try to use SQLite will encounter compatibility issues or fail to operate within the platform's infrastructure. _Workaround_: Applications that require SQLite must be refactored to use MySQL-compatible databases supported by the platform. ### Service levels and incident handling on Acquia Cloud Platform This issue applies to Cloud Platform customers on shared infrastructure. Cloud Platform is designed for cost-efficiency and flexibility. Because the platform uses shared infrastructure such as shared load balancers, Acquia prioritizes immediate service restoration. To bring sites back online quickly, Support engineers often restart or fail over affected hardware. This process frequently clears the low-level system state needed for a definitive Root Cause Analysis (RCA). You receive an incident summary that describes the restoration steps. However, you might not receive a detailed forensic RCA or a single-fix preventive guarantee. _Workaround_ : While platform architecture cannot be changed at the user level, you can reduce the impact of shared infrastructure incidents through Optimizing application performance by: * Enable Drupal page, block, and view caching. * Review cron jobs, database queries, and queues for long-running operations to improve efficiency. * Avoid uncached external API calls during the request cycle.