Information for: DEVELOPERS   PARTNERS

Known issues in Cloud Platform

This page describes known issues in Cloud Platform:

Known Issues on Acquia Cloud Next

  • Users who have MySQL Workbench installed locally cannot connect to environments on Acquia Cloud Next. Users running Sequel Pro locally are not impacted.


    1. Locate the database credentials listed on your Databases page.

    2. In a local terminal, run: {ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}


      • LOCAL_PORT is the port to which Workbench must connect when using localhost.
      • DB_HOST is the hostname obtained from the Acquia Cloud Platform user interface.
      • SSH_STRING is the full connection string from the Acquia Cloud Platform user interface. For example, user@something.
  • MySQL databases shouldn’t exceed 10 GB in size. This is a temporary restriction.

  • Long Code Deployment Times: Environments on Acquia Cloud Next may intermittently experience code deployment times taking more than five minutes.

Known issues with PHP and Memcache

Log formatting changes to multi-line when switching from PHP 7.2 to PHP 7.3

When switching from PHP 7.2 to PHP 7.3, some subscribers experience log formatting changes from single line to multi-line formatting which impacts log forwarding endpoints and debugging issues.

Some versions of the Rules Conditional module are incompatible with PHP 7.2

After upgrading to PHP 7.2, Drupal 7.x applications using the Conditional Rules module display errors similar to the following:

PHP Fatal error:  Declaration of RulesRuleUI::form(&$form, &$form_state, $options = Array) must be compatible with RulesActionContainerUI::form(&$form, &$form_state, $options = Array, $iterator = NULL)

Workaround: Upgrade to the 7.x-1.0 version of the Conditional Rules module. For more information, see issue #2959426 on

Older versions of Drupal 7 are incompatible with PHP 7.2

Only Drupal 7 versions of 7.61 or greater are compatible with PHP 7.2. When you create or import a Drupal 7 website on Cloud Platform, ensure you select a compatible version of PHP.

Memcache configuration and upgrades for Drupal 8 and Drupal 9 require additional steps

Although Acquia recommends the use of the Memcache API and Integration module with Drupal 8 and Drupal 9 applications, the module is undergoing rapid development. Before you upgrade the Memcache API and Integration module, review Using Memcached and the README.txt file in with the module for updated installation and configuration instructions.

PHP 7 deprecates the memcache class

The php-memcached extension provides Memcached support in PHP 7 environments, and the memcached PHP class for interacting with Memcached storage. The extension does not provide the memcache (no d) class previously provided by the PECL memcache extension in PHP 5.x environments.

This change will not affect most users, as the Memcache API and Integration module supports both classes. However, your application may use other tools relying on the deprecated memcache class, which can cause website issues if you upgrade PHP to version 7. SimpleSAMLPHP, for example, is still affected by this issue.

Using SimpleSAMLphp with PHP 7.2 displays errors in log files

Using SimpleSAMLphp on a website hosted on Cloud Platform using PHP 7.2 may see entries in their PHP log files similar to:

PHP Deprecated: The each() function is deprecated. This message will be suppressed on further calls.

These warnings are harmless and will be removed in a future release of Cloud Platform.

Known issues in the Cloud Platform user interface

Cloud Platform notification API doesn’t display real-time results

The Cloud Platform notification API doesn’t 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.

Using the Cloud Platform API to download backups with ELBs present results in failures

When downloading database backups using the Cloud Platform API v2, users will experience failures if an Elastic Load Balancer (ELB) is present.

Workaround: If the ELB isn’t in use, file a Support ticket and request to have the ELB removed.

The server resize Cancel button does not always work as expected

In the legacy Acquia Cloud Platform interface, when a user selects Resize > Cancel, occasionally the Cancel button does not dismiss the dialog box.

XML is not an acceptable file type in Support tickets

The acceptable file listing on the customer-facing ticket submission page 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 can’t be changed

The active domain for an environment defaults to the first bare domain name, with or without the www prefix, and cannot be changed. Environments containing no top-level custom domains use the Acquia default domain as the active domain.

Environment variables starting with $ followed by a number are removed

When using environment variables 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 using the environment variable in your code, manually prepend the first two characters to the variable. Acquia recommends validating your code to prevent any application issues when the issue is resolved.

Database backup downloads fail while using latest version of Chrome

For Chrome version 87 or later, mixed content downloads were disabled. Owing to this, database backup downloads initiated in the Acquia Cloud user interface fail in some cases.

Workaround: Cloud 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.

Known issues with version control

