--- title: "Code Deployment Management" date: "2026-06-04T11:36:16+00:00" summary: "Manage concurrent site-level code deployments with minimal downtime using Multi-Experience Operations on Acquia Cloud Platform." image: type: "page" url: "/acquia-cloud-platform/add-ons/multi-experience-operations/code-deployment-management" id: "834f6ecb-80db-4f22-bb1e-dbfd5ef5b78e" --- Multi-Experience Operations enables concurrent, site-level code deployments for environments with multiple sites. This method minimizes downtime because each site enters maintenance mode only during its specific update instead of the entire environment-wide deployment. Key Features ------------ * Concurrency: Simultaneous site updates reduce total deployment time. * Prioritization: User-defined sequences establish the site update order. * Site-Level Hooks: Site-specific events trigger Cloud Hooks for precise maintenance mode control. * Deployment Control: Stop an active deployment. To continue, submit a new code deployment: * Same code version: The platform resumes from where the previous deployment stopped. * New code version: The platform deploys the new version to all sites, starting from the beginning. Deployment configuration ------------------------ To initialize a deployment, you must first configure your environment settings and then do the code switch. ### Pre-deployment configuration This configuration is optional because the platform updates three sites concurrently in a standard sequence by default. You must complete this configuration only if a specific workflow requires a custom deployment order or a different concurrency limit. 1. [Sign in to the Cloud Platform user interface](https://cloud.acquia.com/). 2. Select the target codebase and environment. 3. To set concurrency, navigate to **Configuration** and select **Code Deploy**.  4. Enter the number of simultaneous site updates in the **Concurrent updates** field. The default value is 3. 5. Click **Save**. ### Set up the update order To setup the update order: 1. On the environment overview page, navigate to the **Sites** list. 2. Click the three dots and select **Edit update order** to define the sequence for the sites. 3. Click **Save**. ### Initiate a deployment 1. On the environment overview page, click **Switch code**. 2. Select the target branch or tag for the new code. 3. To run hooks during deployment, select the **Run Cloud Hooks**. This step is optional. If you do not select this option, the platform bypasses the hooks. 4. If you select the **Run Cloud Hooks**, enter Cloud Hook arguments to pass specific maintenance mode triggers or conditional logic.  5. Click **Switch** to begin the deployment. Active deployment management ---------------------------- During an active deployment, the interface displays the status of individual sites. To manage the queue, click **Stop** to cancel the deployment process. Submit a new code deployment promptly to ensure that sites do not split between two code versions. Important After a **Stop** action, you must submit a new code deployment with the same code version or a new code version to bring all sites into a consistent state. Technical requirements for Cloud Hooks -------------------------------------- Site-level maintenance mode requires specific updates to Cloud Hook scripts. For additional information on Cloud Hooks, refer to [Automating with Cloud Hooks](/acquia-cloud-platform/automating-cloud-hooks "Automating with Cloud Hooks"). * Site-Level Triggers: Configure hooks to respond to the `pre-site-code-update` and `post-site-code-update` events. These are the only available site-level hook events. * Minimum Recommended Snippet Logic: * `pre-site-code-update`: Put the specific site into maintenance mode. * `post-site-code-update`: Run required database updates and take the site out of maintenance mode. * Process Arguments: This step is optional. If a workflow requires custom parameters or logic overrides, update hook scripts to process arguments that pass from Switch Code UI. Hooks that do not use arguments continue to function normally. * Test: Run the hook scripts manually through an SSH session to verify their behavior and debug logic before you rely on them in the deployment queue. Switch code sequence -------------------- A Switch Code operation in an MEO environment proceeds in the following sequence: 1. Cron jobs run with the new code version during the early stages of the rollout. 2. A second rollout of pods launches with the new code. 3. Pre-environment Cloud Hooks run. 4. The platform moves sites to the new code in batches based on the concurrency configuration: 1. The `pre-site-code-update` hooks run for each site in the batch. 2. The platform switches the ingress to point site traffic to the new code for each specific site instance. 3. The post-site-code-update hooks run for each site in the batch. 4. The platform updates the code version for the site. 5. Post-environment Cloud Hooks run. SSH access uses the previous code version until the final deployment steps complete. Stop a code deployment ---------------------- When you stop an active deployment, the following events occur: * A stop task request displays in the User Interface (UI). * The task log of the original code deployment task includes the task ID of the stop request. * The platform terminates active Cloud Hooks and Cloud Actions. A stopped deployment leaves the environment in a split state because the ingress switches to the new code on a per-site basis as sites progress through the queue. You must submit a new code deployment promptly to ensure that sites do not remain split between two code versions. Note MEO code deployments take an average of 3 to 8 minutes because the platform runs two rollouts of pods. If site-level hooks are slow, increase the concurrency setting to reduce the total deployment duration. Troubleshooting --------------- ### Deployment failures If a code deployment task fails, complete these steps: 1. Review the task logs to determine whether a platform issue or a Cloud Hook script error caused the failure. 2. For platform failures, retry the deployment. If the failure persists, open a Support ticket and include the task ID. 3. For Cloud Hook failures, debug the script code. Test the scripts manually through an SSH session. ### Recover from a failure To bring all sites back to a consistent state after a split-state failure or a stopped deployment: 1. Resolve all hook errors. 2. Test the scripts manually through an SSH session. 3. Submit a new full code deployment with the same code version or a new code version. ### External service calls in cloud hooks If Cloud Hooks call external services such as APIs, third-party integrations, and Content Delivery Network (CDN) purge endpoints, ensure that the scripts include the following: * Retry logic: Handle transient failures such as network timeouts and 5xx responses gracefully to prevent unnecessary deployment errors. * Timeouts: Set explicit connection and execution timeouts to prevent hooks from entering an unresponsive state and to ensure that they do not block the deployment queue. Each site-level or environment-level hook has a maximum execution time of 3 hours. A hook that enters an unresponsive state on an external service blocks the batch slot of that site. This action reduces effective concurrency and extends the total deployment time. ### Code version overview The code version on the Sites page indicates whether Cloud Hooks are complete for that site and whether the site uses the new code. A site can serve the new code before the `codeVersion` field updates in the UI. The update sequence for each site runs as follows: 1. Pre-site hooks run. 2. The system directs site traffic to the new code. 3. Post-site hooks run. The code version updates after all hooks complete. If a post-site hook fails, the site runs the new code and the UI displays the previous code version. ### Site re-association in a deployment If you disassociate a site from an environment and re-associate it within the grace period before deletion, the site instance restores to a Ready state. However, the code version does not update to the latest deployed commit. After re-association, you must submit a full code deployment for the environment. This deployment skips the sites that already use the current version. This process is similar to a new site association and sets the code version to the current version.