At One Design we offer our clients a hosting plan. Since many of our projects are green field, this not only to simplifies things client side, but streamlines the process on ours. When we first started this offering we made some mistakes in our setup that caused some headaches over time. Now that we've been running it for a few years we've established a pretty good set of services to power our Craft sites.
Overview
Servers
A website wouldn't be much without a server. We rely on Cloudways to handle the provisioning and have been fairly happy with it. I do wish it was a bit more scriptable, but it makes it nice and easy to spin up a server quickly and gives our developers a decent UI they can use in order to tweak basic settings.
We may eventually move to something like Ploi or Laravel Forge but for now, Cloudways is our go-to.
AWS
The server is only one piece of the puzzle. Each website we build needs a handful of additional services. We end up utilizing AWS for the majority of those services. AWS is quite the beast, but pretty much anything you need can be done there which allows us some flexibility for different clients.
We also use Imgix as our image transform service and CDN. More on that later.
Client Organization
We set every client up as an organization within our main AWS organization. This allows us to pay a single bill without sacrificing the ability to break down our costs by client. It also makes it pretty easy to migrate a client off of our hosting if and when that time comes. This also gives us a bit more insulation from some kind of mishap. Since each client has their own organization, the chances of client A getting access to client B assets is pretty low. I'm sure it's not impossible, but we've never had an issue.
Users
Within each organization we create two IAM users.
- A
craftcms-assetswhich gets limited permissions that allow it to interface with S3 only. The policy matches the example provided by Craft. - An
imgix-assetsuser gets the minimum permissions for Imgix based on the Imgix docs.
Asset Storage
In addition to our users, we need a place to store the assets associated with the website. This typically means a single S3 bucket set to private. Setting this bucket to private ensures that assets are only served via a CDN.
CDN
As mentioned above, we only want to serve assets via a CDN. For the majority of our images that's done with Imgix, but there are a handful of file formats (like pdfs) that we don't necessarily want to run through Imgix but still want served via a CDN. For that, we use Cloudfront. We configure Cloudfront to act as a CDN for S3 bucket and configure it to be able to read from our bucket.
The only downside is that this makes the asset URLs ugly. For many clients, this is just fine but some prefer to have these assets served from something like {assets}.hostname.com. In these cases we have to take a few more steps.
First we need to request a certificate using AWS ACM. Once the certificate has been issued, and we've validated our domain, we can update Cloudfront to use that domain and our nice URLs are in place.
Imgix
As mentioned above, the final piece of our puzzle is Imgix. For each client, we create a new source and configure it to use our S3 bucket and our Imgix user. Having a separate user for Imgix adds a small layer of security (and ease) should we ever have to cycle our keys.
Phew, that's a good chunk of infrastructure for simple marketing sites, but it's served us well through the years. We recently started using Terraform to manage all this, but that's a topic for another blog post.