Multisite trellis setup with one non-wp website

Hi, I’m managing a Trellis installation responsible for the deployment of multiple bedrock/sage instances to the same server and I’d like to add a static website alongside.

Do you have any idea of how can I add it mantaining Trellis and all the wp sites as they are?

1 Like

Does anyone have had a similar need?

I do not have an exact solution for what you need.

One workaround I could think of is that you could turn your static site into a basic WordPress theme that uses a front-page.php and an assets folder.

It might be overkill because you’d get a database and dashboard but it might not be so bad if you decided to expand the site later.


Did you find a solution for this?

I’ve got a single Digital Ocean Droplet for miscellaneous projects. It currently has two separate WordPress installs at two different URLs.

I’m really curious about using the Trellis tools to add another domain/SSL cert to the same box, sans WordPress installation, so I can host a static site from the same box.

Same issue here. I think the start is going to be to disable the creation of databases and any other site options which a static site wouldn’t need. Past that, a properly configured composer file in the site root might do the trick. I’ll be working on this later today so I’ll let you know how it goes.

1 Like

My current site config for the static site looks like this:

      - canonical:
    local_path: ../statictest # path targeting local Bedrock site directory (relative to Ansible root)
    site_install: false
    db_create: false
      enabled: false
      enabled: false
      provider: self-signed
      enabled: false

The site directory is empty except for a composer.json file with the following content:

  "name": "thisolivier/statictest",
  "type": "project",
  "config": {
    "preferred-install": "dist"
  "require": {

Vagrant up runs well, all the way until the final task of wordpress-install, when I hit this error:

TASK [wordpress-install : Setup Permalink Structure] ***************************
changed: [default] => (item=superblog)
Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.
failed: [default] (item=statictest) => {"changed": true, "cmd": ["wp", "rewrite", "structure", "/%postname%/", "--allow-root"], "delta": "0:00:00.300259", "end": "2016-09-27 10:31:47.035436", "failed": true, "item": "statictest", "rc": 1, "start": "2016-09-27 10:31:46.735177", "stderr": "Error: This does not seem to be a WordPress install.\nPass --path=`path/to/wordpress` or run `wp core download`.", "stdout": "", "stdout_lines": [], "warnings": []}

I think this is a bug, since the play should only run when wp_install_results are changed (see roles/wordpress-install/tasks/main.yml line:67), however the site has clearly been skipped (see the output of Install WP below)

TASK [wordpress-install : Install WP] ******************************************
changed: [default] => (item=superblog)
skipping: [default] => (item=statictest) 
changed: [default] => (item=patterncutting)
changed: [default] => (item=followerof)

When I debug the wp_install_results variable, I can see that the Permalink Structure play is checking whether ANY site has been installed. I think it should be looking within the variable for whether the specific site has installed wordpress (that information is available). If you then run vagrant provision, no new Install WP plays are run, so the wp_install_results is not set to changed, and the all the sites skip the Setup Permalink Structure play. Successful execution!

A bigger issue is the number of WP specific plays are still being run, and that the site_install and db_create variables in no way prevent Trellis from treating the site as a wordpress instance.

So, to summarise, it’s possible to deploy a static site as part of the development deployment, just make sure:

  • site_install: false and db_create: false are set in your wordpress_sites file, and vault.yml is setup as normal.
  • You have a valid composer.json file in the site root.
  • You re-run vagrant provision after vagrant up, since there seems to be a bug in TASK [wordpress-install : Setup Permalink Structure]

Edit: I’ve submitted a but report for the Permalink Structure issue. See Trellis issue #660.

Edit 2: The bug has now been fixed, as of pull 661 development deployments should work fine without needing to re-provision.


This is brilliant. Thanks. My goal with this was to actually deploy another site to a multi-Bedrock box on DO, and I don’t really see any reason that wouldn’t work as well, but y’never know with these things.

Well the first thing you’ll have to fix (I just discovered) are the creation of symlinks for the web/app/uploads folder.

TASK [deploy : Create shared symlinks] *****************************************
System info:
  Ansible; Darwin
  Trellis at "WP 4.6 Compat: set WP_HOME/SITEURL directly"
Error while linking: [Errno 2] No such file or directory
failed: [] (item={u'path': u'web/app/uploads', u'src': u'uploads'}) => {"failed": true, "item": {"path": "web/app/uploads", "src": "uploads"}, "path": "/srv/www/statictest/releases/20160928085827/web/app/uploads", "state": "absent"}

That one’s pretty easy to fix, just create the directory in your static site. However, I think our best bet is adding a site variable for ‘static-site’ and changing the conditionals in all the plays.

It shouldn’t take too long, but it’s be worth getting some input from the Trellis dev team if something like this would be a useful feature/enhancement, since otherwise our trellis repo’s are going to have trouble pulling updates.

Further good news, the production server deploys! It doesn’t work yet, but it deploys.

  • Make sure you have /web/app/uploads in your site directory (probably a good idea anyway to keep the shared resources).
  • Add the following variable to your site configuration ensure_wordpress: false
  • Add the following conditional to theroles/deploy/tasks/finalise.yml file, on line 14 - when: project.ensure_wordpress | default(true)

This just sets up an arbitrary setting for our static site, and then checks it before running the Wordpress specific finalisations. To make sure there’s no confusion, my finalise.yml file looks like this:

- include: "{{ deploy_finalize_before | default('../hooks/example.yml') }}"
  tags: deploy-finalize-before

- name: Finalize the deploy
    current_path: "{{ project_current_path }}"
    path: "{{ project_root }}"
    release: "{{ deploy_helper.new_release }}"
    state: finalize

- include: "{{ deploy_finalize_after | default('../hooks/example.yml') }}"
  tags: deploy-finalize-after
  when: project.ensure_wordpress | default(true)

- debug:
    msg: "{{ project_version }}@{{ git_clone.after | truncate(7, True, '') }} deployed as release {{ deploy_helper.new_release }}"

The final step is to add a play which creates the Nginx config to actually serve our files, since that’s normally part of the wordpress plays which we’re now skipping. I can’t build this now, but if you want to, the existing Nginx playbook is in roles/wordpress-setup/tasks/nginx.yml


An overdue word on how this all turned out in the end.

  • Local deployments of a static site aren’t that hard, just follow the instructions in post 6
  • When you’re ready for a remote deployment, follow the instructions in post 9. Note - there’s an additional step to make the site publicly visible.
  • You have to go into the nginx routing on the remote server and create a new file/template for the static site. Follow these instructions from stage 3 and you’ll be fine. I mean I should have added this to the playbooks, but I don’t really know how. I can confirm that reprovisioning the server using trellis won’t remove the routing, so at least you only have to do it once.

Well, if anyone finds this helpful, let me know!


very helpful thank you. I’m about to attempt this over Christmas break, I’ll probably report back with how it went, if not just assume it went well :slight_smile:

1 Like