Ansible Delegate_to: Run Tasks on Delegated Host

The delegate_to keyword in Ansible lets you run a specific task on a different host than the ones defined in your inventory or playbook. This comes in handy when you need to centralize operations, run tasks on a specific control node, or handle actions that are better suited to localhost instead of the remote servers you’re managing. 

What makes delegate_to particularly useful is that it seamlessly redirects tasks within the same playbook execution — allowing you to mix targeted remote operations with locally executed ones without extra complexity.

For example, if you do not want to download a Linux package on the remote hosts the playbook is running against due to restricted internet access, you can utilize the delegate_to keyword to download the Linux package locally (on the control node) or to a designated centralized server that has internet connectivity. Then, you can copy the package over to the remote hosts in your inventory file and trigger an install. 

The following playbook demonstrates this workflow of downloading the package locally on the Ansible Control Node and copying over the file to the remote host. See that the delegate_to keyword is used on the same level as the module get_url since this is a global keyword that can be used with any Ansible module:

This allows you to offload a specific task (get_url) to a separate server instead of following the default execution path of running the task against your listed remote hosts.

The ability to run playbooks locally can be useful in various scenarios. Let’s dive into some real-world examples and break down how you can benefit from this strategy of running your playbooks locally:

1. Backing up configuration files

Our goal is to collect Apache configuration files from each remote host targeted by the playbook and securely store them on the Ansible Control Node in a designated backup directory.

This serves as a precautionary measure, ensuring we have a local snapshot of the current Apache configurations before making any upgrades or changes via Ansible.

2. Creating configuration files

The delegate_to keyword is particularly useful when working with Jinja templating to centralize tasks and avoid redundant execution across multiple locations. 

In this example, we generate an Nginx configuration file locally on the control node by injecting specific variables from our Ansible variables into a Jinja template. The generated file is then copied to all remote hosts. This simplifies the process by centralizing the template generation to a single location, eliminating the need to create the configuration file individually on each remote host.

3. Triggering database scripts locally

Running database schema scripts directly from your Ansible control node can simplify deployments by keeping all SQL execution centralized. It can be especially useful when your control node has direct access to the database server while remote hosts do not. 

Instead of distributing scripts across multiple machines, you execute them from a single location, reducing file transfers and minimizing complexity. 

By running the scripts locally, you streamline the workflow, reduce unnecessary file transfers, and ensure centralized management of database operations.

4. Capturing data and storing it locally

The delegate_to keyword can also log information about your remote hosts and store it locally in a text file. It can be useful for centralized reporting, auditing purposes, and automating data collection across all of your remote hosts.

5. Testing connectivity for ports

Sometimes, you want to verify if specific ports are open and accessible either before deploying an application or after making configuration changes. 

When using the delegate_to keyword, you can check the status of a specific port on a remote host directly from your Ansible control node, which centralizes port connectivity checks, eliminating the need to run the tests individually on each remote host.

The delegate_to directive in Ansible offers powerful capabilities for executing tasks on specific hosts beyond the default inventory assignments. Here are some advanced features and use cases:

Combining  delegate_to with run_once

The delegate_to Ansible keyword works well with run_once, which can be useful when you want a single task to run only once after multiple pre-tasks across multiple remote hosts are completed. 

For example, you have a collection of application servers that all rely on a single shared database service. You need to push some configuration updates to each app server, but for the changes to take effect, the database service must be restarted. 

The problem? Restarting the database after updating every app server would be inefficient and disruptive to dependent applications.

A cleaner approach is to update all application configuration files across your remote hosts first, and only then trigger a single database restart. To achieve this in Ansible, you can use run_once for the database restart task and delegate it to your database server. This ensures the restart happens just once, preventing unnecessary downtime or cascading failures.

Now, let’s see how this works in an Ansible playbook:

Using delegate_to with with_items

Another way to maximize the use of delegate_to is to use it with the with_items keyword. This will allow you to loop through the remote hosts in your inventory file and continuously delegate a specific task to another server. 

For example, if we have a centralized configuration file on a central server that contains a list of all the application servers’ hostnames along with their IP addresses, we can simply delegate a task that uses the lineinfile module to the centralized server and loop through the list of all our application servers listed as remote hosts in the inventory file, which will then grab the hostname and IP addresses of each. 

Here is the sample inventory file we will work with:

Let’s see how we use the with_items with the delegate_to keyword:

Once we run the playbook, we will end up with the following config file in our centralized configuration server:

Use delegate_to with with_items and run_once

We can also combine with_items with run_once when using delegate_to. This is useful when downloading a set of packages on a central server before distributing them to application servers.

For example, instead of downloading each package separately on every remote host, we can fetch all required packages once on a central server and then proceed with installation across the app servers. This avoids redundant downloads and reduces network load while ensuring all application servers get the necessary updates efficiently.

Here’s how this works in an Ansible playbook:

How to run Ansible delegate_to on multiple hosts

Ansible’s delegate_to can only assign a task to one host at a time. To run a task on multiple delegated hosts, you can use loop (or with_items for older versions):

However, this executes the task once per inventory host unless you use run_once: true to ensure it runs only once:

If you need to run a task on multiple remote hosts outside of the inventory hosts, consider defining a separate play with those hosts instead of using delegate_to.

So far, we’ve explored how to use the delegate_to keyword for local task execution and the advantages it offers. Now, let’s take it a step further by looking at use cases where delegate_to is used for remote task delegation, so we can involve external servers dynamically within our playbook runs, enabling more advanced automation. 

For example, we can use Ansible delegate_to keyword to offload specific tasks to dedicated remote servers, such as:

• Managing DNS records: Adding, removing, or modifying entries on a central DNS server
• Centralizing logs: Forwarding logs to a dedicated log server
• Handling certificates: Generating or renewing certificates from a central certificate authority
• Database failover: Promoting a secondary database to a primary one in a failover scenario
• Backup management: Transferring backups to a dedicated storage server
• Load balancer updates: Reconfiguring a load balancer after adding or removing application servers
• Post-deployment testing: Running automated tests on a dedicated load-testing server

Now, we’ll explore these scenarios in more detail and demonstrate how to structure multi-host workflows for better organization and scalability.

Example 1. Update entries in the DNS server

In this example, we’re deploying a web application and need to register its hostname in DNS. Normally, this would require manually updating the DNS server or running a separate script to create the A record. However, by using the delegate_to keyword in Ansible, we can automate this step within our playbook, ensuring the DNS entry is created dynamically for the application server.

To achieve this, we define an Ansible variable containing the necessary DNS information and the target host details. Because our DNS service is hosted on a separate server, we delegate the task to it.

For the actual update, we use the nsupdate command, which allows dynamic DNS modifications. We need to pass a shell script containing multiple nsupdate commands, with update add being the key command that registers the new DNS record.

This ensures that once the web application is deployed, its DNS record is created automatically. Using delegate_to for this task eliminates manual intervention, streamlines deployment, and maintains consistency across our infrastructure.

Example 2: Logging to a log server

Now, let’s centralize our server logging by collecting logs from all remote hosts and storing them on a single log server. Instead of manually checking logs on each server, we’ll configure Ansible to aggregate them in one location for easier monitoring and analysis.

We achieve this by gathering logs from the /var/log/syslog directory on each remote host and transferring them to a designated directory on our central log server. Using the delegate_to keyword, we ensure that the log collection process runs on each remote server but sends the logs to a single destination.

Instead of navigating to each server to view their logs, we have visibility from one simple location:

Example 3: Generate certificates from a central server

Manually generating a Certificate Signing Request (CSR), private key, and self-signed certificate for each application or server can be a tedious and error-prone process. However, with Ansible’s delegate_to keyword, we can automate these steps, ensuring consistency and security across deployments.

By delegating certificate generation to a dedicated certificate server, we avoid storing sensitive certificate files on local machines, reducing security risks. Instead, the certificate files remain securely within the certificate server, and only the necessary files are transferred to the application servers.

To implement this:

• We define a role to handle certificate generation, making it reusable across deployments.
• The playbook first completes the application deployment tasks before triggering the certificate role.
• The role takes the remote host’s details, generates the required certificates, and securely copies them over.
• With the copy module and delegate_to, the source is the certificate server, and the destination is the application server.

Additionally, we can extend this automation by updating application configuration files post-certificate generation to enable HTTPS.

Example 4: Automate database failovers

In Disaster Recovery (DR) scenarios, we can use delegate_to to automate database failover, ensuring a smooth transition from a secondary database server to a primary one with minimal manual intervention.

To achieve this, we first verify that the secondary database server is ready. Once confirmed, we trigger a task — delegated to the secondary database server — to promote it to primary. This is a conditional task that only executes if the target host is the designated secondary database server.

After promotion, we perform another delegate_to task to update the database configuration file (db_config.ini) on the new primary server. This ensures that applications and dependent services correctly recognize the new primary database by updating the db_host parameter accordingly.

This failover method is highly adaptable and can also be applied to other application failovers, such as promoting backup web servers or redirecting traffic after a load balancer failure. 

Example 5. Transfer backups to a central server

The delegate_to keyword can also be leveraged for automating backup synchronization across multiple remote hosts to a centralized storage server. This ensures that all backup files are stored in a single location without requiring manual transfers.

In this setup, we use delegate_to to create a dedicated directory for each remote host on the storage server. Then, we utilize the Ansible Synchronize module to sync backup files from each remote host to its respective directory on the storage server.

Unlike the copy module, the synchronize module follows a pull-based approach — the delegated host (storage server) pulls files from remote hosts rather than pushing them. This means:

• Source: The backup directory on the remote host.
• Destination: The corresponding directory on the storage server.

By structuring it this way, we ensure efficient data transfers while centralizing backups in a secure and organized manner.

Example 6: Update load balancer configurations:

In environments with dynamic infrastructures where backend servers are added and removed, it’s important to update our load balancer configurations continuously as we add new servers. 

For this example, we will be using HAProxy for our load balancer. Our goal is to add an extra line in our haproxy.cfg file in our load balancer server. We can achieve this by using the Ansible lineinfile module, which allows us to insert a line item after a specific word pattern. 

Once we add the line to our configuration file, we will reload the HAProxy Load Balancer service to reflect the new changes. 

Example 7. Post-deployment load testing

After deploying an application to a backend server, we need to ensure its performance and reliability through load testing. In this example, we delegate the load testing task to a separate server equipped with Apache Benchmark (ab).

To trigger the test, we run the ab command on the load-testing server, passing in key parameters such as the App URL, Concurrent Requests, and Total Requests. The results are then stored in a dedicated directory on the load-testing server, organized per tested remote host.

For extended functionality, we could delegate result storage to a separate log server instead, ensuring centralized performance tracking. However, for simplicity, we store results directly on the load-testing server in this example.

Here are some of the benefits of using the delegate_to keyword across your Ansible playbooks. 

• Increased task flexibility across hosts – Offload tasks to a different host than the one in your inventory, allowing centralized execution while keeping the playbook structure intact.
• Efficiency – Reduce redundancy by executing tasks once on a central host and distributing results to remote hosts, avoiding repetitive downloads or script generation.
• Centralized coordination – Perform critical operations — like updating a load balancer, modifying DNS records, or generating configuration files — on a single designated server instead of maintaining multiple playbooks.
• Enhanced security – Execute sensitive tasks (e.g., certificate signing, key generation) on trusted servers to prevent unnecessary exposure across multiple hosts.
• Minimized errors – Run tasks on a dedicated server to prevent inconsistencies caused by differing configurations across remote hosts, improving reliability and preventing playbook failures.

Following these best practices will improve the efficiency, security, and maintainability of your Ansible playbooks when using delegate_to:

1. Use delegate_to only when necessary – Avoid delegating tasks that can be executed directly on remote hosts. Only use delegate_to for operations requiring a specific dedicated server, such as DNS updates, logging centralization, or certificate handling.
2. Leverage run_once to prevent redundant execution – When running tasks on a central server, use run_once to prevent repetitive execution. This is particularly useful for actions like restarting shared services or applying global configuration changes.
3. Optimize tasks with with_items – Condense multiple related tasks into a single loop using with_items (or loop). This reduces redundancy, making it ideal for bulk operations like downloading packages or registering multiple DNS records.
4. Document all delegated tasks – Clearly document each delegated task in your playbook. Since delegated tasks can become complex, proper documentation ensures clarity and prevents misconfiguration or overlooked automation steps.
5. Use delegate_to for sensitive operations – Security-sensitive tasks, such as generating SSL certificates or handling encryption keys, should be performed on a secure, dedicated server instead of on multiple remote hosts.
6. Test in a staging environment first – Before applying delegated tasks in production, validate them in a controlled staging environment. This helps identify issues early and ensures the automation functions as expected without causing disruptions.

Spacelift’s vibrant ecosystem and excellent GitOps flow can greatly assist you in managing and orchestrating Ansible. By introducing Spacelift on top of Ansible, you can easily create custom workflows based on pull requests and apply any necessary compliance checks for your organization.

Another advantage of using Spacelift is that you can manage different infrastructure tools like Ansible, Terraform, Pulumi, AWS CloudFormation, and even Kubernetes from the same place and combine their stacks with building workflows across tools.

Our latest Ansible enhancements solve three of the biggest challenges engineers face when they are using Ansible:

• Having a centralized place in which you can run your playbooks
• Combining IaC with configuration management to create a single workflow
• Getting insights into what ran and where

Provisioning, configuring, governing, and even orchestrating your containers can be performed with a single workflow, separating the elements into smaller chunks to identify issues more easily.

Would you like to see this in action — or just get a tl;dr? Check out this video showing you Spacelift’s Ansible functionality:

If you want to learn more about using Spacelift with Ansible, check our documentation, read our Ansible guide, or book a demo with one of our engineers.

Ansible’s copy module is both flexible and powerful, making it a key tool in IT automation. It’s great for simple tasks like moving files from one location to another, but it can also handle more complex needs like making sure files have not changed before moving them using checksum, creating backups, and checking that files are correct and safe. This module is useful for different situations, whether it’s just copying over files as they are or ensuring that everything is secure and in the right place.