Two CMS frameworks that do broadly similar jobs, but have vastly different hosting strategies. This article aims to help you make a more informed choice when choosing an open source CMS framework.
This article does assume some knowledge of serverless hosting & the role of a CMS. If you’re unsure on either, you may benefit from reading our CMS & serverless articles first.
The elephant in the room, and perhaps the most glaring difference between the two frameworks is the hosting architecture. Both frameworks are self hosted, so the person responsible for setting up the CMS will also be responsible for its operational maintenance, uptime and cost. However, the way this is achieved is broadly different.
Strapi is hosted traditionally (either directly on a server, or through containerisation), the documentation has swathes of different hosting provider setup guides, but for the purpose of this article we chose to use AWS as it is the most well established, and as far as we could tell, cheapest.
Webiny is hosted using serverless. In this case the framework is tightly coupled with AWS and includes comprehensive infrastructure as code (IaC) scripts that sit atop Pulumi.
From a headless CMS perspective, both frameworks offer similar out of the box capabilities; comprehensive content modeling, user authentication, and a GraphQL API (Strapi also supports a REST API out of the box).
Being open source, both frameworks offer the developer the ability to extend as they see fit, although we found that for most use cases this isn’t necessary.
Webiny has a paired offering in the form of a no-code page builder and a form builder which by default will be deployed alongside the CMS. In the case that your use case is solely a headless CMS, these can be disabled.
From an administrator standpoint we found Strapi to be more intuitive, due in part to the fact that it is first and foremost a headless CMS. The documentation is clear and unambiguous and the process for content modeling and getting users started is streamlined.
This contrasts with Webiny, which can take considerable mental energy to get set up. Content modeling can be done through the UI, but if you want a persistent backup that can be redeployed, it needs to be done in code. At the time of writing the only way to know how to structure the content models in code is to read the Webiny source code.
Broadly the Webiny documentation is difficult to understand at best and out of date or missing at worst. We have been told that the Webiny documentation is currently undergoing an overhaul so hopefully it has improved by the time this article is read.
Although Strapi has several deployment guides, we found none of them sufficient for a highly available, scalable production application.
If you want to deploy Strapi to a production environment, there won’t be any handholding - you’ll need a good understanding of the operational side of software development.
At the time of writing there is no Docker image available for Strapi v4, so if you’re hoping to just drop an image onto ECS or Fargate, you’ll need to write your own Dockerfile.
Assuming you’re working with AWS, there’s a slew of hosting paths available; EKS, ECS, Fargate, EC2. You’ll likely need to pair with an RDS instance, as well as the infrastructure that sits in front of the server (Cloudfront, Route53, VPC, etc).
For non-hobbyist, production applications, this can easily become a complicated deployment path. If you’d like to hear more about the operational options, please get in touch.
This is where Webiny really shines. Deployment to AWS via Pulumi is as simple as typing:
yarn webiny deploy
Pulumi will provision all the resources required for a production environment, no faff. There’s of course customisation available in the Pulumi configuration if you need to set up TLS certificates, custom caching policies, etc.
Assuming you are just using the base headless CMS framework, both options are completely free. Their only cost comes from their hosting & operational fees.
We attempted to optimise the cost for a production ready, highly available application. Assuming a low traffic profile with low scaling requirements, this is where we arrived:
Minimum requirement for AWS hosting:
Minimum requirement for AWS hosting:
Note that ElasticSearch can be included to increase API performance in some circumstances.
Despite its more jagged developer experience, Webiny is lightning fast, highly scalable, highly available and cheap out of the box. When working with clients we almost always opt for Webiny.
Please note, we are in no way affiliated with Webiny or Strapi, these are only our opinions based on our experience of working with the two products.