To efficiently troubleshoot subscriber websites, update modules, and implement fixes, Acquia Support requires several tools and Drupal modules. The absence of these tools and modules can delay the delivery of Acquia Remote Administration (RA) services.
Acquia’s security update automation has specific requirements. Ensuring your website complies with these requirements will ensure the efficient delivery of security updates.
Access
For Acquia to have access to your websites, be aware of the following:
Subscribers must give Acquia administrative-level access to all systems and accounts required to perform RA tasks.
Acquia will perform RA services from its own premises using remote electronic access to subscriber’s systems and accounts.
Acquia requires access to one or more development or testing servers to ease the testing and deployment of updates in connection with this service.
Acquia will assist with configuring two QA, development or test servers to support the test and deployment process using a code repository and revision control.
Acquia will deploy a Environment for each subscription which is used solely for the deployment of automated security updates by Acquia.
To administer your website from the user interface, Acquia requires an administrative-level user account on your Drupal website.
Acquia requires full access to your Acquia version control system (VCS) repository.
RA has the following requirements for Drupal and its associated modules.
Drupal
The Drupal Core version can be one version behind the latest one, but not older than that. For example, if the latest version is 9.2.x, then 9.1.x is supported, but 9.0.x and earlier are not.
Each RA subscription may contain a single installation of Drupal. Multiple installations of Drupal in one codebase isn’t supported.
The Drupal installation must be located in [reponame]/docroot. A symlinked docroot directory (typically to a vendor or www) is supported.
If you have a multisite that is dedicated to local development, Acquia recommends using a naming convention like [multisite_name].local or using DevDesktop to create a local multisite directory with a name like [multisite_name].dd. If the RA automated update process encounters a multisite directory with a name that ends in .local or .dd, it will not attempt to copy databases for or run Drush commands against these multisites.
Note
If you are using configuration management, ensure that you export the updated configs after Remote Administration provides you with an update branch. You can commit the updated configs to the RA branch and they will be included in the tag that RA creates during Step 2 of the update process.
Module installation
Acquia strongly encourages the implementation of Drupal best practices regarding module installation.
The default location of contributed modules must be [reponame]/docroot/modules for websites running the current Drupal version.
Modules can be sorted into contrib and custom if desired.
Duplicate modules must be avoided unless a particular website must use a specific module version. In this case, the module must be in the website-specific module folder, and must be locked to avoid automated updates.
Required modules
Acquia RA has no specific module requirements for receiving updates. However, to assist with troubleshooting after the updates are applied, Acquia recommends enabling or installing the Syslog core module and it’s dependencies on each multisite in the Production environment, where you want RA to check for outstanding security updates.
As RA doesn’t cover modified core or contributed modules, Acquia recommends you implement any customizations using custom modules or theming files. This allows the RA team to implement updates, while allowing the subscriber development team to change custom code without any loss of modifications.
If your website requires modification of Drupal core, or contributed modules, refer to Patching and locking modules to ensure your website remains compatible with Acquia security updates.
Drush
Drush is required by RA automation to apply database updates for websites running the current Drupal version. Acquia Support also uses Drush to troubleshoot and scan websites. Drush is required to work on all environments without error.
Any of the following items must not interfere with running Drush commands (such as drushpm-updatestatus or drushpm-updatecode):
custom themes
custom modules
customizations to the settings.php or sites.php files
customizations to contributed modules
Installations of the current Drupal version requires Drush 10 installation and configuration in the website’s codebase. A symlink to Drush must be present in vendor/bin if you have installed Drush using Composer.
Composer
The current Drupal version, contributed modules, and distributions are increasingly reliant on Composer to manage dependencies. Although Drush will continue to be used to detect insecure modules, only Composer builds and updates will ensure dependencies are included in any Drupal core or contributed module update.
When updating a website running the current Drupal version, the automated update process requires a functional composer.json file located above the docroot directory that includes references to all your website dependencies like Drupal core and contributed modules. Acquia doesn’t recommend changing the composer.json or vendor/ directory located inside of the docroot directory unless you are removing them. See Acquia Automation: Composer builds for a full explanation of requirements.
Special considerations for Site Factory
During the initial RA setup process, Site Factory subscribers must give the RA team a list of five to ten domain names to be staged during future RA updates. To speed up delivery, the RA team will stage only the requested websites.
To change the domains staged during RA updates at least two business days before a planned update, contact Acquia Support to give your list of domain names.
Repository size
Acquia recommends that you keep your Git repository as small as possible. The RA service clones repositories as part of the update process. Smaller repositories are faster to clone and easier to work with and maintain. Individual files in a repository should be limited 100 MB. If the size of the repository is larger than 2 GB, it can take a long time to backup or copy the database. To keep the overall size of the repository down, clear unnecessary or outdated files and commit history from the repository.
RA environments are provisioned on shared hardware with limited space. Maintaining a small, efficient Git repository is essential to RA’s ability to issue an update branch in a timely fashion. If an RA server is nearing capacity due to a large Git repository, the RA update process will not complete. This can prevent you from receiving RA security updates. You should periodically review the size of your Git repository to ensure that it is as small as possible.
Acquia delivers RA services in English only. For multilingual websites, you must ensure the administrative back end for Drupal is in English. This will improve Acquia’s efficiency in troubleshooting and updating your website.
Continuous integration
Acquia RA can’t support websites using continuous integration (CI) development practices, such as Pipelines, Jenkins, and Travis, where build artifacts are pushed to the Acquia-hosted Git repository. RA performs repository updates and examines tags for subscriber production code, and these processes aren’t compatible with continuous integration.
Acquia recommends you either ignore or decline automated update branches provided by RA Automation. To receive notifications about available security updates when they’re released, set your RA preferences to Inform only.
Version control system
To track changes to your code, RA requires subscribers to use Git. RA won’t change code without Git in place. Acquia provides Acquia-hosted subscribers a full repository of their choice.
Acquia RA doesn’t support updates to websites that include private external Git repositories in their composer.json. Private external Git repositories are repos that require authentication in order to access them.
Non-Acquia environments
Acquia doesn’t offer RA services to subscribers who aren’t on the Cloud Platform.
Cloud Next
The Acquia database include statement is required in the settings.php file for each multisite in the sites directory. For more information, see Working with databases.
Cloud Platform creates the AURABot user in your organanization-level team called RA-BOT-team. This user is required for the smooth functioning of the Remote Administration service that provides Drupal security updates to your Cloud Next environments on a weekly basis. Ensure that you do not delete this user.
Requirements
To efficiently troubleshoot subscriber websites, update modules, and implement fixes, Acquia Support requires several tools and Drupal modules. The absence of these tools and modules can delay the delivery of Acquia Remote Administration (RA) services.
Acquia’s security update automation has specific requirements. Ensuring your website complies with these requirements will ensure the efficient delivery of security updates.
Access
For Acquia to have access to your websites, be aware of the following:
Subscribers must give Acquia administrative-level access to all systems and accounts required to perform RA tasks.
Acquia will perform RA services from its own premises using remote electronic access to subscriber’s systems and accounts.
Acquia requires access to one or more development or testing servers to ease the testing and deployment of updates in connection with this service.
Acquia will assist with configuring two QA, development or test servers to support the test and deployment process using a code repository and revision control.
Acquia will deploy a Environment for each subscription which is used solely for the deployment of automated security updates by Acquia.
To administer your website from the user interface, Acquia requires an administrative-level user account on your Drupal website.
Acquia requires full access to your Acquia version control system (VCS) repository.
RA has the following requirements for Drupal and its associated modules.
Drupal
The Drupal Core version can be one version behind the latest one, but not older than that. For example, if the latest version is 9.2.x, then 9.1.x is supported, but 9.0.x and earlier are not.
Each RA subscription may contain a single installation of Drupal. Multiple installations of Drupal in one codebase isn’t supported.
The Drupal installation must be located in [reponame]/docroot. A symlinked docroot directory (typically to a vendor or www) is supported.
If you have a multisite that is dedicated to local development, Acquia recommends using a naming convention like [multisite_name].local or using DevDesktop to create a local multisite directory with a name like [multisite_name].dd. If the RA automated update process encounters a multisite directory with a name that ends in .local or .dd, it will not attempt to copy databases for or run Drush commands against these multisites.
Note
If you are using configuration management, ensure that you export the updated configs after Remote Administration provides you with an update branch. You can commit the updated configs to the RA branch and they will be included in the tag that RA creates during Step 2 of the update process.
Module installation
Acquia strongly encourages the implementation of Drupal best practices regarding module installation.
The default location of contributed modules must be [reponame]/docroot/modules for websites running the current Drupal version.
Modules can be sorted into contrib and custom if desired.
Duplicate modules must be avoided unless a particular website must use a specific module version. In this case, the module must be in the website-specific module folder, and must be locked to avoid automated updates.
Required modules
Acquia RA has no specific module requirements for receiving updates. However, to assist with troubleshooting after the updates are applied, Acquia recommends enabling or installing the Syslog core module and it’s dependencies on each multisite in the Production environment, where you want RA to check for outstanding security updates.
As RA doesn’t cover modified core or contributed modules, Acquia recommends you implement any customizations using custom modules or theming files. This allows the RA team to implement updates, while allowing the subscriber development team to change custom code without any loss of modifications.
If your website requires modification of Drupal core, or contributed modules, refer to Patching and locking modules to ensure your website remains compatible with Acquia security updates.
Drush
Drush is required by RA automation to apply database updates for websites running the current Drupal version. Acquia Support also uses Drush to troubleshoot and scan websites. Drush is required to work on all environments without error.
Any of the following items must not interfere with running Drush commands (such as drushpm-updatestatus or drushpm-updatecode):
custom themes
custom modules
customizations to the settings.php or sites.php files
customizations to contributed modules
Installations of the current Drupal version requires Drush 10 installation and configuration in the website’s codebase. A symlink to Drush must be present in vendor/bin if you have installed Drush using Composer.
Composer
The current Drupal version, contributed modules, and distributions are increasingly reliant on Composer to manage dependencies. Although Drush will continue to be used to detect insecure modules, only Composer builds and updates will ensure dependencies are included in any Drupal core or contributed module update.
When updating a website running the current Drupal version, the automated update process requires a functional composer.json file located above the docroot directory that includes references to all your website dependencies like Drupal core and contributed modules. Acquia doesn’t recommend changing the composer.json or vendor/ directory located inside of the docroot directory unless you are removing them. See Acquia Automation: Composer builds for a full explanation of requirements.
Special considerations for Site Factory
During the initial RA setup process, Site Factory subscribers must give the RA team a list of five to ten domain names to be staged during future RA updates. To speed up delivery, the RA team will stage only the requested websites.
To change the domains staged during RA updates at least two business days before a planned update, contact Acquia Support to give your list of domain names.
Repository size
Acquia recommends that you keep your Git repository as small as possible. The RA service clones repositories as part of the update process. Smaller repositories are faster to clone and easier to work with and maintain. Individual files in a repository should be limited 100 MB. If the size of the repository is larger than 2 GB, it can take a long time to backup or copy the database. To keep the overall size of the repository down, clear unnecessary or outdated files and commit history from the repository.
RA environments are provisioned on shared hardware with limited space. Maintaining a small, efficient Git repository is essential to RA’s ability to issue an update branch in a timely fashion. If an RA server is nearing capacity due to a large Git repository, the RA update process will not complete. This can prevent you from receiving RA security updates. You should periodically review the size of your Git repository to ensure that it is as small as possible.
Acquia delivers RA services in English only. For multilingual websites, you must ensure the administrative back end for Drupal is in English. This will improve Acquia’s efficiency in troubleshooting and updating your website.
Continuous integration
Acquia RA can’t support websites using continuous integration (CI) development practices, such as Pipelines, Jenkins, and Travis, where build artifacts are pushed to the Acquia-hosted Git repository. RA performs repository updates and examines tags for subscriber production code, and these processes aren’t compatible with continuous integration.
Acquia recommends you either ignore or decline automated update branches provided by RA Automation. To receive notifications about available security updates when they’re released, set your RA preferences to Inform only.
Version control system
To track changes to your code, RA requires subscribers to use Git. RA won’t change code without Git in place. Acquia provides Acquia-hosted subscribers a full repository of their choice.
Acquia RA doesn’t support updates to websites that include private external Git repositories in their composer.json. Private external Git repositories are repos that require authentication in order to access them.
Non-Acquia environments
Acquia doesn’t offer RA services to subscribers who aren’t on the Cloud Platform.
Cloud Next
The Acquia database include statement is required in the settings.php file for each multisite in the sites directory. For more information, see Working with databases.
Cloud Platform creates the AURABot user in your organanization-level team called RA-BOT-team. This user is required for the smooth functioning of the Remote Administration service that provides Drupal security updates to your Cloud Next environments on a weekly basis. Ensure that you do not delete this user.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Requirements | Acquia Product Documentation
Cloud Platform
Requirements
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform