CD environment resources and limitations¶

Limitations¶

CD environments in Acquia Cloud are not intended as replacements for production or load testing environments. Be aware of the following limitations that apply to these types of environments:

• CD environments are limited to three active databases per environment limited to 1GB, and query execution time is limited to 60 seconds.
• You can not add or delete databases in Acquia Cloud CD environments. To obtain a new database, you must recreate the environment.
• CD environment software versions may not match Acquia Cloud environment versions. Pushing applications from your CD environment to your Production environment may have unexpected consequences. In general, issues should be minimal.
• CD environments do not currently support the following features available to standard Acquia Cloud environments:
  • Creation of custom scheduled jobs
  • Live development
  • Server or uptime reporting
  • Custom VCLs
  • Drupal 6-based environments
  • Dedicated Acquia Search cores
  • mod_proxy configurations — because of this, tests that depend on mod_proxy being enabled will fail
  • Node.js environments
  • Elastic IPs (EIPs) can not be assigned to these environments
• To maintain platform stability, CD environments that exceed filesystem limits are subject to deletion.
• CD environments are limited to 256MB of RAM per process.
• Acquia performs 24x7 monitoring of CD environment infrastructure health but, unlike Acquia Cloud Enterprise production environments, the application uptime SLA does not extend to CD environments.
• Because Acquia Cloud CD is based on a dynamic infrastructure, the following items are applicable to CD environments:
  • Acquia will proactively perform service restarts or maintenance activities to preserve High Availability. These activities will not be preceded by formal notifications and will occur as required to maintain service availability.
  • Acquia may have to terminate cron jobs and other automated processes at our discretion; therefore, Customer cron jobs and scripts should be resilient to failure.
  • SSH sessions will be disconnected when containers are replaced; in these cases, customers should reconnect and they will automatically connect to a healthy container.