CD environment resources and limitations¶

Limitations¶

CD environments in Acquia Cloud are not intended as replacements for production or load testing environments. The following limitations apply to CD environments:

• CD environments are limited to three active databases per environment limited to 1 GB, and query execution time is limited to 60 seconds.
• You cannot add or delete databases in Acquia Cloud CD environments. To retrieve 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 – tests depending on mod_proxy enablement will fail
  • Node.js environments
  • Elastic IPs (EIPs) cannot be assigned to CD environments
• To maintain platform stability, CD environments exceeding filesystem limits are subject to deletion.
• CD environments are limited to 256 MB 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. Service restarts or maintenance activities will not be preceded by formal notifications and will occur as required to maintain service availability.
  • Acquia may terminate cron jobs and other automated processes at its discretion; therefore, customer scripts must be resilient to failure.
  • SSH sessions will be disconnected when containers are replaced; in such cases, customers must reconnect, and they will connect to a healthy container.