Drupal
Flexible enterprise CMS for complex content structures
Drupal is a robust open-source content management framework suited to large, complex websites with structured content and demanding requirements. It is known for granular permissions, multilingual support, and an extensible module architecture.
Key features
- Structured content modeling
- Strong multilingual support
- Granular access control
- Headless and decoupled options
Pros & cons
Strengths
- Scales to very large sites
- Enterprise-grade security track record
Trade-offs
- Steep learning curve
- Heavier hosting requirements
Drupal replaces
Last reviewed Sep 13, 2026 · 817 words
Do not pick Drupal for a blog, a portfolio, or a five-page site for a club. WordPress or Ghost will be live in an hour and you will resent Drupal every week after. Drupal earns its Hard rating and its 1 GB baseline when content is structured: dozens of content types with typed fields and references between them, an editorial workflow with roles that see different things, several languages, and listings that have to be assembled from all of that without a developer writing a query. For that site, it is the most capable self-hosted option there is, and it has been since 2001.
Choose Drupal when your content has a schema
The core idea is that everything is an entity with fields. A "course" content type has a reference to a "lecturer" entity, a taxonomy term for its department, a date field, a file field for the syllabus. Views, in core, lets an editor build a listing page or block from those fields with filters, sorting and paging, no code. Content moderation gives draft, review and published states per role. Configuration translation and content translation are core modules rather than paid add-ons. Granular permissions go down to individual fields, which is why universities, governments and publishers run it. Everything that is a plugin or a premium tier elsewhere is core here, and the price is the learning curve.
Composer or nothing
Modern Drupal is installed and updated with Composer, and every shortcut around that ends in pain:
composer create-project drupal/recommended-project mysite
cd mysite
composer require drush/drush drupal/pathauto drupal/redis
vendor/bin/drush site:install --db-url=pgsql://drupal:pw@localhost/drupal
Modules are composer required, updates are composer update followed by drush updatedb, and nothing under vendor/ or web/core/ is ever edited by hand. The official drupal Docker image is good for a first look but ships the codebase inside the image, so a real deployment builds its own image from a Composer project with the code in your repository. Drupal CMS, the packaged distribution launched for marketing teams, sits on top of the same Composer workflow with sensible modules preselected, and is the better starting point than bare core for a first site.
Hosting numbers that are honest
PHP 8 with OPcache, MySQL or PostgreSQL, and 1 GB of RAM as the catalogue floor. I would call 2 GB comfortable once Redis is in the mix. The internal page cache and dynamic page cache in core mean anonymous traffic is cheap; logged-in editors are what cost CPU. Cron has to run, hourly is typical, via drush cron from the host's crontab rather than the built-in "automated cron" that piggybacks on page requests. Public files live in web/sites/default/files, private files belong outside the web root, and trusted_host_patterns in settings.php must match your domain or the status report will nag you and, more importantly, host-header tricks become possible. A reverse proxy in front is standard.
Security updates are a calendar commitment
The Drupal security team publishes advisories on Wednesdays, and core security releases are announced a week ahead so operators can be at a keyboard. Sites that ignored those windows are how the 2014 and 2018 "Drupalgeddon" bugs turned into mass compromises within hours of disclosure. The flip side is that the track record for fixes is excellent and the process is public. Budget a monthly update slot plus the occasional same-day patch. Major versions arrive on a roughly two-year cadence and the upgrade between them is usually a Composer bump, unlike the Drupal 7 to 8 rewrite that kept sites on 7 until its end of life in January 2025.
Headless: Drupal as the backend, something else as the front
JSON:API ships in core, so a React or Next.js front end can read every entity and field without extra modules, and Drupal becomes an editorial backend with a mature permission model. That is the point at which it competes with Strapi rather than WordPress. Strapi is lighter and friendlier for a developer defining a content model from scratch; Drupal wins when editors need workflow, translation and revisions on that model, and when the team already knows it.
What I'd do
For anything under about 50 pages with one or two editors: WordPress or Ghost, and keep the weekend. For a structured, multilingual, permission-heavy site, or an Adobe Experience Manager replacement that a real team will maintain: Drupal CMS on a Composer project, PostgreSQL, Redis, 2 GB, drush cron hourly, a monthly update slot and a rule that Wednesday advisories get read the day they land. It is a lot of process for a content site, and for the right site it is the only free tool that scales to the job.
Compare Drupal
8 head-to-head comparisons.
Similar content management systems apps
Ghost
Content Management SystemsProfessional publishing platform for blogs and newsletters
Replaces WordPress, Substack
Payload CMS
Content Management SystemsTypeScript-native headless CMS and application framework
Replaces Contentful, Sanity
Docsify
Content Management SystemsDocumentation site generator
Replaces GitBook
WordPress
Content Management SystemsThe most popular content management system in the world
Replaces Wix, Squarespace
Wagtail
Content Management SystemsDeveloper-friendly Django CMS with a great editor experience
Replaces Adobe Experience Manager, WordPress
Grav
Content Management SystemsFast flat-file CMS with no database required
Replaces WordPress, Squarespace