A technical evaluation guide for engineering leaders choosing a CMS for a multitenant SaaS platform. This guide covers multitenancy architecture, deployment models, cost at scale, security, integration, and editing experience.
Sometimes your title is Director of Engineering. Sometimes it's CTO. Sometimes it's just "technical co-founder." Either way, the buck stops with you on major technical decisions for your organization. That includes choosing a CMS that will empower your customers to create their own content, without forcing an awkward fit on your developers.
Most CMS guides only scratch the surface on this topic. When looking for the right CMS for this business model, robust support for multitenancy is a key concern. It's also important to understand how to keep costs down as you scale up. The learning curve for editors matters, especially when editors are customers with a range of experience and skill levels, or the way a separate "back end" impacts that learning curve. And the true cost of implementation for your engineering team is made up of many factors, not just license fees.
Some CMS products support self-hosted deployment. Others do not. For those that don't, data residency requirements can end the conversation quickly. For those that do, the pros and cons of self-hosting versus managed hosting should be carefully evaluated.
If your organization doesn't have a firm requirement for self-hosting, it's time to consider the pros and cons.
For those who have the choice, here are some genuine advantages of self-hosting:
When evaluating these choices, it's important to remember what the stakes are. When managed hosts and the hyperscalers they run on experience downtime, it makes news. But "managed hosting is not perfect" misses the real tradeoffs. It's not about whether managed hosting is flawless; it's about whether it's more reliable and cost-effective than running the infrastructure yourself. The appropriate comparison takes into account:
The reliability of managed hosting vs. the reliability of self-hosting.
The cost of managed hosting vs. the fixed cost and the staffing cost of self-hosting.
Consider this: What is your team's secret sauce? What is the core competency only your company can deliver? If it's devops, by all means self-host. If not, focus your energy on what you do best.
Some CMSes achieve multitenancy by attaching a tenant id to every database record. While this is elegant on paper, it poses security concerns.
When data for independent tenants is differentiated only by a particular field, each line of code that manipulates the data must be written to take multitenancy fully into account. Otherwise data "bleeds through" and risks proliferate. This approach is common in in-house designs. It can work, but only with very careful attention to the issue in "model layer" code.
Others, like WordPress, resolve it by adding suffixes to table names in SQL databases. While this is more robust than a tenant id in each record, because it will never accidentally read data that does not belong to the current tenant, it does require that each line of code directly manipulating the database be aware of this issue in order to successfully read the data at all.
Others approach multitenancy by using separate logical databases or schemas. With some database back ends, like MongoDB and Postgres, this can be quite efficient. These can readily accommodate 1,000 "logical databases" before the overhead of each logical database becomes a concern. And more importantly, the implementation code does not have to constantly take the "tenant id" into account. Instead, it simply "talks" to the database object it is given. This is the approach taken in ApostropheCMS.
There are two parts to this question: licensing and hosting.
CMS licensing schemes vary. Some price by the seat, which is especially common among proprietary closed-source CMSes. Some charge by the website in a multitenant project. Others, like WordPress and ApostropheCMS, have a free, open source core but require closed-source plugins to add certain capabilities and charge by the seat or site for those features.
ApostropheCMS charges a per-website license fee for access to multitenant features and other advanced tools. For a multitenant SaaS implementation, this option is most relevant to your use case. However, ApostropheCMS also offers volume licensing to bring the per-site cost down quickly with large numbers of tenants.
Apostrophe Assembly, our multitenant solution, starts at $499/mo for five sites but license costs come down rapidly with volume. Other providers similarly set site count limits on a tiered basis. Reach out to us for a quote to match your specific needs.
The golden rule: whether you self-host or host with a managed provider, hosting costs should always be on a "pay for what you need" basis. They should be based on expected usage, not the number of sites.
ApostropheCMS, for instance, offers optional managed hosting. Rather than a fixed hosting fee per seat or site, the customer decides how many performance servers to pay for. For high availability, scalability and durability MongoDB Atlas and AWS S3 are standard equipment in such deployments.
Be leery of products that quote hosting prices based on "dynos" or other concepts without a clear definition in terms of actual capacity.
When hosted by ApostropheCMS, a multisite / multitenant project with 50 websites will typically have production hosting costs of $178 per month ($89 per performance server, with 2 servers for high availability). Some customers might elect to get by with just one performance server. Others might have high traffic needs that demand more resources. The important thing is that the level of capacity provided is chosen by the customer through a transparent process.
This pricing reflects the added value our solution provides while keeping that cost dependent on the resources actually delivered.
Compliance requirements usually break into two layers, and it's worth knowing which is which. The first is operational: SOC 2, ISO 27001, and similar attestations that certify how a vendor runs its hosted service. The second is application security: Is the software itself sound? Hosted CMS vendors sell you the first and ask you to trust them on the second. Be leery of any CMS whose entire security story is a logo you're not allowed to look behind.
ApostropheCMS flips the narrative. Because the core is open source, the application layer is fully auditable, engineered against the OWASP Top 10, with red-teaming built into how we develop and release it. Even our closed-source extensions, including Pro and Assembly, are source-available to licensed customers, with evaluation licenses available on request.
The operational layer works in your favor too. Because you can deploy Apostrophe on infrastructure you control, SOC 2 and ISO 27001 are earned where they actually apply: through your own already-certified operations. One honest caveat: our optional managed hosting isn't SOC 2 or ISO 27001 certified yet, though we're working toward it. So if those are hard requirements today, self-host with our active support and guidance, and your existing compliance program covers you.
Multitenant CMS use cases tend to get lumped together. But SaaS platforms and simple white-label marketing site platforms are very different beasts. SaaS platforms benefit far more from integrating their own functionality directly in CMS-driven websites.
When evaluating a CMS, ask whether the software stack is a good fit for yours and what the points of integration are. Are you limited to iframes, or can you pull in content from your own REST and GraphQL APIs? Will you be doing that using a modern software stack that aligns with the rest of your application, or will your developers have to take a detour into PHP? In the opposite direction, can your application push content into the CMS easily via REST APIs?
Don't forget infrastructure alignment. Can the CMS be self-hosted alongside your existing application for minimal latency, or at least hosted in the same region of the same hyperscaler? Can the CMS be run on the database your company already has experience with, or are you required to manage a database outside your core competencies? Will your developers be required to install a local database engine they don't normally need?
ApostropheCMS is built on a modern Node.js stack and directly supports React-style JSX templates, as well as Liquid-like Nunjucks syntax. If you choose to use our Astro integration, components can be written with virtually any frontend framework. Your application logic can be integrated directly via ApostropheCMS event handlers and async components. Because the source is in your hands, you can integrate any existing npm module, including GraphQL clients. REST calls come free with JavaScript's fetch. Incoming REST APIs are standard, with rich support for API keys and other authentication methods. MongoDB, SQLite and PostgreSQL are all supported through a consistent document-driven API via our db-connect layer.
Developer experience isn't everything. It's true that SaaS product teams that offer a website builder experience often start by building out the customer's site for them, in whole or in part. This can mitigate concerns about learning curve. But even though the team doing that is experienced, the sheer volume of customers makes the editing experience mission critical. And even if you "pregame" each tenant's site, you'll still want to give them the keys to a safe, effective and pleasing editing experience so that they can do their own updates without constantly nagging your content team. So the learning curve matters after all.
How do you get there? At a minimum, a CMS needs to support an inline editing experience, with live preview on the page as edits are made in the interface. Ideally, this should be an inline or in-context visual editing experience, i.e. editors should be able to type directly on the page. Editors should be able to produce good results in mobile and tablet responsive views, ideally without any special effort. You should ask: is there an entirely separate back end? If not, how tight is the "inline" integration between the editor and the page? How robust is the preview capability?
At the same time, the CMS should offer effective editorial workflows. At a minimum, it should be easy to distinguish the latest draft version of a document from the live version that website visitors see, right up until the moment it is ready to publish. Customers with more sensitive content may also expect the ability to pass updates through an approval process.
For text, ApostropheCMS delivers direct, visual editing on the page. For other types of content, ApostropheCMS offers inline editing with live preview. Content that doesn't map "one to one" to the page can be managed via the admin bar, which integrates directly into the site. Multiple levels of editorial control are available, including the option to require drafts to be submitted for approval. The ApostropheCMS layout widget simplifies responsive design by automatically reflowing the page at smaller sizes, while still giving the editor the option to expressly hide certain content on phones and tablets. And all of these benefits still apply if your development team chooses to use their frontend framework of choice via Astro.
Some may say: "ease of use would be nice, but there is a price to be paid for going headless." Don't accept that excuse.
Those with a large commitment to an existing CMS are right to be concerned about the lift involved in migration. Especially when tens or hundreds of sites have been built out in a multitenant platform. The quality and flexibility of the migration tools provided matter here.
While some migrations can be handled through manual content entry, or an AI automation of that process, some customers may have hundreds or thousands of existing blog posts, product pages, etc. So automation is frequently called for.
Some CMSes offer a native path from certain others, most often from WordPress. But there are many existing CMSes, and it is unlikely that every single one has an explicit migration path to your new CMS of choice.
So it is better to ask: how good are the general-purpose export capabilities in your existing CMS? And how good are the general-purpose import capabilities of the new CMS?
Here the news is mostly good. Most systems offer REST APIs that can be used to both read and write content. And this is often the best path for content migration. Your developers (and their AI coding agents) can script a migration path like this:
In the end, the ease of migration will depend on the quality of the API documentation and the degree of conceptual "fit" between the old and new systems. But there's another piece of good news here: AI coding agents are well-suited to "take an X and transform it to Y" tasks like this. Migration tasks that used to take months can often be completed in hours or days.
Of course, there are edge cases. Some legacy and proprietary CMSes may lack a clear or complete export path. For these, web scraping may be needed. Tools like Cheerio and Puppeteer can help to automate that.
ApostropheCMS has well-documented REST APIs for all content types. Your developers get full access to the source. And since our admin UI relies 100% on the REST APIs, it is straightforward to examine examples of valid calls right in the browser console. Even so, mapping between different representations can be a chore. That's why we provide conveniences specifically for importing rich text with inline images intact, including bringing those images into the ApostropheCMS media library with their alt attributes. This makes it much easier to migrate from a legacy system quickly, especially for common content types like blog posts.
Every section above comes down to the same discipline: separate what a vendor claims from what they can show you. A CMS demo is usually built to impress, with a polished site and a carefully chosen happy path. Your job is to redirect it toward the questions that actually decide whether this product fits your platform. A strong vendor will welcome that. Deflection is itself an answer.
Bring this short list to the demo, and ask them to demonstrate, not describe:
Multitenancy. Ask how tenant data is isolated at the database layer, and have them show it. Separate logical databases or schemas are far easier to reason about than a tenant id stamped on every record. The real question behind the question: how much does correct isolation depend on every developer remembering to handle it, on every line?
Deployment. Ask whether self-hosting is genuinely supported or merely tolerated. If you need it for data residency, have them stand up a self-hosted instance, or at least walk the docs that show how. For managed hosting, ask exactly what you are paying for, in units of real capacity rather than dynos.
Cost at your scale. Give them your actual tenant count and ask for a real quote. Understand the two axes separately: licensing, which typically scales with the number of sites (ask about volume discounts at your scale), and hosting, which should scale with the capacity you actually use, not a per-site fee. Be wary of hosting priced in vague units like dynos rather than real capacity.
Security. Ask to see the code, since an open or source-available core is something you can actually inspect. Remember that operational certifications like SOC 2 apply mostly to hosting practices, not the CMS software itself. Most telling of all: ask what they don't yet have. A vendor who answers plainly is more trustworthy than one who deflects to a logo.
Integration. Ask them to walk through how content from your own REST or GraphQL APIs gets onto a CMS-driven page, with a real example from an existing customer or their docs. Ask what stack your developers will actually be writing in, and whether you can run it on the database your team already knows.
Editing experience. Ask to edit real content directly on the page, then resize to a phone and do it again. Ask to see a draft that differs from what visitors see, and an approval step if your customers will need one. Watch whether editing happens in context, or banishes the user to a separate back end.
Migration. Describe your current system and ask them to walk the export-to-import path concretely, ideally showing a real GET, transform, and POST from a past migration. Ask specifically how images and other linked assets come across, because that is where blog migrations quietly fail.
The throughline is simple. The right CMS for your SaaS platform is the one whose vendor is comfortable with this entire conversation: open about its architecture, transparent about its pricing, and honest about its limits. Those are the same qualities you will be relying on long after the demo, the night something breaks and you need to understand exactly what you are running.
These are the questions we hope you will ask us.
