Cloud Platform
Preparing for a successful launch
Prior to launching your site, ensure the following:
In addition to the preceding best practices, follow the subsequent detailed checklist that can help you track the tasks you must complete to successfully launch an application on the Cloud Platform.
The following tasks are common requirements for building an application that supports SSL. These steps may or may not be required if you are using a CDN in front of your site on Acquia Cloud.
| Task | Why | Documentation |
|---|---|---|
| Generate Certificate Signing Request (CSR) | A CSR is required to buy an SSL certificate. If you have already purchased an SSL certificate, you can skip this step. | Generating a certificate signing request (CSR) |
| Upload SSL certificate | If there is no SSL installed, your website will throw an error when accessed over HTTPS. | Managing SSL certificates |
| Check rewrite rules are configured (using a contributed module or .htaccess file) | Your application’s .htaccess file controls how your website’s visitors can access your website and can be configured to handle many different visitor scenarios. | Introduction to .htaccess rewrite rules |
The following performance and scalability tasks prepare your application for production traffic.
| Task | Why | Documentation |
|---|---|---|
| Perform final content migration | After content freeze, migrate content one last time, if applicable. | |
| Delete test content | Delete or verify the deletion of any test content. | |
| Index content | After content freeze, index content for Acquia Search. | |
| Verify Search | Make sure search is working properly on production. | |
| Identify missing content/assets and broken links | Consider using the link checker module or use some other crawler. | Link checker | Drupal.org |
| 404 Remediation | Resolve 404s (add missing content/assets, update broken links, etc.). | |
| 301 Remediation | Create redirects as needed (Redirect module, .htaccess rules, etc.). | Redirect | Drupal.org |
| Configure sitemap | Set up and configure a module like Sitemap XML to serve. | XML sitemap | Drupal.org |
| 404 handling |
| Task | Why | Documentation |
|---|---|---|
| Configure Teams and Permissions | Ensure that everyone that needs access to Acquia Cloud has the necessary permissions. | Managing team members |
| Configure Drupal cron using Scheduled jobs | Set up the necessary cron jobs for your application to perform regular system maintenance and scheduled tasks. | Using scheduled jobs to support your application |
| Configure New Relic | To see application performance metrics for requests that reach Drupal. | Claiming your New Relic APM Pro account |
| Configure Platform Email | Allow your application to send outbound email on verified domain names. | Configuring Platform Email |
| Task | Why | Documentation |
|---|---|---|
| Address issues identified in the Site Review | Site Review is provided by Acquia Support or your TAM. | |
| Address issues identified in Drupal Status Report | Check /admin/reports/status. | |
| Cache test | Verify pages have correct cache headers. | Caching Score |
| Front end performance testing | Use PageSpeed Insights, YSlow, and WebPageTest. | PageSpeed Insights | YSlow | WebPageTest |
| Load testing | Confirm estimated monthly page views and load test data to make sure infrastructure is sized properly. Use a tool like BlazeMeter. | Load testing on Cloud Platform | BlazeMeter |
| Check logs for errors and notices | Resolve any errors and notices. | About Cloud Platform logging |
| Task | Why | Documentation |
|---|---|---|
| Identify DNS owner | Determine who has the authority/ability to manage DNS. | Configuring DNS records for your application |
| Verify Domains and DNS | Make sure Domains and DNS info have been identified. | Managing domains |
| Verify edit domain | Ensure the edit domain is functional for content admins. | Best practices on setting up an edit domain |
| Set a short TTL for DNS | If using an existing domain, ensure the TTL is set to 5 minutes prior to launch. This ensures a quick launch process. | Set a short TTL for DNS |
| Task | Why | Documentation |
|---|---|---|
| Submit a Site Review ticket (2+ weeks before website launch) | The Site Review will be conducted by Acquia once you confirm you have launch-ready code in the production environment. | Contact Acquia Support |
| Set page cache maximum age to something greater than “no caching” | Varnish® won’t cache your standard page requests from Drupal if page cache maximum age isn’t set. This may cause severe strain on infrastructure, resulting in degraded performance and potential website downtime. | Configuring Drupal cache settings for Varnish |
| Enable & configure Acquia Purge module | Acquia Purge is essential for proactively clearing stale content from Varnish® cache and Platform CDN caches, if applicable. | Purging Varnish cache on Acquia Cloud |
| Disable basic authentication so Acquia can check that Varnish is serving pages from cache | With basic authentication enabled (typically using the Shield module), you can’t check whether Varnish caching is working. | Password-protecting non-production environments |
| Update Drupal Core to the latest release |
These configuration tasks configure preferences and connect your application to Acquia services.
| Task | Why | Documentation |
|---|---|---|
| Add custom domains | If there are no custom domains present, domains do not resolve when DNS is updated. Include the bare domain if necessary. | Managing domains |
| Configure Remote Administration preferences | Setting your application update preferences correctly ensures security updates can be integrated into your workflow. | Remote Administration Preferences |
These tasks prepare your application for an imminent launch.
| Task | Why | Documentation |
|---|---|---|
| Remove Prod environment site protection | Disable basic auth (Shield module) or remove IP whitelists. | Password-protecting non-production environments |
| Warm Caches using /etc/hosts and Prod domain | Configure /etc/hosts and navigate the site as anonymous to cache popular pages. | Avoiding maintenance mode during site updates |
| Clear the Varnish cache on your production environment | Clearing cache on your production environment will allow the most recent website changes to be reflected. | Using Varnish |
| Back up the database on your production environment | For recovery purposes. In the event of a disaster, you can retrieve the most current version of your database readily. | Taking backups |
| Enable Production mode | Lack of a production mode leads to a heightened possibility of destroying your live application by overwriting your production files and databases. | Using Production mode to protect your live application |
These items should be checked and verified once the site has been moved to production.
| Task | Notes | Documentation |
|---|---|---|
| Check Drupal’s status report | Go to Reports > Status report. | |
| Verify analytics tracking is working | ||
| Verify third-party integrations are working | Any external app or service that interacts with Drupal needs to be verified. | |
| Monitor New Relic | File an Acquia Support case with any concerns. Paste a permalink to what you see in New Relic in the case. | Using New Relic to troubleshoot site issues |
| Monitor Stack Metrics | Verify that infrastructure metrics are good. | Using Stack Metrics to monitor activity on your environments |
| Request Traffic Report | Acquia Support can provide a traffic report upon request. This shows the top 200, 30x, 40x, and 50x requests. | Contact Acquia Support |
| Verify 301 redirects | Make sure redirects are working properly. | Redirects |
In case there are unforeseen or unplanned issues, the steps below can be followed to revert the launch and go back to using the old site.
| Task | Notes | Documentation |
|---|---|---|
| Change DNS | Point DNS back to the original site. | |
| Revert 301 Redirects | Redirect | |
| Enable the Shield module on Prod environment | ||
| Flush Varnish cache | Flushing Varnish prevents the site from being displayed even though the Shield module is enabled. | Using Varnish |
| Notify necessary parties of postponed launch |
| Create a plan for remediating 404s post-launch. |
| Redirect | Drupal.org |
| Accessibility testing | Review site for accessibility compliance. | Website Content Optimization & Governance Platform |
| Security vulnerabilities leave your website more susceptible to attacks, and so on. |
|
| Disable any modules that set session cookies | Session cookies can prevent Varnish from working properly and lead to severe performance issues. This will be checked in an Acquia Site Review. | Using Varnish |
| Don’t override the PHP memory limit on a global basis. Consider conditionally increasing memory limits for specific pages that need more memory | Acquia tunes its infrastructure to use the exact number of threads possible for 128 MB of PHP memory. If your application needs more memory for every page request, create a Support ticket. Conditionally overriding the memory limit for certain administration pages can sometimes be acceptable, but check with Acquia Support before adding this. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Configure Memcache to help with overall website performance | The lack of Memcached can lead to a heavy load on the database infrastructure, therefore resulting in degraded performance. | Enabling Memcached on Cloud Platform |
| Enable the Dynamic Page Cache module | Dynamic Page Cache may increase the speed of your website, even for authenticated users. It’s the second line of defense after reverse-proxy caching (Varnish) and will keep user requests from overwhelming your website until the latter is warmed up. |
| Enable JavaScript / CSS aggregation | CSS and JavaScript files can cause extended page load times because it is loading all the files for each. This can slow down page rendering. | Improving application performance |
| Disable Watchdog database logging module | The DBlog module (watchdog) writes logs to the database, which can cause a major strain on storage and memory. |
| Enable the Syslog module | Syslog should be used in favor of DBLog. It can store logs much faster because it doesn’t need to write to the database. | About Cloud Platform logging |
| Check for pending database updates | Depending on the functionality, issues can compound over time if left unaddressed. This is important for critical/core business functionality. |
| Enable full PHP error reporting | Failure to log problems caused by faults in PHP can cripple your ability to troubleshoot an issue. | PHP error logs |
| Check for and Remove SQL queries and PHP logic or functions in templates | Going against the Drupal architecture can cause performance problems, such as SQL queries should not exist in Drupal templates such as node--xxx.tpl.php. |
| Back up Stage and Prod database | For recovery purposes. In the event of a disaster, you can quickly retrieve the most current version of your database. | Taking backups |
| Clear Stage Varnish caches | Clearing cache on your staging website will allow the most recent website changes to be reflected. | Using Varnish |
| Migrate Stage code to Prod | Without code in your production environment, there will be no live website. | Code workflows with Cloud Platform |
| Migrate Stage files to Prod | Without files in your production environment, there will be no live website. For more information, see Copying files between environments. | Working with files | Cloud Platform |
| Migrate Stage database to Prod | Without a database in your production environment, there will be no live website. For more information, see Copying a database across environments. | Working with databases |
| Review areas of codebase using infrastructure-side device detection to confirm caching isn’t impacted or remove entirely | If the website is relying on infrastructure-side device detection for anonymous visitors, you may find pages are improperly caching for a single device. | Varnish headers |
| Configure OPCache to be large enough to store compiled code for your applications’ PHP scripts | If OPCache usage is too high, you may experience memory allocation and other associated OPCache errors. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Ensure directories don’t contain more than 2,500 files each | Website performance can severely degrade when too many files are added and available to the system in a single directory without any subdirectory structure. | Proactively organizing files in subfolders |
| Identify and remediate potential issues from having large image files | Image processing can be complex and can put a major hit on website resources (for example, memory). Underestimating the memory usage of these processes can have severe impacts on the responsiveness of your website. | Scoping the impact of image processing |
| Disable or adjust settings for modules and applications | Cloud Platform and security require permissions and installs to be built in a particular fashion. This can sometimes cause incompatibilities with Drupal contributed modules. | Modules and applications incompatible with Cloud Platform |
| Switch from Drupal database search to Acquia Search | This can cause availability issues for websites in association with increased database activity, and is considered redundant and inferior to search backed by Acquia Search. | Acquia Search |
| Enable caching on blocks, views, and panels where applicable | While Varnish cache will take a significant load off your website, Drupal-level granular caching can provide more performance benefits in many situations. |
| Disable default Drupal cron in favor of Acquia’s scheduled jobs | Compared to other cron solutions, using the Scheduled Jobs page is more reliable and provides extensive and integrated logging for Cloud Platform applications; disable the automatic cron module. | Using scheduled jobs to support your application |
| Disable unneeded modules (SimpleTest, Statistics, Devel, Mobile Tools) in Production | These modules can increase the website’s startup (bootstrap) overhead and are unnecessary in Production. |
| Disable user interface modules (views_ui and field_ui) | Can impose a small performance penalty when enabled, and can allow the essential views/fields required by your website to be modified. https://Blocking unwanted traffic on your website |
| Identify and Block Nuisance Bots | Nuisance bots disrupt site analytics and create an impact on your infrastructure utilization. Block unwanted traffic with a WAF. Add such nuisance bots to .htaccess to keep unnecessary traffic at bay. | Blocking unwanted traffic on your website |
| Check that domains and DNS are pointed correctly | Your website do not resolve to the Acquia platform unless you update your DNS settings with your Acquia IP address. | Configuring DNS records for your application |
| Enable legacy 301 Redirects | Enable 301 redirects from legacy URLs/services/sites to the new site. | Redirect |
| Notify search engines of the site | Such as Google Webmaster Tools. | Google Search Console |
| Verify emails are being sending correctly | Troubleshooting Platform Email |
| Verify cron jobs are executing properly | Using scheduled jobs to support your application |
If this content did not answer your questions, try searching or contacting our support team for further assistance.
| Generating a certificate signing request (CSR) |
| Upload SSL certificate | If there is no SSL installed, your website will throw an error when accessed over HTTPS. | Managing SSL certificates |
| Check rewrite rules are configured (using a contributed module or .htaccess file) | Your application’s .htaccess file controls how your website’s visitors can access your website and can be configured to handle many different visitor scenarios. | Introduction to .htaccess rewrite rules |
The following performance and scalability tasks prepare your application for production traffic.
| Task | Why | Documentation |
|---|---|---|
| Perform final content migration | After content freeze, migrate content one last time, if applicable. | |
| Delete test content | Delete or verify the deletion of any test content. | |
| Index content | After content freeze, index content for Acquia Search. | |
| Verify Search | Make sure search is working properly on production. | |
| Identify missing content/assets and broken links | Consider using the link checker module or use some other crawler. | Link checker | Drupal.org |
| 404 Remediation | Resolve 404s (add missing content/assets, update broken links, etc.). | |
| 301 Remediation | Create redirects as needed (Redirect module, .htaccess rules, etc.). | Redirect | Drupal.org |
| Configure sitemap | Set up and configure a module like Sitemap XML to serve. | XML sitemap | Drupal.org |
| 404 handling | Create a plan for remediating 404s post-launch. | Redirect | Drupal.org |
| Task | Why | Documentation |
|---|---|---|
| Configure Teams and Permissions | Ensure that everyone that needs access to Acquia Cloud has the necessary permissions. | Managing team members |
| Configure Drupal cron using Scheduled jobs | Set up the necessary cron jobs for your application to perform regular system maintenance and scheduled tasks. | Using scheduled jobs to support your application |
| Configure New Relic | To see application performance metrics for requests that reach Drupal. | Claiming your New Relic APM Pro account |
| Configure Platform Email | Allow your application to send outbound email on verified domain names. | Configuring Platform Email |
| Task | Why | Documentation |
|---|---|---|
| Address issues identified in the Site Review | Site Review is provided by Acquia Support or your TAM. | |
| Address issues identified in Drupal Status Report | Check /admin/reports/status. | |
| Cache test | Verify pages have correct cache headers. | Caching Score |
| Front end performance testing | Use PageSpeed Insights, YSlow, and WebPageTest. | PageSpeed Insights | YSlow | WebPageTest |
| Load testing | Confirm estimated monthly page views and load test data to make sure infrastructure is sized properly. Use a tool like BlazeMeter. | Load testing on Cloud Platform | BlazeMeter |
| Check logs for errors and notices | Resolve any errors and notices. | About Cloud Platform logging |
| Accessibility testing | Review site for accessibility compliance. | Website Content Optimization & Governance Platform |
| Task | Why | Documentation |
|---|---|---|
| Identify DNS owner | Determine who has the authority/ability to manage DNS. | Configuring DNS records for your application |
| Verify Domains and DNS | Make sure Domains and DNS info have been identified. | Managing domains |
| Verify edit domain | Ensure the edit domain is functional for content admins. | Best practices on setting up an edit domain |
| Set a short TTL for DNS | If using an existing domain, ensure the TTL is set to 5 minutes prior to launch. This ensures a quick launch process. | Set a short TTL for DNS |
| Task | Why | Documentation |
|---|---|---|
| Submit a Site Review ticket (2+ weeks before website launch) | The Site Review will be conducted by Acquia once you confirm you have launch-ready code in the production environment. | Contact Acquia Support |
| Set page cache maximum age to something greater than “no caching” | Varnish® won’t cache your standard page requests from Drupal if page cache maximum age isn’t set. This may cause severe strain on infrastructure, resulting in degraded performance and potential website downtime. | Configuring Drupal cache settings for Varnish |
| Enable & configure Acquia Purge module | Acquia Purge is essential for proactively clearing stale content from Varnish® cache and Platform CDN caches, if applicable. | Purging Varnish cache on Acquia Cloud |
| Disable basic authentication so Acquia can check that Varnish is serving pages from cache | With basic authentication enabled (typically using the Shield module), you can’t check whether Varnish caching is working. | Password-protecting non-production environments |
| Update Drupal Core to the latest release | Security vulnerabilities leave your website more susceptible to attacks, and so on. |
|
| Disable any modules that set session cookies | Session cookies can prevent Varnish from working properly and lead to severe performance issues. This will be checked in an Acquia Site Review. | Using Varnish |
| Don’t override the PHP memory limit on a global basis. Consider conditionally increasing memory limits for specific pages that need more memory | Acquia tunes its infrastructure to use the exact number of threads possible for 128 MB of PHP memory. If your application needs more memory for every page request, create a Support ticket. Conditionally overriding the memory limit for certain administration pages can sometimes be acceptable, but check with Acquia Support before adding this. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Configure Memcache to help with overall website performance | The lack of Memcached can lead to a heavy load on the database infrastructure, therefore resulting in degraded performance. | Enabling Memcached on Cloud Platform |
| Enable the Dynamic Page Cache module | Dynamic Page Cache may increase the speed of your website, even for authenticated users. It’s the second line of defense after reverse-proxy caching (Varnish) and will keep user requests from overwhelming your website until the latter is warmed up. | |
| Enable JavaScript / CSS aggregation | CSS and JavaScript files can cause extended page load times because it is loading all the files for each. This can slow down page rendering. | Improving application performance |
| Disable Watchdog database logging module | The DBlog module (watchdog) writes logs to the database, which can cause a major strain on storage and memory. | |
| Enable the Syslog module | Syslog should be used in favor of DBLog. It can store logs much faster because it doesn’t need to write to the database. | About Cloud Platform logging |
| Check for pending database updates | Depending on the functionality, issues can compound over time if left unaddressed. This is important for critical/core business functionality. | |
| Enable full PHP error reporting | Failure to log problems caused by faults in PHP can cripple your ability to troubleshoot an issue. | PHP error logs |
| Check for and Remove SQL queries and PHP logic or functions in templates | Going against the Drupal architecture can cause performance problems, such as SQL queries should not exist in Drupal templates such as node--xxx.tpl.php. | |
| Back up Stage and Prod database | For recovery purposes. In the event of a disaster, you can quickly retrieve the most current version of your database. | Taking backups |
| Clear Stage Varnish caches | Clearing cache on your staging website will allow the most recent website changes to be reflected. | Using Varnish |
| Migrate Stage code to Prod | Without code in your production environment, there will be no live website. | Code workflows with Cloud Platform |
| Migrate Stage files to Prod | Without files in your production environment, there will be no live website. For more information, see Copying files between environments. | Working with files | Cloud Platform |
| Migrate Stage database to Prod | Without a database in your production environment, there will be no live website. For more information, see Copying a database across environments. | Working with databases |
| Review areas of codebase using infrastructure-side device detection to confirm caching isn’t impacted or remove entirely | If the website is relying on infrastructure-side device detection for anonymous visitors, you may find pages are improperly caching for a single device. | Varnish headers |
| Configure OPCache to be large enough to store compiled code for your applications’ PHP scripts | If OPCache usage is too high, you may experience memory allocation and other associated OPCache errors. | Finding/Resolving Memory Related PHP errors in Acquia Cloud |
| Ensure directories don’t contain more than 2,500 files each | Website performance can severely degrade when too many files are added and available to the system in a single directory without any subdirectory structure. | Proactively organizing files in subfolders |
| Identify and remediate potential issues from having large image files | Image processing can be complex and can put a major hit on website resources (for example, memory). Underestimating the memory usage of these processes can have severe impacts on the responsiveness of your website. | Scoping the impact of image processing |
| Disable or adjust settings for modules and applications | Cloud Platform and security require permissions and installs to be built in a particular fashion. This can sometimes cause incompatibilities with Drupal contributed modules. | Modules and applications incompatible with Cloud Platform |
| Switch from Drupal database search to Acquia Search | This can cause availability issues for websites in association with increased database activity, and is considered redundant and inferior to search backed by Acquia Search. | Acquia Search |
| Enable caching on blocks, views, and panels where applicable | While Varnish cache will take a significant load off your website, Drupal-level granular caching can provide more performance benefits in many situations. | |
| Disable default Drupal cron in favor of Acquia’s scheduled jobs | Compared to other cron solutions, using the Scheduled Jobs page is more reliable and provides extensive and integrated logging for Cloud Platform applications; disable the automatic cron module. | Using scheduled jobs to support your application |
| Disable unneeded modules (SimpleTest, Statistics, Devel, Mobile Tools) in Production | These modules can increase the website’s startup (bootstrap) overhead and are unnecessary in Production. | |
| Disable user interface modules (views_ui and field_ui) | Can impose a small performance penalty when enabled, and can allow the essential views/fields required by your website to be modified. https://Blocking unwanted traffic on your website | |
| Identify and Block Nuisance Bots | Nuisance bots disrupt site analytics and create an impact on your infrastructure utilization. Block unwanted traffic with a WAF. Add such nuisance bots to .htaccess to keep unnecessary traffic at bay. | Blocking unwanted traffic on your website |
These configuration tasks configure preferences and connect your application to Acquia services.
| Task | Why | Documentation |
|---|---|---|
| Add custom domains | If there are no custom domains present, domains do not resolve when DNS is updated. Include the bare domain if necessary. | Managing domains |
| Configure Remote Administration preferences | Setting your application update preferences correctly ensures security updates can be integrated into your workflow. | Remote Administration Preferences |
These tasks prepare your application for an imminent launch.
| Task | Why | Documentation |
|---|---|---|
| Remove Prod environment site protection | Disable basic auth (Shield module) or remove IP whitelists. | Password-protecting non-production environments |
| Warm Caches using /etc/hosts and Prod domain | Configure /etc/hosts and navigate the site as anonymous to cache popular pages. | Avoiding maintenance mode during site updates |
| Clear the Varnish cache on your production environment | Clearing cache on your production environment will allow the most recent website changes to be reflected. | Using Varnish |
| Back up the database on your production environment | For recovery purposes. In the event of a disaster, you can retrieve the most current version of your database readily. | Taking backups |
| Enable Production mode | Lack of a production mode leads to a heightened possibility of destroying your live application by overwriting your production files and databases. | Using Production mode to protect your live application |
| Check that domains and DNS are pointed correctly | Your website do not resolve to the Acquia platform unless you update your DNS settings with your Acquia IP address. | Configuring DNS records for your application |
| Enable legacy 301 Redirects | Enable 301 redirects from legacy URLs/services/sites to the new site. | Redirect |
| Notify search engines of the site | Such as Google Webmaster Tools. | Google Search Console |
These items should be checked and verified once the site has been moved to production.
| Task | Notes | Documentation |
|---|---|---|
| Check Drupal’s status report | Go to Reports > Status report. | |
| Verify analytics tracking is working | ||
| Verify third-party integrations are working | Any external app or service that interacts with Drupal needs to be verified. | |
| Monitor New Relic | File an Acquia Support case with any concerns. Paste a permalink to what you see in New Relic in the case. | Using New Relic to troubleshoot site issues |
| Monitor Stack Metrics | Verify that infrastructure metrics are good. | Using Stack Metrics to monitor activity on your environments |
| Request Traffic Report | Acquia Support can provide a traffic report upon request. This shows the top 200, 30x, 40x, and 50x requests. | Contact Acquia Support |
| Verify 301 redirects | Make sure redirects are working properly. | Redirects |
| Verify emails are being sending correctly | Troubleshooting Platform Email | |
| Verify cron jobs are executing properly | Using scheduled jobs to support your application |
In case there are unforeseen or unplanned issues, the steps below can be followed to revert the launch and go back to using the old site.
| Task | Notes | Documentation |
|---|---|---|
| Change DNS | Point DNS back to the original site. | |
| Revert 301 Redirects | Redirect | |
| Enable the Shield module on Prod environment | ||
| Flush Varnish cache | Flushing Varnish prevents the site from being displayed even though the Shield module is enabled. | Using Varnish |
| Notify necessary parties of postponed launch |
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform