Strapi: The Good and the Not so Good

Strapi: The Good and the Not so Good
9 min read

November 6

Today, we are going to talk about Strapi, a JavaScript-based headless CMS that has an open-source codebase and is free to host on your own servers. Let’s start this article by talking about where we have been using Strapi. We have used Strapi in 2 projects so far, one in our product FinWise (which by the way you can check out on and the other, in Hopeful Homes, a product for one of our clients.

FinWise is a product in the personal finance space and we are using the CMS for both our website and the web application. The website uses the CMS to fetch content for all the landing pages, blogs, and forms while the web application uses it for everything from user authentication, saving user data, and preferences to customize the user experience as well as the media and assets for the application.

Hopeful Home is a mobile application for victims of domestic violence in the UK available both on iOS and Android. It uses Strapi for everything from user authentication to maintaining the user data and experiences in an anonymous pattern.

Under the hood, we use PostgreSQL as our database and bookshelf as our connector. We also heavily use the GraphQL plugin to fetch our data and the S3 upload plugin to keep all our assets on our S3 buckets.

Both Finwise and Hopeful Homes had multiple developers working on them with the frontend being Next.js and React Native respectively. The only difference was that Hopeful Homes had a single backend developer working on the custom APIs and the schema implementation while Finwise had multiple developers doing so (this is relevant for when we talk about migrations).

The Good

Overall, we had a very pleasant experience using Strapi. There were many areas in which it reduced efforts and made the whole process more efficient. The features in this section reduced our development time by at least 60%. (This is not a list of all the features that Strapi provides but the ones that we found most useful).

Quick Setup

The CMS comes with minimal initial setup and quick guides on how to set up the plugins and the database. It does not take more than 10 to 15 minutes to set Strapi up on your local machine or EC2 instance. The content-type builder has an intuitive interface with a minimal learning curve and provides the standard CRUD APIs out of the box.

Automatic Generation

All the content types that are made using Strapi have an option of fields that have all the imaginable and required data types also the database tables, controllers, services, CRUD endpoints, and GraphQL types, and documents are autogenerated. Without this, we were re-writing a lot of the boilerplate code in our projects thus going against the DRY principle. Additionally, Strapi makes it very easy to override or disable these standard methods too.

Content Management

Well, if a “Content” Management System does not manage content, then we need to reconsider a lot of things. But, fortunately, Strapi does not have any trouble with this. It provides role-based access control, upload manager, intuitive UI, and most importantly, plugins to connect Strapi to S3. You can also use the media library plugin to extend the kinds of media that Strapi can handle to include videos, photos, and practically everything.

User Management

If you use Strapi, it is imperative that you install the Roles & Permissions plugin. Almost all applications will require features such as signup, login, forgot password, etc. The plugin implements these things for you and also gives you role-based access control. It provides you with login options from various social services such as Facebook, Twitter, Google, Discord, and a lot more. Also, it allows you to change the behavior of the default login mechanism from using email as an identifier to using a mobile number instead with a little customization (stay tuned to our blog, we may write an article on how to do that soon). There also is JWT token support for authentication on the code side of the application. Most importantly, Strapi has recently separated the roles and management of admin users and end-users thus making it easier to have more granular role-based access and avoiding privacy and security concerns.


Another interesting feature that we haven’t had the opportunity to use yet is the standard emails that are provided out of the box - such as forgot password. As you have guessed by now, it also has a plugin for different providers such as SendGrid.


Strapi allows you to customize a lot more than you’d expect. You can override most of the plugins using extensions so as to change the functionality without having to get the changes approved and merged in the Strapi core project. You can also write your own plugins which give you the ability to organize some of your business logic in a different way.

The Not so Good

There are only 3 major complaints that we have with Strapi.


This is a minor one, first, it does not provide 2FA out of the box, and the second issue is with its migration.

Database Migration

Strapi allows different SQL and NoSQL databases through Bookshelf and Mongoose as connectors for both respectively. But despite this, there is no support for traditional database migrations. All the content model changes are done behind the scenes in Strapi code. This means that if you want to add indexes or extensions, you either need to do this directly in the DB or build a custom migration solution. This becomes a bigger problem when you need to migrate data and more importantly permissions across different development environments and different developers’ local setups.

Multi-developer Collaborations

Lastly, collaborating on a bigger project with relatively more content types and custom APIs is slightly problematic. Different developers will add and remove different content types, fields, and relations but since everything is done in the strapi core and developers will not have access to each other’s changes while working locally, there will be a lot of errors and failures. This, we realized could be avoided by having each developer use a separate, local, development database instead of a common hosted development database. This also solved the issue of developers complaining about disappearing tables due to someone else running Strapi with a separate schema. But, the separate local databases lead to the issue of lack of migration support and merge conflicts especially in the content types that have been edited by multiple developers and documentation. After carefully merging the code, building Strapi, and manually migrating the data, things seem to work well, but we would love a more efficient solution here (hit us up if you have one).

Apart from these, there are a few other cons that you’ll find across the internet such as no type-script support, architecture and design issues, and lack of relationships in the database, but when you take into account the fact that the project is just over 5 years old and has come a long way since the start as a school project, you’d understand why we recommend Strapi not only for MVPs but even live applications. And if you still don’t trust us, try it out yourself, after all, it hardly takes a few minutes to set up.

View Next Blog