Craft Cloud - A year in review

Recent features and improvements

In July just before Craft Cloud turned one years old, the Craft Cloud team dropped a big update bring many improvements and new features to Craft Cloud. Here's my summary of the major changes and what's improved.

Code deployments

Code deployments on Craft Cloud were a little rough to start with being totally honest. It was one of the major criticisms in my Craft in Notts talk. The serverless design of Craft Cloud means your Craft project needs to be built and then deployed as a container image being served through bref.sh and AWS. Because of this code deployments trigger a build of a new image each time you push to your Git repository. The main issues were deployment times could range from anywhere to 5 - 30 minutes (dependant on the amount of plugins, asset bundles and generally the speed of the builder process itself) it was also was very inconsistent. We found in many cases code deployments to exceed 30 minutes which is the max timeout, causing the build to fail outright. Think about having to wait 30 minutes just for a build to fail. Not ideal.

The Craft Cloud team were listening to feedback and have released Builder 2.0 and the speed is frankly amazing. We can now get consistent 5 minute build times, which for serverless is impressive, given all the requirements of composer, npm and asset bundle building needed for serverless deployment. One of the advantages of the no DevOps, minimum configuration code builds with Craft Cloud came at a massive speed penalty until now, the builder process is much more reliable and consistent!

Automatic database backups for all environments