Unicode characters and emoji are not supported in branch names

If a branch name contains a Unicode character, such as an emoji, users will receive a Failure due to fatal system error message when attempting to switch to that branch. This error affects all Cloud Platform systems, including the pipelines feature.

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 beginning 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 can’t be deleted

Cloud Platform doesn’t allow you to delete branches 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

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

Contact Acquia support to correct the directory’s ownership settings.

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.

Known issues with the Acquia Connector

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 reverting to Acquia Connector 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 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, causing some requests to timeout.

Workaround: If your subscription service is experiencing timeouts, Acquia recommends you modify your cron runs 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 module, which is listed on the Modules to use with caution on Cloud Platform page.

Workaround: Apply this patch, available on

Known issues with Drush

Errors seen while running SQL queries using Drush 8 on Drupal 7 with MySQL 5.7

If you are using Drush 8 on Drupal 7 with MySQL 5.7, you might get errors while running SQL queries. This is because MySQL 5.7 doesn’t allow using certain reserved keywords in SQL queries.

Workaround: Ensure that your SQL Query doesn’t include any of the reserved keywords. See MySQL 5.7 Keywords and Reserved Words.

You cannot use Drush to update your Drupal 8.4 or greater websites

You must use Composer to build websites running Drupal versions 8.4 or later. Updating using Drush will no longer be possible.

Using vendored Drush may disable some Drush commands

Including Drush in a Cloud Platform application branch may create a conflict between the version installed in the vendor directory and the version installed in Cloud Platform, disabling some Drush commands. Most notably, it disables Install distribution, which allows you to install a different version of Drupal into the deployed branch.

Workaround: Modify the existing branch by removing Drush from the branch you want to install a Drupal distribution into, or create a new branch without the Drush dependency.

Drush is generally found in one of the following directories:

  • vendor/drush
  • docroot/vendor/drush

You can use Composer to remove Drush by executing the following command:

composer remove drush/drush

See Vendored Drush known issue for additional details.

Drush 9 and greater are incompatible with certain Acquia Drush commands

For Drupal 8 websites, the following Drush commands require you to use Drush 8 instead of Drush 9:

These commands may not work with Drupal 9 applications, and require you to run drush8 from a directory outside of your docroot, after using SSH to access your Cloud Platform environment.

Drush 9 and Drush 10 support only websites built with Composer

Drush 9 and Drush 10 both require your Drupal 8 or Drupal 9 website to be built with Composer, with Drush listed as a dependency.

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]'
  • 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 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 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.

Known issues with external services

New Drupal 8 and Drupal 9 Composer builds fail due to vendor dependency

Composer builds for Drupal 8 and Drupal 9 were failing due to a problem with the behat/mink-selenium2-driver vendor dependency required by Drupal.

Workaround: Remove the previous workaround, which recommended pinning to the 1.3.x-dev version of the vendored software. For more information, see this Acquia knowledge base article and issue #3078671 on

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, see: Transition from legacy alerting to New Relic Alerts and Availability monitoring (legacy).

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.

Website duplication may cause rsync issues

Website duplication can cause rsync issues in the distributed file system which results in the following log 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: Contact Acquia Support and specify the affected files listed in the rsync error.

Known issues with the Cloud Platform pipelines feature

For issues with Cloud Platform CD, see Known issues in Cloud Platform CD.

The Acquia Cloud pipelines UI doesn’t work with IP allowlisting enabled

The Acquia Cloud pipelines user interface uses a user authentication system incompatible with IP address allowlisting.

Workaround: If you are using IP address allowlisting you must use pipelines from the command line, instead of the user interface.

Custom IdP authentication causes 403 error on Cloud Platform pipelines feature

Users authenticated into using custom identity provider integration receive a 403 error when attempting to authenticate into the Cloud Platform pipelines UI feature and the pipelines client/CLI.

You can connect the Cloud Platform pipelines feature only to repositories owned by the current Bitbucket user

The Bitbucket permissions model requires that the current user own the repository and all of the code being deployed. Users may be unable to add branches from external pull requests or experience other issues.

The Cloud Platform pipelines feature is incompatible with Bitbucket infrastructure

The Cloud Platform pipelines feature works only with Bitbucket Cloud, and not Bitbucket infrastructure.

The Bitbucket API has known issues with forks

The API for Bitbucket does not allow you to pull in the branch from a fork inside a pull request.

The Bitbucket API only allows collaborators to see branches

You must add a user as a collaborator to your fork to see the user’s branches.

