# Best practice for multiple sites on multiple servers

**URL:** https://discourse.roots.io/t/best-practice-for-multiple-sites-on-multiple-servers/5385
**Category:** trellis
**Created:** 2015-12-01T16:14:23Z
**Posts:** 14
**Showing post:** 6 of 14

## Post 6 by @fullyint — 2016-04-07T19:16:07Z

@40Q I think it’s cool that you’re trying this out. I haven’t tried it. If you run the regular command

```
ansible-playbook server.yml -e env=production
```

this results in [`hosts: web:&production`](https://github.com/roots/trellis/blob/3fa9a3d285f2f3e6200f3d8daaf028983f8c58ad/server.yml#L13), meaning "run `server.yml` on all the hosts in my inventory that are simultaneously in the `web` group and the `production` group (c.f. [Ansible docs](http://docs.ansible.com/ansible/intro_patterns.html) regarding specifying “intersection of two groups”). In other words, the command will provision both `site1` and `site2`, each on the separate and respective IPs you have assigned in your inventory.

I believe you can use the [`--limit` option](http://docs.ansible.com/ansible/playbooks_best_practices.html#what-this-organization-enables-examples) @richvida mentioned to run `server.yml` for only one host/site, which is one IP in your case.

```
ansible-playbook server.yml -e env=production --limit site2
```

The advantage of setting up the `host_vars` directory as you have done, is that you shouldn’t have to comment out inapplicable sites from `worpdress_sites` when you run your command because each `host_vars` file defines only the desired `wordpress_sites` just for that host.

One downside of adding `host_vars` is that it introduces structure that is absent from the upstream official Trellis, which could mean you’ll have to resolve conflicts that may arise if the upstream structure changes in a conflicting manner.

Another downside of adding `host_vars` is that you may need to deal with this issue:

> [@To deploy a second site](https://discourse.roots.io/t/to-deploy-a-second-site/5229/6):
>
> EDIT. The `host_vars` in option 3 above makes no distinction between environments (e.g., staging vs. production). Perhaps there’s an easy way to address this next level of complexity, but I haven’t explored it yet.

I’m sure it’s possible to handle, but it may require a bit of familiarity with the Ansible’s mechanisms (read: more work) and perhaps some additional structure.

> [@40Q](#):
>
> a situation where you might have a client who owns multiple servers for different projects and wish to have only one trellis installation

If the different projects/servers have a lot of special configs that are shared and it is particularly helpful to have them in a single Trellis project for the sake of logistics and keeping things DRY, then I may be inclined to do the integration work we’ve been discussing. Otherwise, I’d probably still be inclined to have separate Trellis projects per site/server, even though they are all for a single client.

> [@fullyint](#):
>
> My inclination would be to use a different Trellis project for each logical group of sites.

I mean “logical group” in terms of project code and Trellis configs and/or customizations shared across sites/projects. I would not group sites/projects into a single Trellis project solely on the basis that they all belong to a single client. I don’t know which situation you face.

Again, I haven’t tried any of the above. If you trial both approaches a little bit, a preferred strategy may become clear.

---

_[View the full topic](https://discourse.roots.io/t/best-practice-for-multiple-sites-on-multiple-servers/5385)._