On initial launch, Craft Cloud only provided daily backups for the production environment and not any other non-live environment e.g. staging. While non-live environments should technically be classified as destructible and are often overwritten by live database snapshots, having an automatic backup of any environment is nice for piece of mind. When you have a in progress project or development which isn't ready for production, having a backup of your non-live environments helps prevent any losses of in progress work, particuarly if this relies on specific field values or entries being present. Or if you happen to accidently nuke someone's work on staging (I have been guilty of this and I'm very sorry to my team!). Craft Cloud now does automatic backups for all environments, in addition backups are now compressed with gzip to help with saving storage space and reducing the payload size to download, which is very welcome for sustainability. These days various development environments like DDEV support restoring from gzip database backups, handling the decompression/extraction on the fly.

At my organisation we also implement a separate backup policy/process where we directly connect to the Amazon RDS database at scheduled intervals to perform backups and store these in an S3 bucket outside of Craft Cloud. We originally did this due to backup reliability being an issue at times, where an automatic backup would randomly fail. This has also been improved, but we felt having a separate backup strategy independent of our provider was still good for the 3-2-1 backup rule and in the event of Craft Console is down, we can get hold of recent database backups still.

Redirects/URL rewrites

With Craft Cloud being serverless, redirects or URL rewrites are a little trickier to handle. With more traditional server based hosting with something like NGINX or Apache, you have the server/VirtualHost configuration or .htaccess (for Apache) to implement URL redirect or rewrites, with serverless, there is well.... no server, so no config for you. Since Craft CMS 5.6, Craft itself provides redirect capabilities through the redirects.php config which while there is no GUI interface to manage them, you can implement redirect rules for any 404 request, simple or complex rules (i.e. using regex matches) are possible. Of course there is also the excellent Retour plugin which has been around for a while and does provide a friendly interface to manage all your rules. The downside to these options is they are at the Craft CMS application level, which potentially adds some additional weight and resources to process any rules. There is the app.web.php which runs a bit higher up in the chain to not require the entire Craft CMS application to be fully loaded but things can get wild and messy quickly. You can see the old way you'd have to handle non-www to www requests on Craft Cloud, not really elegant.

A recent update now provides redirects and rewrites to be possible through the Craft Cloud YAML configuration file. For those who aren't familiar the craft-cloud.yaml is a required configuration file for any Craft project being deployed to a Craft Cloud environment. This update ships this feature with a syntax that is using the URLPattern API behind the scenes, which get processed by the Cloudflare Gateway before your Craft CMS application. This is great for core redirects such as non-www to www or forcing or removing trailing slashes, offloading them to the gateway and never having to query your application to then follow a 301/302 response is better for performance. The syntax does take a bit of time to understand, but having the ability to do redirection at the gateway level is great and a welcome feature.

My wishlist

There's been some great improvements recently, but as both a client of Craft Cloud through my employer and being really passionate about anything Craft, here's some of my key features I'd like to see in the future on Craft Cloud, both for selfish reasons but likely benefitting others as well!

Asset/database syncing

Craft Cloud proudly pitches its no DevOps approach to hosting, which I'm big fan of. However having multiple Craft Cloud environments means at some point we need to sync assets from our production to one or more non-live environment. Currently due to some limitations I would argue you absolutely have to do DevOps to do this currently. The issue stems from the fact that access to the Amazon S3 bucket where assets are stored for each environment, is only provided with short life S3 credentials which last for one hour. This is a bit rough currently. The best solution we've come up with is writing a wrapper script around the AWS CLI to sync assets from either local to remote or remote to local, with the remote being any of our Craft Cloud environments. This however still relies on getting short-life S3 credentials which will only last for an hour from Craft Console, there is no API to automate this. In addition asset syncing requires you to pull down assets from one environment locally to then sync to a remote. It is something others have been interested in and I think the Craft Cloud team will be looking at it in the next major update.

Similarly being able to directly copy the database from one environment to another would be a great time saver. I think asset syncing is more important and I can live without database syncing, given it is relatively simple to setup MySQL connection profiles in something like MySQL Workbench or Datagrip and unlike the S3 access credentials the RDS database credentials are fixed. it is also possible connect directly to the RDS database without Craft, meaning you can run your own automation/scripts in a container, which is how we do our separate backup policy.

Craft Cloud/Console API

Several discussions have highlighted features which could benefit from having some form of REST API to interact with Craft Cloud functionality without the Craft Console GUI, for example downloading a database backup, running a command through Craft CLI or really any other environment specific function available in the Craft Cloud interface without needing to use the Craft Console GUI. There are obvious security implications to having an API that has the access and execution power for this, but for automation, this would be really nice to have. With a suitable security model it is something that I think would allow for more possibilities, particularly if you do want to do any DevOps/automation in this area.

Running Craft Cloud environment commands through the Yii module

All Craft projects which run on Craft Cloud require the Cloud Extension. This extension is the bridge between Craft CMS and the serverless architecture of Craft Cloud. On local environments, the module doesn't really do much, but being a module it is bootstrapped an entire Craft CMS project and can implement additional functionality, such as CLI commands. If you happen to have a project that uses Craft Cloud, you'll notice additional commands like cloud/queue/exec appearing in the CLI runner rather than just the standard queue/exec command for example. Being inspired by something like Fortabbit's copy plugin, being able to run commands at a Craft Cloud environment from local dev would be a game changer. One of the great things with Fortrabbit's copy plugin has is the ability to pull download a database backup and restore it in one single command,. While you can easily restore a database backup through something like ddev with import-db, you still need to obtain said backup and the path to it. As previously mentioned there is no way to download the database backups from Craft Cloud currently, unless you've opted to create database backups in an alternative storage medium e.g. a separate S3 bucket.

Updating environment variables without needing to create a new deployment

This one I can live without, but it would be nice for environment variable changes to be applied without having to trigger a whole new deployment. Currently any environment variable change requires this because of the environment variable values being set in the container during the build. While not too much hassle, I have forgotten on more than one occasion to hit the deploy button after changing environment variable values. If this can be done automatically or the app runtime automatically updated and reloaded, that would be amazing!

Hobbyist pricing tier

Craft Cloud currently offers three pricing tiers, Team (120 USD per month), Pro (240 USD per moth) and Enterprise (which is pretty much a custom agreement and price TBA). One barrier for smaller projects wanting to use Craft Cloud is the pricing starting at the Team level, it potentially cuts out smaller websites, given the Team pricing is quite a high barrier for a small Craft CMS site e.g. my blog for example. Craft Cloud is managed through Craft Console which is agency friendly for managing many client websites under a single organisation account, but I think there a potential market for a lower entry pricing tier to be more competitive. There's nothing wrong with being more focused on medium to larger organisations of course, but many Craft CMS sites are not necessarily in that category and could be being priced out currently.

Summary

Summarising all of the recent changes, the July update has made Craft Cloud a more viable and serious option for an organisation considering the power of serverless. Backed by the same team who develop Craft CMS, there is no other platform with better support and knowledge when hosting your Craft CMS application. I would still say there are perhaps some gaps for features some may consider deal breakers. Similar third-party competitors like Servd and Fortrabbit do have some features and platform areas which Craft Cloud is currently lacking, but more improvements and new features are planned, which you can see the Craft Cloud roadmap for more details.

Overall for some of the shortcomings, the main benefits of Craft Cloud is leveraging the serverless architecture to its full potential, with a native CDN and static caching layer built directly into the platform which seamlessly works with Craft CMS and the element/caching layer, alongside zero-config queue workers and minimal-config code deployments, you spend less time configuring your environment, not worrying about scaling/performance and more time shipping code to it, which as a developer who actively doesn't want to do DevOps, I'm down for that!