If you already visited strapi.io price page, you may have seen this popup and even had the occasion to chat with one of the Strapiers behind it: Pierre, Victor, Adrien, Mélanie, or me.

You've left 568 messages on this chat in 2020 and 1609 in 2021 to ask questions related to the features, to know if it's a good fit for your use case, for technical assistance, for pricing details... And we did our best to provide answers, live or asynchronously.

So we thought it was time to make a Top 10 Most Frequently Asked Questions and share our answers with you!

1. "When will Strapi Cloud be available?"

As you may have seen, we plan to work on a Strapi Cloud and many of you have expressed interest in it by upvoting it on our roadmap as one of the most requested features. This is why we recently decided to change the wording from "Coming soon" to "Not available yet" as it reflects that we are ready to deliver something in the coming months. No public ETA has been communicated but please do not expect something in 2022.

If you need help hosting your Strapi project, we have two kinds of partners that could be useful:

• Solution partners (see the full list here) can perform Managed Services to handle the deployment, hosting, scaling, and maintenance of your Strapi. You can choose to either go with the hosting options they offer or directly have them handle deployment configuration & maintenance over your own infrastructure.
• Technology partners (platform.sh, artifakt...) that build, operate, and scale complex infrastructures with a fully managed cloud hosting service.

2. "I don't understand a "free, forever" open source version with paid features?

Strapi is following an "open-core" model. Meaning that our core product is open-source under the MIT license so we can accomplish our mission: to empower the community to build a million tailor-made projects while providing enterprise features mainly required by companies. It allows us to generate the revenue we need to continue to invest in the rapid development of the Strapi open source project.

Read more about our vision in our Company Handbook.

3. “What are the default roles?”

Let's detail what kind of roles we're talking about.

In Strapi, you have roles used to manage end-users permissions to consume the content through APIs. By default, you'll find "authenticated" and "public roles" in the "User & Permissions" Plugin which you can customize

You also have roles that restrict content access to specific users in the Administration Panel. That's what we call the Role-Base Access Control (RBAC) or Granular-Access Control. The Community Edition of Strapi offers 3 default roles (Author, Editor, and Super Admin). To go further, creating custom conditions for any type of permission is also possible. This requires an Enterprise Edition starting with a Bronze license plan.

Read this support article for more details.

4. Your pricing mentions: "per admin user/month". "What do you consider to be an "admin user'?

Admin User is referring to anyone able to access Strapi (the user interface, not the API) regardless of whatever the User actually accesses or the frequency with which they access the interface.

If an Admin User has access to multiple projects with an enterprise edition (like a developer), then it counts twice.

You can find the legal definition in our Enterprise Terms.

5. "Is Strapi a good fit for large-scale apps like web stores with 500,000 products?"

Performance & scalability are quite a tough topic and there are so many variables that could have an impact: network, load-balancing, scaling (of everything), database tuning, model structure, number and type of relations, filtering types, caching, and CDN usage...

That being said, you should always keep in mind that Strapi is a product made of: a Node.js application, a database, and a UI. As long as these three components can scale, you shouldn't be concerned by Strapi's performances. Here is more information on horizontal or vertical scaling for your Strapi application.

If large companies like Toyota, IBM, AECOM, or Kyivstar run Strapi in production, then you can trust it is a powerful high-performing system! We would love to hear your own story to share it with our community. You contact us at reviews@strapi.io

6. "Can I have multiple websites on Strapi"?

Yes… and no!

Yes because that is actually what being "headless" means: having multiple heads, multiple frontends, multiple pages! But no because Strapi isn’t supporting multi-tenancy and doesn’t allow you to manage easily websites with different domains or sub-domains.

In a more technical consideration, it would represent the following structure:

blog

api blog/posts

api blog/shares

website

api website/home-banners

api website/newsletter

This topic is actually more complex. Let’s begin with defining what is multi-tenancy. There are two definitions possible:

• a single-project approach: which is perfectly supported In Strapi. It allows, for example, building a web app, a mobile app., and even pushing to an internal application while relying on the same database, configuration, policies, plugins...
• a multi-project approach: which is not well supported. It changes the architecture of the application to allow multiple projects like different websites in a single Strapi application. Each project is fully independent, you can use different domains, databases, policies, plugins... and maintaining such an advanced configuration and all the synchronization is very challenging.