Deleting pull request branches on merge causes pipelines errors

Bitbucket has an optional setting to automatically delete pull request branches after pull requests are merged. This will cause the pr-merged event in pipelines to fail with an error:

Failed to parse the build file. The VCS path [feature/branch] was not found
in git repository.

Bitbucket commits must be linked to an active Bitbucket user

Bitbucket uses the username and email address associated with a Git commit to associate the commit with a Bitbucket user account. If no user is associated with a commit, Pipelines will fail with an error:

webhook start failed to start pipeline for app [app]. Operation failed with
the following details: Payload do not have the following required

Workaround: Ensure the username and email attached to the commit is associated with a Bitbucket user account.

Pipelines jobs fail if they contain SSH keys generated by OpenSSH version 7.8 or greater

OpenSSH version 7.8 now generates RSA key pairs with a default format incompatible with the Cloud Platform pipelines feature. Pipelines jobs that include a SSH key generated in the default format by these versions of OpenSSH in the ssh-keys section of the build definition file will fail with the following error:

Failed to parse the build file. The SSH key named [KEY NAME] is not a valid
SSH private key or requires a password.

Workaround: Generate a key using a format compatible with pipelines jobs:

ssh-keygen -m PEM -t rsa -b 4096

Linked repository cannot be changed if GitHub personal access token is revoked

Pipelines allows you to link repositories to the service to trigger new Pipelines jobs using webhooks.

If you’ve linked Pipelines to a GitHub repository and later revoke the GitHub personal access token used by Pipelines, trying to change the linked Pipelines repository will result in an error: “Please ensure your personal access token is valid. Failed to remove webhook.”

Workaround: Use the Pipeline CLI to reconnect to GitHub, or reconnect GitHub by directly visiting the linking page at the following URL, replacing my-application-id with your application ID:

Known issues with the Cloud Platform CDN

Cloud Platform CDN is not compatible with Node.js

The Cloud Platform CDN is incompatible with Node.js applications.

Cloud Platform CDN is not compatible with custom Varnish configurations

The Cloud Platform CDN does not support the use of custom Varnish configurations (custom VCLs) with Cloud Platform-hosted applications. Attempting to do so can cause Cloud Platform Enterprise to experience conflicting caching behavior.

Unable to perform database backups following the VCL access list update

After adding an access control list to your Varnish configuration file, 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, that is required for database downloads to function.

To perform database backups, do the following:

  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.

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.

Certificate signing requests don’t work with Node.js applications

You can’t generate certificate signing requests (CSRs) for Node.js applications from the Cloud Platform user interface.

Workaround: Upload SSL certificates manually.

Emergency-level logging broadcasts logged data to open SSH sessions

If a Drupal module logs information with the RFC 5424 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 [email protected]

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.

Multi-region failover does not support multisites

The Cloud Platform multi-region failover service supports only a single database per environment.

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. Other modules usable on Cloud Platform with caution or special configuration are listed in Modules to use with caution on Cloud Platform. For information about other software incompatible with Cloud Platform, see Unsupported software.

You must rebuild caches after updating Drupal

Subscribers upgrading their websites to newer versions of Drupal 8, or Drupal 9, 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 Drupal 8 or Drupal 9 can display error messages

Attempting to run update.php on Drupal 8 or Drupal 9 will fail 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 altering 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 interface does not support importing a website archive from a local file using the UI. Instead, you can import a site archive from a URL or import 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, see Twig caches.

Resolution for Site Factory subscribers: Upgrade your installed version of the Site Factory Connector module to either version 8.x-1.59 or greater, or version 8.x-2.59 or greater (for Drush 9 support).

Drupal 8 and Drupal 9 websites can have theme change issues with Twig caches

Drupal 8 and Drupal 9 applications on Cloud Platform Enterprise can experience issues where cached Twig templates fall out of sync on different web infrastructure when changing themes and performing a code deployment. The problem arises from having separate copies of the compiled Twig templates on each web infrastructure and a related Drupal core issue.

Workaround: When you make changes to themes in Drupal 8 or Drupal 9 applications on Cloud Platform Enterprise, connect to each web infrastructure, and then run a command like the following 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 won’t 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, use of the SymLinksIfOwnerMatch option in your application’s .htaccess file will prevent 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 in your .htaccess file or in other custom scripts.

Workaround: Use the AH_SITE_NAME, AH_SITE_GROUP, or AH_SITE_ENVIRONMENT environment variables 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 don’t need to dump the tablespace information, invoke mysqldump with the –no-tablespaces option.