Bedrock + Trellis - Am I ready to make the switch?

bedrock
1

Hey all,

I could use some advice on whether or not I should dive into Bedrock and Trellis at this moment. Or maybe postpone for a rainy day.

I’m a Graphic Designer and I’ve started programming about two years ago. (better pays, and broader service :slight_smile: ) . About two months ago I came across Sage 10 and, by now, I’ve made 3 themes with it. I might say I feel comfortable with using it.

Currently I develop the site with Sage first in mamp. Export it with a plugin and upload the entire site remotely. But I’m starting to feel the frustrations with the hassle and inefficient way doing so.

Looking at Bedrock + Trellis looks a good time investment to learn and I can picture it working locally and with github, But this is where ends for me and where I would like to get some feedback.

Before I would get a webhost with shared hosting and an wordpress application installer. This manages the local backups and installs a clean site. For me that was easy. And I have no responsibilities when the site is down “they” just fix it. External backups are done with a plugin. Easy.

But for me, updating the theme is a hassle and versions could easily get mixed up. Plus, I now want to rollout multiple sites with the same WP base (plugins, themes, settings). This is where bedrock looks nice.

As for the hosting I’m completely in the dark. Wat would I need and what maintenance would it require?
From what I understand I would need a linux web server. But that’s where the knowledge ends for me.
Would I need to install appache on it manually?
Would I need to set a firewall manually?
Would I need to update the OS manually?
What are the downsides
Do I need to fix my own local backup and would this be a backup of the entire OS or site plus DB?
Are there webhosts with additional software preinstalled? (for maintenance and such)
These are questions that popped into my head, maybe there are additional requirements to get it running remote and maintaining it.

I know it’s a lot of text, so any pointers are welcome.

2

My two cents here:

  1. Trellis is not meant for shared hosting, you need root access to complete Linux (Ubuntu) system. You should have a minimal/bare Ubuntu 20.x LTS for it.
    In fact, additionally installed packages/services (e.g. already installed mysql/mariadb, PHP, nginx) can even complicate the installation.
  2. There is also managed WordPress hosting where the hoster will do all the hosting-related jobs for you, including backups, updates and maintenance. But those are quite costly, especially for many sites. Also you give up most control of course.
  3. Trellis uses ansible, which is a tool that automatically configures/ensures the states of a server.
  4. Trellis also sets up a firewall and fail2ban, although if your cloud provider offers a separate hardware firewall you may want/need to configure it, too.
  5. As a general rule of thumb, the least software you need/run on a production system, the better.
  6. Trellis is primarily meant for web agencies (as I understand), so there is some technical skill and maintenance involved but you get the full control over the system.
    You can also mix-and-match specific components: Managed database and Trellis, AWS hosted static upload files, CDN service like Cloudflare, proxy in front of the site, etc.
  7. Updates and maintenance have to be performed by yourself, either using some auto-updating mechanism as Ubuntu offers or manually in the role of a system admin.
    Though normal package upgrades should in theory always be compatible with the previous configuration (also always keep the existing configuration), so issues should rarely occur - except for distribution-level upgrades.
  8. Backups also have to be set up by yourself. You got some choice. For example, you can use the existing cloud provider backup (when affordable enough, e.g. Hetzner is quite good with it) and additionally backup to an off-site/off-DC location, which is always a good backup practice.
3

Thank you @strarsis for the elaborate answer. Except for the second half of point 6 it all makes sense to me. I can now see that for me, as a freelance studio, bedrock and trellis are overkill. I see potential fubars when I get about 20 sites in the air and have to become a fulltime system administrator for maintenance and a helpdesk if a site becomes unresponsive.

Too bad. But for me staying at just Sage would be the best option. Deployment and version control would stay the same as it used to be. It would be nice for small buisnesses to have something like Netlify.com is for react sites for bedrock and/or trellis.

4

Well, I don’t have to do much for keeping it updated. Some basic knowledge would be helpful of course.
Paying one cloud instance for 20 (smaller) sites is surely more affordable than using managed hosting.
Shared hosting has its own downsides, you have much less control, security, and performance issues can arise.

5

Thanks, I’ll keep that in mind. Maybe in a few months I can re-evaluate this question. Of the entire Trellis + Bedrock + Sage workflow the maintenance of the hosting is my only concern. The rest of it is just learning.

