A Content Management System (CMS) is software that lets you create, edit, and publish content on a website through an interface instead of writing HTML files by hand. WordPress, Drupal, Ghost, Strapi, and Contentful are all CMS platforms — but they work in fundamentally different ways, and understanding those differences matters when you need to deploy, scale, and maintain a site.
This article is written for developers and teams who need to choose a CMS, understand how it fits into a deployment workflow, and avoid the architectural decisions that become expensive to reverse later.
How a CMS Works
Every CMS has three core components, regardless of whether it is WordPress or a headless API:
flowchart LR
A[Content editor] --> B[Content storage]
B --> C[Content delivery]
- Content editor — The interface where authors create and manage content. This can be a rich text editor in a browser, a Markdown file in a Git repository, or a structured form with custom fields.
- Content storage — A database or file system where content is persisted. MySQL for WordPress, PostgreSQL for many headless platforms, flat files for static site generators.
- Content delivery — How content reaches visitors. Traditional CMS platforms render HTML on the server. Headless platforms deliver content via API, and a separate frontend renders it.
The fundamental split in the CMS world comes down to how tightly these three components are coupled.
Traditional vs. Headless vs. Hybrid CMS
This is the most important architectural decision when choosing a CMS. It affects how you deploy, how you scale, and what your team needs to maintain.
Traditional CMS
A traditional (or monolithic
) CMS bundles the editor, storage, and delivery into a single application. WordPress, Drupal, and Joomla all follow this pattern. You install the CMS on a server, and it handles everything — from the admin panel to the rendered HTML that visitors see.
How deployment works: You deploy the entire application as one unit. Code changes, theme updates, and plugin installations all go to the same server. Tools like DeployHQ push your Git repository directly to the server, and the CMS handles the rest.
Best for: Content-heavy sites where the editorial team needs a familiar interface, plugin ecosystems matter, and the development team is comfortable with PHP or the CMS's native language.
Headless CMS
A headless CMS separates the backend (content editing and storage) from the frontend (content delivery). The CMS provides a REST or GraphQL API, and you build a separate frontend application — in React, Next.js, Vue, Astro, or whatever framework you prefer — that fetches content from that API.
How deployment works: You deploy two things independently: the CMS backend (API) and the frontend application. Each has its own repository, build process, and deployment pipeline. This is where the complexity increases — but also where the flexibility pays off. See our guide to deploying headless CMS platforms for the practical setup.
Best for: Teams building multi-channel content (website + mobile app + kiosk), projects that need a modern frontend framework, or organisations where the content team and development team work on different release cadences.
Hybrid CMS
Hybrid platforms offer both a built-in frontend and an API layer. WordPress with the REST API enabled, Drupal with JSON:API, and platforms like Payload CMS fit this model. You can use the traditional rendering when it works and switch to API-driven delivery when you need it.
How deployment works: Same as traditional if you use the built-in frontend. If you add a decoupled frontend, you deploy both — similar to headless, but with the option to fall back to server-rendered pages.
Best for: Teams migrating from traditional to headless incrementally, or projects that need server-rendered pages for some sections and API-driven content for others.
Comparison Table
| Traditional | Headless | Hybrid | |
|---|---|---|---|
| Editor + delivery | Coupled | Decoupled | Optional |
| Frontend | Built-in themes | Custom (React, Vue, etc.) | Both |
| Deployment | Single application | Two separate deploys | Depends on usage |
| API access | Limited or add-on | Native REST/GraphQL | Native |
| Time to launch | Fast (themes + plugins) | Slower (custom frontend) | Moderate |
| Scaling | Scale entire app | Scale frontend and backend independently | Flexible |
| Content reuse | Website only | Any channel (web, mobile, IoT) | Any channel via API |
The Major CMS Platforms
Traditional
| Platform | Language | Database | Strengths |
|---|---|---|---|
| WordPress | PHP | MySQL | Largest ecosystem, 60%+ CMS market share, thousands of plugins and themes |
| Drupal | PHP | MySQL/PostgreSQL | Granular permissions, multi-site, strong for enterprise and government |
| Joomla | PHP | MySQL | Middle ground between WordPress simplicity and Drupal power |
WordPress dominates this category and it is not close. If you are building a content site and want access to the largest ecosystem of themes, plugins, and developers, WordPress is the default choice. Drupal is the alternative when you need fine-grained access control, complex content types, or multi-site management at enterprise scale.
Headless
| Platform | Type | API | Strengths |
|---|---|---|---|
| Strapi | Self-hosted, open source | REST + GraphQL | Full control, customisable content types, no vendor lock-in |
| Contentful | SaaS | REST + GraphQL | Managed infrastructure, CDN-backed delivery, rich media handling |
| Sanity | SaaS + open source | GROQ + GraphQL | Real-time collaboration, portable text format, flexible schemas |
| Ghost | Self-hosted or SaaS | REST | Focused on publishing, built-in newsletters, clean editor |
| Payload CMS | Self-hosted, open source | REST + GraphQL | TypeScript-native, code-first config, hybrid rendering support |
The self-hosted vs. SaaS decision is significant. Self-hosted platforms (Strapi, Ghost, Payload) give you full control and no per-seat pricing, but you manage the infrastructure. SaaS platforms (Contentful, Sanity) handle infrastructure and scaling, but lock you into their pricing model and API.
Static Site Generators (CMS-Adjacent)
Static site generators like Hugo, Jekyll, Eleventy, and Astro are not CMS platforms in the traditional sense — they do not have a content editor. But paired with a headless CMS or Markdown files in Git, they produce static HTML that is fast, secure, and trivial to deploy. DeployHQ can deploy static sites directly from your repository with a build step to compile the output.
How CMS Deployment Works
Deployment strategy depends entirely on which CMS architecture you chose. Here is how each one maps to a typical workflow:
flowchart TD
subgraph Traditional
A[Git push] --> B[DeployHQ transfers files]
B --> C[Server runs CMS]
end
subgraph Headless
D[Git push frontend] --> E[Build step]
E --> F[Deploy to CDN or server]
G[CMS API runs separately]
F --> G
end
subgraph Static
H[Git push] --> I[Build static HTML]
I --> J[Deploy to CDN or server]
K[Headless CMS webhook triggers rebuild]
K --> H
end
Deploying a Traditional CMS
Traditional CMS deployment is straightforward: your Git repository contains the CMS codebase (or at least your custom theme and plugins), and a deployment tool pushes changes to the server.
1. Store your theme and custom plugins in Git. Do not commit the entire WordPress core — install it on the server and manage updates separately.
2. Connect your repository to DeployHQ and configure the deployment target (your server via SFTP, SSH, or rsync).
3. On each push to your main branch, DeployHQ transfers only the changed files to the server. No build step needed for most traditional CMS setups.
4. Run post-deployment commands if needed — cache clearing, database migrations, or service restarts via deployment scripts.
For zero-downtime deployments, use atomic deployments with symlink swapping so the CMS is never in a partially-updated state.
Deploying a Headless CMS
Headless CMS deployment involves two independent pipelines — one for the CMS backend and one for the frontend. This is covered in detail in our headless CMS deployment guide.
The key difference: content changes in a headless CMS do not require a code deployment. The CMS API serves content dynamically. Code deployments only happen when the frontend application or the CMS configuration changes.
Deploying a Static Site with a CMS
Static sites built from CMS content (e.g., Astro pulling from Contentful, Hugo pulling from Strapi) need a rebuild whenever content changes. The typical setup:
1. The headless CMS fires a webhook when content is published.
2. The webhook triggers a CI/CD pipeline that rebuilds the static site.
3. The build output (HTML, CSS, JS) is deployed to a CDN or server via DeployHQ.
This gives you the performance benefits of static HTML with the editorial convenience of a CMS.
Choosing the Right CMS
The decision matrix is simpler than most CMS comparison articles make it:
Choose traditional (WordPress/Drupal) when:
- Your content team needs a familiar, full-featured editor with plugins
- You want to launch quickly with existing themes
- The content only needs to appear on one website
- Your team is comfortable with PHP
Choose headless (Strapi/Contentful/Sanity) when:
- You need to deliver content to multiple channels (web, mobile, IoT)
- Your frontend team wants to use React, Next.js, Vue, or another modern framework
- Content and code need to deploy on different schedules
- You want API-first architecture for future flexibility
Choose static + headless CMS when:
- Performance and security are top priorities
- Content changes are infrequent (blog, documentation, marketing site)
- You want the simplest possible hosting (CDN, no server to maintain)
Choose hybrid when:
- You are migrating from traditional to headless incrementally
- Some pages benefit from server rendering while others need API access
- You want to keep your options open
Common CMS Mistakes
Choosing based on the editor, ignoring deployment. A CMS with a beautiful editor means nothing if your team cannot deploy it reliably. Before committing, map out how the CMS fits into your deployment workflow — who deploys, how often, and what breaks when it goes wrong.
Going headless when traditional would work. Headless adds complexity: two deployments, API latency, CORS configuration, authentication between services. If your content only appears on one website and you do not need a custom frontend, a traditional CMS with a good theme is simpler and faster to ship.
Committing CMS core files to Git. WordPress core, Drupal core, and plugin directories should be managed by the CMS's own update system, not version-controlled in your repository. Commit your custom theme, custom plugins, and configuration — not third-party code that gets updated independently.
Ignoring content modelling. The CMS structure you set up in week one is hard to change in month six. Spend time designing your content types, taxonomies, and relationships before creating content. Headless CMS platforms enforce this through schema definitions; traditional platforms make it optional, which means it often gets skipped.
No staging environment. Updating a CMS plugin directly on production is a gamble. Set up a staging environment that mirrors production and test plugin updates, theme changes, and PHP version upgrades there first.
FAQs
What is the difference between a CMS and a website builder?
A CMS (WordPress, Drupal, Strapi) gives you full control over the code, hosting, and deployment. A website builder (Wix, Squarespace, Webflow) is a managed platform where the hosting, editor, and rendering are all controlled by the provider. Website builders are faster to start but harder to customise beyond their templates. A CMS is more work to set up but gives you complete flexibility.
Do I need a CMS for a small website?
Not necessarily. If the content rarely changes (a portfolio, a small business landing page), a static site built from HTML files or a static site generator is simpler and cheaper to host. A CMS adds value when multiple people need to edit content, when content changes frequently, or when you need structured content types (blog posts, products, events).
What is a headless CMS?
A headless CMS provides the content editing and storage backend without a built-in frontend. It delivers content via API (REST or GraphQL), and you build a separate frontend application to display it. This decoupling lets you use any frontend framework and deliver content to multiple channels. See our headless CMS deployment guide for the practical setup.
Can I deploy a CMS with Git?
Yes. Most CMS platforms work well with Git-based deployment. For traditional CMS platforms, you version-control your custom theme and plugins and deploy via SFTP or SSH. For headless platforms, both the backend and frontend are typically deployed from separate Git repositories with their own build pipelines.
How do I migrate from one CMS to another?
Content migration involves exporting content from the source CMS, transforming it to match the target CMS's schema, and importing it. Most CMS platforms provide import/export tools or APIs. The harder part is migrating custom functionality — themes, plugins, and integrations. Plan for a parallel-running period where both systems serve content while you validate the migration.
Ready to deploy your CMS? Sign up for DeployHQ and connect your Git repository to start deploying WordPress, Strapi, Ghost, or any other CMS platform in minutes.
For questions about CMS deployment, reach out at support@deployhq.com or find us on X (@deployhq).