What Is Drupal? A Beginner’s Guide to the Open-Source CMS

What is Drupal? Drupal is a free, open-source content management system written in PHP. It powers a meaningful share of the world’s most demanding websites: government portals, university systems, large nonprofit and association sites, multilingual enterprise content properties, and complex publishing operations. It is one of the three major open-source CMS platforms (alongside WordPress and Joomla) and the one most often chosen when content models are intricate, access requirements are strict, or the site needs to scale beyond what a simpler CMS can support cleanly.

This post explains what Drupal actually is, how it compares to WordPress and other CMS options, the modular architecture that defines its developer experience, what you need to run a Drupal site, and when Drupal is the right choice (versus when it is not). If you are evaluating CMS options, inheriting an existing Drupal site, or trying to understand the broader open-source web stack, start here.

What Drupal actually is

Drupal was first released by Dries Buytaert in 2001 as an open-source bulletin board project and has grown into one of the most widely-used enterprise-class content management systems in the world. The official project home is at drupal.org, which hosts the source code, contributed modules, documentation, and the community infrastructure that maintains the platform.

The defining characteristics:

• Free and open source: Drupal is released under the GPL license. No licensing fees, no per-seat costs, no commercial lock-in at the platform level. Hosting, modules, themes, and development services all have costs; the platform itself does not.
• Written in PHP: like WordPress and most major open-source CMSs, Drupal is a PHP application. This means it runs on the most widely-supported web hosting stack on the internet (Apache or Nginx, PHP, MySQL or PostgreSQL).
• Modular architecture: Drupal core is intentionally lean; functionality comes from modules. Drupal.org hosts thousands of contributed modules for everything from e-commerce to multilingual content to single sign-on. Custom modules extend the system further for site-specific needs.
• Content-first: where WordPress was originally designed for blogs and grew toward broader content management, Drupal was designed from the start for structured content. Custom content types, taxonomy, relationships between content items, and granular permissions are core platform concerns, not bolted-on plugins.

Drupal’s notable users have historically included Whitehouse.gov (during the Obama administration), Australia’s federal government, NASA, The Economist, the City of Los Angeles, and a long list of major universities. The pattern: institutions with serious content governance requirements that need flexibility a simpler CMS cannot provide.

How Drupal differs from WordPress and other CMS platforms

This is the question most operators ask first. The short answer: WordPress and Drupal have meaningfully different design philosophies, and the right choice depends on what your site actually needs.

WordPress powers the largest share of CMS-driven websites. It started as a blogging platform and grew outward; its strengths are simplicity for content editors, a vast theme and plugin ecosystem, and a low learning curve. For most small business websites, marketing sites, and simple blogs, WordPress is the default and a defensible choice.

Drupal is structurally more flexible at the cost of a steeper learning curve. Its strengths are complex content models, fine-grained access control, multilingual content handling, and the ability to model relationships between content types. For government, higher education, large nonprofits, and enterprises with intricate content governance, Drupal handles cases WordPress would require many plugins (and meaningful custom development) to approximate.

Joomla sits in between in terms of capability and complexity. Its community is smaller than either WordPress or Drupal, and its growth has slowed relative to the other two over the past decade.

Two more recent options worth knowing about:

• Headless CMSs (Contentful, Sanity, Strapi) separate the content management layer from the presentation layer entirely. A team chooses a headless CMS when the front-end needs maximum flexibility (often a JavaScript framework like React or Vue) and the backend’s job is purely content storage and API delivery.
• Static site generators (Hugo, Jekyll, Eleventy) compile content into static HTML at build time. They suit content-light, performance-sensitive sites without dynamic interactivity needs.

For a typical small or mid-sized business website with a marketing focus and a contact form, WordPress is usually the right call. For an organization with complex content types, strict access governance, multilingual content, or compliance-driven content workflows, Drupal earns its complexity.

Drupal’s modular architecture

Drupal’s design centers on the concept of modules. The core platform provides the essentials (user accounts, content storage, basic permissions, the request lifecycle), and modules extend it for everything else.

Three categories of module matter:

• Core modules: ship with Drupal itself. Include node (content), user, taxonomy, views (query builder), menu, and so on. These define the platform’s baseline capability.
• Contributed modules: maintained by the community, hosted on drupal.org. Thousands of options for specific functionality: webform builders, commerce integration, single sign-on, SEO tooling, search integration, image manipulation, social media integration, and so on. The strength of any open-source CMS is partly its contributed ecosystem; Drupal’s is large and active.
• Custom modules: written by the site’s developer for project-specific functionality. Drupal’s module API is documented and stable; building a custom module is a defined development task.