Now you’re wondering what’s under the hood and where this product’s limitation comes from? Here are the technical details.

Strapi is fundamentally built in both the back end and the admin panel to only work with one domain at a time. When we build the admin panel, we literally hard code the domain into the build as the Admin is CSR (Client-side rendered) thus the user's browser downloads the entire admin and it runs it on the user's machine thus it needs to know what API domain to contact to run operation.

Now, if you’re still reading this article, you surely wondering “What if…”

Domain-based routing at the proxy layer? Yes, it would allow you to send traffic to different instances. But it doesn't mean that this is a good idea either. Or maybe you watched Virgin Media hacking multi-tenancy at Strapi Conf 22 and you still wanna do it?

Well, a workaround is possible. You could:

• Create a collection-type “Domain” with domains as entries and as a text field.
• Add a “one-way” relationship with other collection-types (eg: “Pages”)
• Display a different frontend for each domain.
• Allow users to be able only to edit pieces of content based on the domain.

Then you discover that you can utilize API token to secure the REST/GraphQL endpoint but this comes with the limitations of not being able to limit the content that can be accessed. So you want to add policies or middleware's to limit what API token can access at the API layer ect… And so you fall understand layer over layer of customization.

Please carefully consider that this proposed workaround is not production-ready. It’s actually is ideal for small web pages/sites just landing pages for different domains that have some degree of static data. Using this for more complex websites will add complexity in terms of deeply nested content models that contain a lot of dynamic zones and components. This would potentially bring up the relational performance issues Strapi currently faces and with this implementation, it would run into relational performance due to the complexity of the model.

As a conclusion, headlessCMSs created a new paradigm in the definition of “multi-tenancy”(vs. monolithic CMS) so our main recommendation is to clearly define your expectations and the architecture that you need to match these. Most of the time, it’s an inheritance from your current implementation and dev. teams are focusing on satisfying business needs while avoiding to change their work-style. Switching to Strapi is a huge occasion to change your architecture to something simpler and to review your content editing workflow, even though it means dealing with change management, the overall benefits should be higher.

7. "Is it possible to pay monthly for a Strapi Enterprise license?"

With our Enterprise Edition licensing, we offer annual payments for 1 year by default on all license plans.

For the Bronze and Silver plans, we do not allow for monthly, quarterly, or any other modifications to the payment schedule for less than one year. We can provide contracts that are longer than a year, but the entire term must be paid upfront.

For our Gold plan, we can do custom terms based on your needs and requirements. Options can be discussed with our sales team here.

Read this support article for more details.

8. "When I buy a license, do I have to pay for each environment?"

A Strapi application may be deployed in multiple instances and environments with the same license as long as it doesn't:

1. Serve different model configurations with the same license
2. Multiple projects serving different websites:
   • Client 1 has one Strapi instance to power their website: client1.example.com
   • Client 2 has one Strapi instance to power their website: client2.example.com An excerpt from this article
3. Get distributed as part of a template available for free download/distribution.

Read this support article for more details.

9. "How do I upgrade my existing Strapi project to the Enterprise Edition?"

If you have purchased an Enterprise Edition license, you will be given a long randomized key, this key is used to activate the features of your Strapi project the license provides. There are two key ways to install this license that will be detailed below:

• Via an environment variable STRAPI_LICENSE
• Via a license.txt file located in the root folder of your Strapi project

Read our Installation Guide for more details.

10. "What is different between Strapi and other headless CMS services?"

An estimated 1.7 billion websites exist around the world and over half use a CMS. One of our customers benchmarked more than 100 different solutions before choosing Strapi. With more than 46k GitHub Stars, Strapi ranks #136 most popular repository, before Adobe Brackets, Symfony or ASP.NET Core. Based on the number of GitHub stars and number of NPM downloads, we think it's fair to say that we are a leading open-source headless CMS.

Being open-source & self-hosted brings many benefits: full control over your stack, no vendor lock-in, infinite possibilities of customization... Whereas SaaS solutions provide ease of deployment for non-technical users.

When it comes to pointing out each solution's differentiators, people are generally looking for three main points: the feature coverage, the public reviews, and the companies already using the solution at scale.

Our advice would be to pay specific attention to:

• The stickiness to your technical stack
• The documentation's quality
• The community's footprint and the number of active contributors
• The company's history and any dependency on a legacy stack