6

I was once in the same boat, as a graphic designer. Now I’m managing 25+ sites with Trellis :slight_smile:
I can only advice to just give it a go with a dummy site. Cheapest droplet is $5 at digital ocean, if you don’t like it then that is your only cost.
Once you got the hang of it, you will never go back to a shared hosting, I promise you!

7

They could…use Netlify. I’ve launched a couple sites for businesses that used Forestry for a CMS backend and 11ty and Netlify for building and hosting the site. Folks like it, it works great, and for a lot of small businesses it’s essentially free (or incredibly low-cost). Almost zero maintenance (esp. compared to WordPress), faster out of the box, more secure, etc.

8

Thanks, I just might do that. I think I’ll give it a go on a rainy Sunday afternoon. But after that I’ll look for a local (Dutch) solution to have a helpdesk in the same language and in the same timezone :slight_smile:

9

Ah yes, I’ve done two with SanityJs and GatsbyJs on Netlify. But most (or at least local) clients prefer the word “Wordpress” :slight_smile: That’s why I wanted to find a better WP solution to work with. That’s where Sage filled the first gap for me.

10

Hi Tim,

As more of a Bedrock beginner, I might be able to give you a more subjective impression that will help in a different way from the other comments.

I’m very new to Bedrock and have not tried using it with Trellis yet and don’t know if I will since I don’t think it works well with multiple sites on a single VPS.

My first impression is that Bedrock is good for a site where the developer or someone with some ability to use Composer is responsible for all updates and adding/removing plugins. So I am running my personal site using Bedrock.

For a site that you will hand over to a client, you have to figure out how you’ll handle plugin updates.

You also have to figure out how you’ll handle any premium plugins not available through wpackagist

In my case, I allow automatic updates because I have had a server that had to be burned and restored from backups due to being a few hours late on a Drupal update (see “Drupageddon”)

Once you’ve gotten to that point - premium plugins and auto-updates - I think some of the advantages of Bedrock disappear, but it’s not as bad as it sounds.

So first, this is the flow and, yes, it sounds bad:

  • your site updates automatically, so the composer json and lock files get out of sync with the actual files on your site
  • your premium plugins update but are not in your composer.json (or you build a system that does include them, meaning you are running your own package server or you are using the local system on your dev platform). In my case, where I rarely use premium plugins, I simply whitelist those and track them in git, so like the composer.json file, they are part of the git push/pull process
  • on your live site, which presumably has been auto-updating, you do a git add/commit/push
  • you pull that down to your dev site and then run a composer update
  • you check to make sure that all plugins updated to the current version and, if not, adjust your version constraints in composer.json
  • do your dev work
  • git add/commit/push
  • pull your latest changes to staging
  • deploy

No matter how you cut it with WP, though, you have a problem with local/staging/production data. Since posts and settings are all in the DB, there’s simply no reliable way with WP to do dev work and push to production if your dev work involves changing DB settings.

I’m more used to Drupal where settings can all be exported to code, so you never have to push the database to production or manually port database settings and Composer is baked into the trunk distro. The only real way to manage Drupal 8+ is with Composer, so you are not fighting the trunk distro to bolt Composer management onto a software package that is fundamentally designed for a different management paradigm.

Don’t get me wrong - it’s not a criticism of Bedrock at all. I am super thankful that Roots has taken on this project and I would love to see WP as a whole get friendlier to Composer and build in a strict separation of content and config so that you could track config and not be pushing databases and, in the worst cases, having to merge databases.

But for now, I just feel like no matter how you cut it, Wordpress just feels like a very old codebase and a very old approach to managing a site. The Roots folks are fighting the good fight and doing a wonderful job considering the headwinds Wordpress blows in their face, but those headwinds are strong.

11

The VersionPress project could help a lot with the data/content issue, but sadly its development is stalled:

The problem with updating WordPress core and plugins can be solved by using an automated updater like renovate and a CI pipeline for automatically pushing a new release.

In many cases premium plugins don’t offer an easy way for updates.

The content/data of a CMS doesn’t have to be the same for staging and development. The development sites may use a simple dataset that can be used to test all aspects of the site theme and plugins.