Beyond modules, Drupal’s architecture includes:

• Themes: separate the site’s presentation layer from its content and functionality. A site can change themes (or run different themes on different sections) without touching content or modules.
• Configuration: in modern Drupal, site configuration (content types, fields, views, permissions, and more) is exportable as YAML files. This lets configuration travel with the codebase through version control, code review, and deployment.
• Entities: Drupal’s unified data model. Nodes (content), users, taxonomy terms, and custom data types are all “entities” with consistent APIs for storage, querying, and rendering.

The architecture rewards investment in understanding the platform’s patterns. Sites built by teams that learn Drupal deeply tend to age well; sites built by teams that fight the platform’s patterns tend to age painfully.

What you need to run Drupal

The technical stack to run a Drupal site:

• Web server: Apache or Nginx. Most managed Drupal hosts run Nginx; both work.
• PHP: a recent version. Drupal 9 (the current version as of this post) supports PHP 7.4 and 8.0; the version requirement tightens with each major release.
• Database: MySQL, MariaDB, or PostgreSQL. SQLite is supported for development environments.
• Composer: PHP’s dependency manager. Modern Drupal installation goes through Composer rather than the older “download and extract” path.

For most teams, the realistic deployment path is a managed Drupal host rather than self-managed infrastructure:

• Pantheon: developer-focused managed hosting with strong git-based deployment workflows.
• Acquia: founded by Drupal’s creator Dries Buytaert; enterprise-focused with rich tooling around Drupal-specific operations.
• Platform.sh: developer-focused multi-stack host with strong Drupal support.
• Self-managed: AWS, Google Cloud, DigitalOcean, or a traditional VPS, with the operator handling stack maintenance, security patches, and scaling.

Managed hosting costs more per month but reduces the operational burden of running a non-trivial CMS. For a typical small or mid-sized organization, the managed-host route is usually the right trade.

When Drupal is the right choice

Drupal earns its place over WordPress (or other CMSs) when several of these are true:

• Your content model is complex (multiple custom content types with relationships between them).
• Your access control is granular (different user roles need different permissions on different content types in different states).
• You need multilingual content with translation workflows built into the platform.
• You have multi-site or multi-domain content syndication needs.
• You need to comply with government accessibility standards (Drupal’s accessibility track record is strong).
• Your team has, or can develop, Drupal-fluent development capacity.

Drupal is the wrong choice when:

• The site is a simple blog or basic marketing page (WordPress is faster and cheaper to operate at that scale).
• The team has no PHP or CMS development background and the budget will not support hiring that expertise.
• The site’s primary purpose is pure e-commerce (Shopify or a commerce-focused platform often fits better).
• The site is content-light enough that a static site generator handles it cleanly.

For organizations in the right fit, Drupal’s flexibility pays back over years; the upfront complexity is the price of admission. For organizations in the wrong fit, Drupal’s flexibility becomes overhead the team carries without benefit.

Update (2026-05-12): the Drupal landscape since this post first published.

Several major Drupal milestones have landed since the original 2022 publication of this post. The foundational explanation of Drupal above still holds; the version landscape has moved substantially:

• Drupal 10 released December 2022, raising the PHP minimum to 8.1 and introducing significant frontend improvements. It reaches end of life on December 9, 2026 (covered in our companion post on the deadline).
• Drupal 11 released August 2024, introducing the Recipes system, Single Directory Components, and (in subsequent minors) major performance improvements. We cover Drupal 11 in detail in our pillar overview.
• Drupal 9 reached end of life November 2023.
• Drupal 7 reached end of life January 5, 2025 after multiple extensions. Sites still on Drupal 7 should be planning migration urgently.
• Drupal 12 is planned for release in 2026 with release-window candidates in August or December depending on beta readiness.
• The Symfony foundation that underlies Drupal since version 8 has continued to evolve; Drupal 11 ships on Symfony 7. Our piece on how Drupal is built on Symfony covers the architectural relationship.

The "what is Drupal" answer in the body of this post remains correct. The "which version should I be on" answer in 2026 is Drupal 11, with Drupal 10 sites needing to plan migration before December 9, 2026.

Frequently Asked Questions