Drupal CMS and Canvas site building guide

When Drupal CMS is the right starting point for a Drupal site

Drupal CMS is usually the better starting point when a team needs a working Drupal site quickly and the people who will build and edit pages are marketers and content teams. It is a distribution built on Drupal core, packaged for those users with recipes, site templates, Drupal Canvas (previously Experience Builder) and optional AI tools. Drupal CMS 2.0 is the current major release. Bare Drupal core makes more sense when the site's architecture, content model and integrations are the main concern from day one and the team is ready to assemble those pieces itself.

The choice is harder than it looks because a distribution's defaults become the site's defaults. Recipes install content types, fields, roles, views and contributed modules, and once those are in configuration management and in use by editors, removing or replacing them carries real cost. Before committing, list every recipe you plan to apply, the configuration it creates, the roles it defines and the modules it pulls in. Decide which of those you would keep, which you would change, and who owns each decision after launch.

Drupal Canvas and the AI tools need their own evaluation against your organization's requirements. For Canvas, check who may change page layouts, how components are governed, whether the component library matches your brand and design system, and whether editor output meets your accessibility and performance standards. For AI features, check what content is sent to which service, where processing happens, how outputs are reviewed, and whether your data policies permit use. Confirm the current maturity of Canvas and the AI features with Drupal.org before deciding, because feature status and stability can change between releases.

The starting point also shapes later work. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Confirm that the Drupal CMS release you choose supports the core version you plan to run, how quickly distribution updates follow core updates, and what moving off the distribution would involve if your needs change. Treat the choice as a starting point that you review at each major release, not as a permanent commitment.

Which Drupal CMS parts a build actually uses

Drupal CMS is a distribution built on Drupal core, so every part below sits on the same foundation and release cycle. Each component changes something different in the site: content types, configuration, theme, permissions or editorial workflow. Map each one to the team that will own it before applying anything.

Drupal core as the foundation

Drupal core provides the content entity system, users and permissions, configuration management and the release cycle that every Drupal CMS site inherits. Because Drupal CMS is built on core, core release timing and PHP requirements still apply to your build. Drupal 11 requires PHP 8.3 or later, and Drupal 10 reaches end of life on December 9, 2026. Confirm that your hosting supports the required PHP version and a supported database before choosing a starting point.

The Drupal CMS distribution

A distribution is a packaged Drupal site: core, a curated set of contributed modules, a theme and default configuration, aimed at marketers and content teams. Drupal CMS 2.0 is the current major release. Installing it sets up the initial content types, configuration, theme and permissions, so it fits best on a fresh codebase. Review the contributed modules it brings in and confirm your team can own their updates within your Composer workflow.

Recipes as configuration bundles

Recipes are reusable configuration bundles applied to a site to add a capability, such as a set of content types, fields, views or roles. Each recipe writes configuration, so review what it changes before running it on a site with live content. Check whether it depends on modules your site does not yet have, what permissions it grants and how it behaves if applied again. Keep applied recipes in version control so their changes pass through review like any other code change.

Site templates for starter structure

Site templates are starter sites that combine recipes into pages, navigation and sample content for a common use case. They are the fastest route to a working site, but they fix the content model early. Check the content types and blocks the template creates, whether it installs sample content that must be removed and how its theme will be replaced to match your brand. Choose the template before editorial teams begin entering content, since changing structure later carries a rework cost.

Drupal Canvas visual page builder

Drupal Canvas, previously called Experience Builder, is the visual page builder meant to let content teams assemble pages with less developer involvement. It affects how layouts and components are created, so it touches the theme and component library your developers maintain. Confirm current component support, supported field types, and how Canvas pages are versioned and exported against the current Drupal.org documentation before relying on any of them. Test editor permissions on a staging site before rollout.

Optional AI tools

Drupal CMS offers optional AI tools, but their features, supported model providers and data handling can change between releases, so confirm them against the current Drupal.org documentation before scoping. Many AI features need an external provider account, API keys and outbound network access, which adds a data residency and vendor review step. Identify which content leaves the site, which permissions gate each feature and who approves enabling it. Trial these tools in a non-production environment first.

Drupal CMS or bare Drupal core: the decisions and trade-offs

This table compares three ways to start a Drupal site: Drupal CMS with recipes, Drupal core with a custom install profile, and Drupal core with contributed modules only. Read each row as a decision the team must make before the first build sprint, then check the operational cost on the right. The main takeaway is that Drupal CMS shortens setup for content teams but adds a distribution and recipe layer that someone must own after launch.

Decision	Drupal CMS with recipes	Drupal core with a custom install profile	Drupal core with contributed modules only
When it fits	Content teams need editor-friendly site building, site templates and Drupal Canvas page building soon after launch	Team has strong Drupal skills and wants a repeatable, organization-specific starting point across several sites	Team wants minimal inherited structure and is comfortable assembling every module, configuration and theme itself
Upgrade path	Follows Drupal CMS release versions on top of Drupal core, so distribution and recipe updates must be applied with core updates	Upgrades are owned by the team that maintains the profile and its custom code on each Drupal major version	Upgrades follow core and each contributed module, with no distribution layer to track
Custom code volume	Lower at launch, but custom integrations, Canvas components and bespoke content types still need custom modules	Highest up front, because the profile, default configuration and custom modules are written and tested by the team	Moderate, depending on how many contributed modules must be combined and how much glue code is needed
Dependency on recipes	High: recipe changes after launch can alter configuration on existing sites if not reviewed	None from a distribution, but configuration must be managed directly through Configuration Management	None from a distribution; dependency is on individual contributed modules and their maintainers
Training needs	Editors learn Canvas and recipe-based site building; developers learn how recipes apply to the site	Developers need deep knowledge of install profiles, configuration and custom module APIs	Developers need broad knowledge of contributed module selection, configuration and testing
Canvas and AI tools at launch	Confirm whether Canvas and optional AI tools are needed at launch; enabling later keeps the initial configuration smaller and easier to review	Enable only the modules the profile ships with, adding Canvas later through a reviewed configuration change	Canvas is available only if its contributed module is installed and assessed for the Drupal version in use
Ownership of recipe changes after launch	Assign a named owner for applying recipe updates, with a review step that checks configuration changes before they reach production	The team that maintains the install profile owns changes, approvals and release notes	Not applicable; each configuration change is owned by the team that makes it and reviewed through the normal change process

How to build a Drupal CMS site step by step

This sequence takes a team from a chosen Drupal CMS release to a launch-ready site with version-controlled configuration. Each step ends with a check the team can verify before moving on, so problems surface in the non-production environment.

Confirm requirements and install on non-production
The team confirms the PHP and database requirements for the Drupal CMS release it has chosen before installing anything. Check the PHP version against the Drupal.org PHP requirements page: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. Confirm that the web server and database (MariaDB, MySQL, PostgreSQL or SQLite) are supported, then install the distribution in a non-production environment. The step is complete when the install finishes cleanly and the status report shows no errors.
Review recipes and site templates
Before applying any recipe or site template, the team reads what it changes and lists the content types, fields, views, roles, modules and configuration it adds. Apply recipes one at a time on the non-production site and export configuration after each one. Ask the Drupal CMS maintainers or your implementation partner to explain anything the documentation leaves open. The step is complete when the team holds a written list of every change each recipe makes and has checked that list against the content model and the access rules the organization needs.
Define content types and editorial roles
Content owners, editors, reviewers and publishers work with the platform team to define content types, required fields and the roles that will create and approve content. Map each role to the actions it needs, including any Content Moderation workflow states. Test each role on the non-production site by completing its tasks and attempting tasks it should not have. The step is complete when a signed role matrix matches the permissions observed in testing, and no role can perform actions outside its matrix.
Build pages in Drupal Canvas
Limit the first build to a small set of representative pages, such as a home page, a landing page, an article template and a campaign page. Editors build these pages in Drupal Canvas using the available components, and developers record every component gap they hit. Confirm in the release documentation which Canvas features the chosen release includes. The step is complete when an editor who was not involved in the build can publish a page without developer help, and the pages pass a mobile layout and accessibility review.
Decide AI tool use and governance
The organization decides which optional AI tools in Drupal CMS are enabled, and for which content and users. For each tool, the team documents what data it processes, where that processing happens, who approves its use, how its output is reviewed by a person, and how activity is logged. Security, legal and content leads approve the record before the tool goes on. The step is complete when the approved governance record exists, and a configuration check confirms that any tool not approved is disabled in the exported configuration.
Add custom modules and theme work
For requirements that no recipe or contributed module covers, the team builds custom modules and theme work. Prefer contributed modules where they meet the requirement and are actively maintained, and confirm their compatibility with the chosen core version first. Custom code follows Drupal coding standards, includes automated tests and has a named owner. The step is complete when each custom module has passing tests, a code review record and documentation of what it does and what depends on it.
Export configuration to version control
The team exports the full site configuration and commits it to version control, keeping environment-specific values such as database credentials and hostnames out of the exported files. Every change from the recipes, roles, Canvas pages and custom modules should appear in the export. Review the diff against the previous export before each commit. The step is complete when a fresh install built from the repository reproduces the site, and the diff contains only the changes the team intended.
Run content and permissions review
Before launch, the team audits seeded and placeholder content, checks links and accessibility on key templates, and reviews every role and account, including administrator accounts and anonymous access. Compare the effective permissions for each role against the signed role matrix. Confirm that the launch checklist is complete and that an owner has signed off each area. The step is complete when the permissions review finds no unexpected access, all placeholder content has been replaced or removed, and the launch checklist is signed.

What drives the effort and cost of a Drupal CMS build

This table lists the main factors that change how much work a Drupal CMS and Drupal Canvas build requires, how each one raises effort, and what keeps it contained. Read each row as a lever you can set during scoping, since most of the variation in a fixed-scope quote traces back to these choices. The largest savings usually come from agreeing the page template set, the editor roles and the custom module list before development starts.

Driver	How it raises effort	What keeps it down
Content types and page templates	Each content type needs fields, display modes, listing views and editorial rules. Each new Canvas page template adds layout, component mapping and testing work.	Limit Canvas templates to a defined set agreed in writing. Reuse existing recipe content types where they fit the content model.
Editors and roles	Every role needs permissions, workflow states and test accounts. Roles that differ only slightly still need to be verified separately.	Start from a small set of roles and add more only when an editorial process requires it. Confirm the workflow before build.
Identity provider integrations	SAML or OpenID Connect sign-in needs attribute mapping, role mapping from identity provider groups and handling of local admin accounts. Each provider adds testing.	Use one identity provider where possible. Use the contributed SAML Authentication or OpenID Connect modules where they fit the requirement.
CRM and marketing tool integrations	Each connection needs API credentials, field mapping, error handling and monitoring. Two-way sync is considerably more work than one-way publishing.	Limit the first release to one-way data flows. Confirm which integrations already have maintained contributed modules.
Data volume and migrated content	Large content sets, media libraries and migrated translations extend import scripts, validation and cutover rehearsal. Messy source data adds cleaning work.	Audit source content before scoping. Agree which content is migrated and which is archived or left out of the first release.
Custom modules beyond recipes	Logic that no recipe or contributed module covers requires custom code, tests, code review and long-term maintenance by someone.	Confirm the recipe and contributed module options first. Keep custom code to the behavior the organization actually differentiates on.
Number of environments	Development, staging and production each need configuration sync, deployment steps, data handling rules and access control. More environments add pipeline and testing work.	Agree a minimal environment set and a single configuration sync process. Confirm how content is refreshed between environments.
Compliance and accessibility review	Accessibility checks, audit evidence such as change records and access reviews, and security testing add review cycles. Remediation after review is often the least predictable item.	Define the accessibility standard and evidence list at scoping. Ask whether the Canvas components you plan to use have been checked against it.

How Drupal CMS deployment differs by environment

This is the simplest model. One web server runs Apache or Nginx with PHP, and the database runs on a managed service operated by your cloud or hosting provider. Drupal's system requirements list MariaDB, MySQL, PostgreSQL or SQLite as database options, so the managed service must match one of them.

File storage: Uploaded media stays on the server's local disk unless you move it to network or object storage. Confirm which option your hosting setup supports.
Configuration sync: With one node, configuration export and import run against a single codebase. The main risk is drift between development and production settings.
Packages: Composer pulls recipes, modules and themes from public repositories during build or deployment, so the server needs outbound access at those moments.
AI tools: Optional AI tools may call external model services. Confirm hosting and data-flow requirements in the vendor documentation before enabling them.

Check that the managed database version and engine appear on the supported system requirements list, and that backups cover both the database and the file directory.

Securing Drupal CMS editors, Canvas pages and AI tools

Drupal CMS bundles recipes, site templates, Drupal Canvas and optional AI tools into one distribution, so editors gain more reach than a bare core site gives them by default. The controls below cover who can change what, which tools can send data out, and how security fixes reach both core and the distribution. Each card names what to review and what evidence to keep.

Review permissions from recipes

Recipes and site templates change role configuration when they run, so a recipe applied during build can grant more access than the team approved. Export the role configuration after each recipe run and compare it with an approved permission matrix. Check that editor roles cannot administer users, modules or text formats they do not need. Keep the configuration diff and the approver's sign-off as evidence.

Limit Canvas publishing and component changes

Drupal Canvas lets editors assemble pages from components, so creating drafts, publishing pages and changing components should sit in separate roles. Decide which roles may do each action, then test every role on a staging copy of the site. Confirm that the review step you intend to use is enforced for Canvas pages in your Drupal CMS version. Keep the role-to-capability matrix and the test results.

Control AI tool access and outbound data

Optional AI tools send prompts and selected page content to a model provider, so the data path is a security decision. List which AI tools are enabled, which roles can use them, and which content fields they can read. Confirm where the provider processes data and whether it retains prompts, and record the answer from the provider's contract or documentation. Disable the tools for roles that handle restricted content.

Protect settings.php and the file system

The settings.php file holds database credentials and the hash salt, so the web server user should not be able to modify it after installation. Confirm that private files sit outside the web root, that uploaded files cannot run as code, and that trusted host patterns match your production domains. Scan the codebase after each deployment for unexpected writable files. Keep the file permission report and the deployment scan output.

Apply advisories to core and the distribution

Drupal CMS is a distribution built on Drupal core, so an advisory can affect core, the distribution or a contributed module. Subscribe to Security Team advisories and apply fixes in the third-Wednesday security release window, after testing on staging. Confirm that your Composer updates move core and distribution packages together and that the lock file records the result. Keep a log of each version deployed and the date it went live.

Keep AI and integration secrets out of config

Configuration export writes settings to files that teams usually commit to version control, so API keys for AI services or integrations must stay out of exported configuration. Store credentials in environment variables or a secrets manager, and reference them from settings.php or the service configuration. Check that configuration sync carries no credential values, and scan the repository for key patterns before each release. Keep the scan reports and the secret rotation record.

How to test a Drupal CMS site before editors use it

Test the build before any editor touches it. The goal is to confirm two things: that the site matches the agreed design, and that when something goes wrong it fails in a contained, visible way instead of exposing content or permissions to the wrong people. Start by comparing the configuration export against the design document. After Drupal CMS recipes have been applied, export the active configuration and review the content types, fields, roles, permission assignments, text formats, and Canvas-related settings against the agreed list. Differences are not automatically defects, since an editor may have changed something during review, but each one should be either accepted and written back into the design or reverted. Keep the export under version control so the comparison can be repeated after every change.

Next, test what editors can actually do. Create one test account for each role in the design and log in as each one. For Drupal Canvas, confirm that the role can create, edit, and publish only the page types and components it was granted, and that it cannot reach component configuration, global templates, or pages outside its section. Then test publishing with Content Moderation: draft to review to published, with the correct role able to approve and no one else able to bypass the step. Check that scheduled publishing and unpublishing behave as the design describes. Also check that AI tools are either disabled or restricted for roles that should not use them. Confirm this from the permissions page and by attempting the action as that role, because a visible menu item is not proof that the underlying permission is denied.

Check accessibility and responsive rendering of the templates themselves, not just sample articles. Review each layout at common phone and tablet widths, and check that navigation, forms, and Canvas-built sections reflow without clipped or overlapping content. Run an automated accessibility scanner against representative pages, then review the findings manually for keyboard focus order, heading structure, and form labels, since scanners miss many of these issues. Record which findings are fixed, which are accepted with a reason, and who accepted them. Ask the agency or internal team to confirm the accessibility standard the organization has adopted, because that choice determines which findings are blocking.

Define failure cases deliberately and test them. Three are worth running in a staging environment. First, a broken recipe: apply a recipe with a deliberate error, such as a missing dependency, and confirm that the failure stops the process and leaves the site in its prior state rather than half-configured. Second, a template that renders incorrectly on mobile: confirm the problem is caught by the review step, not discovered by editors after publication. Third, an editor with excess permissions: give a test editor one permission beyond the role and confirm that your review process or permission audit detects it. A safe failure means the site stays unpublished or in its previous state, the error is logged and visible to the admin team, and no public page exposes draft content or unapproved configuration.

Finish with a restore or rollback drill on a copy of the database and files, not on production. Take a backup, restore it to a separate environment, and confirm the site boots, the configuration imports cleanly, uploaded files resolve, and the test editor accounts still have the expected access. Time the procedure and write down each step, including who has access to the backup store and how long a restore takes in your own environment. Ask your hosting or implementation partner to confirm the backup schedule, retention, and the exact commands or steps for a restore, because these depend on your infrastructure and should be written into the runbook before launch.

Questions teams ask before building on Drupal CMS

Does Drupal CMS have a license fee to pay?

No license fee applies to the software itself. Drupal and contributed files on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, according to the Drupal.org licensing page, and there is no paid edition of Drupal. Your costs sit elsewhere: build work (scoping, content modeling, theme, Canvas configuration, integrations), hosting in your cloud accounts or data centers, PHP and major version upgrades, contributed module maintenance, and security monitoring. Some costs are one-time, such as the build, while others recur, such as hosting and upgrades. Ask any vendor to separate one-time build from recurring operations in the written quote.

Can marketers build pages in Drupal Canvas without developers?

For common page work, often yes, but the boundary is set by your permissions and templates. Editors can assemble pages from components and templates that developers or site builders have configured, within the roles you define. Changes to page structure, new components, custom data sources and layouts that must follow strict brand rules generally still need a developer. Confirm current Canvas capability against the Drupal CMS documentation for the version you plan to deploy, since the feature set changes between releases. Then test with your own editors on a staging copy before you plan headcount around it.

How long does a Drupal CMS site build take?

Timing depends on scope, and a written scope is the only reliable basis for a schedule. The main drivers are the number of page types and templates, the volume of content to migrate, the number and complexity of integrations (CRM, identity, analytics, search, payments), theme design and accessibility review, approval steps, and how quickly your team makes decisions. Drupal CMS recipes and site templates can shorten configuration work, but custom components and integrations still take time. Ask for phases, dependencies, assumptions and the client responsibilities in writing, with a timeline tied to each phase rather than one overall date.

What does our organization need to provide for a Drupal build?

The build needs named people and access more than documents. Content owners approve the content model and sign off on templates. An identity contact supplies details for single sign-on and role mapping if you use SAML or OpenID Connect. Integration owners provide credentials and documentation for each system the site calls. For hosting, you provide cloud or data center accounts, DNS, certificates, database and file storage, and staging and production environments. You also need a decision-maker who can resolve scope questions within agreed time. Before work starts, confirm which of these people and systems are committed and for how long.

Can our internal team build on Drupal CMS without a partner?

A team with the right skills can build a contained site, but most teams need outside help for some part of the work. The skills include Drupal site building (content types, Views, Canvas), PHP for custom modules, Composer, Drush, configuration management, theming, security review and hosting operations. Internal teams usually manage well when the site is contained, they have prior Drupal experience and they can own upgrades for the life of the site. A partner adds value for regulated controls, complex integrations, migrations from Drupal 6 or 7, performance under load, or a compressed timeline. Test your team's readiness by reviewing a small sample build against the scope you intend to deliver.

How do Drupal CMS upgrades relate to Drupal 10 end of life?

Plan the move now, because Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. The same schedule places Drupal 12 for the week of December 7, 2026. Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. Drupal CMS is a distribution built on core, so confirm which core version your Drupal CMS release tracks and whether its recipes and contributed modules support your target version. For a Drupal 10 site, check deprecated API usage, contributed module readiness and PHP version on a staging copy before you schedule the production upgrade.

Can a Drupal 7 site move to Drupal CMS in place?

No, a Drupal 6 or Drupal 7 site cannot be updated in place to Drupal 10 or later. Drupal.org documentation describes migrating the content and configuration into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt because they cannot be migrated. Drupal 7 security support ended on January 5, 2025, according to Drupal.org. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet, so extended support can serve as a stopgap. Start with a content and configuration audit to identify contributed modules that lack a migration path.

How DeployOpen scopes, builds and hands over Drupal CMS work

DeployOpen plans and builds Drupal CMS and Drupal Canvas sites inside the client's own infrastructure, with the work agreed in writing before it starts. The method below shows what gets scoped, built, tested, documented and handed over, and where ongoing support fits.

How we scope

Review which recipes, site templates and optional AI tools the content team needs, and confirm each one against the current Drupal CMS release.
Agree the content types, editorial roles and Canvas page layouts that marketers will manage directly.
Record which features need custom development, such as bespoke integrations or non-standard identity flows, as separate written line items.
Confirm the hosting target, PHP version and database engine, since Drupal CMS must run on a version the Drupal.org requirements pages list as supported.
Engagements are fixed-scope, so the written scope states deliverables, acceptance criteria and timelines before work begins.

How we build

Install Drupal CMS from a Composer-managed project so the distribution, recipes and contributed modules are version-pinned and reproducible.
Apply site templates and recipes first, then configure Canvas pages against the agreed content model rather than building pages by hand.
Build custom modules and theme changes only where the scope requires them, and keep them separate from the distribution code.
Test editorial workflows, permissions, forms and integrations in a staging environment that matches production.
Store configuration in version control and use Configuration Management export and import to move changes between environments.

How we hand over

Deliver the codebase, configuration export, environment setup and deployment steps as documented in the agreed scope.
Provide editor guidance covering Canvas page building, content types, media handling and any optional AI tools that were enabled.
Document every custom module, recipe modification and contributed module choice, including the reason each one was selected.
Walk through the test results and open items with the client's content and technical owners before cutover.
Transfer administrator access and credentials to the client's own team, so the client controls its production environment.

How we support

Offer ongoing support as a retainer covering Drupal CMS updates, contributed module checks and security release handling.
Plan updates around the monthly bugfix release window and the Wednesday security release windows published on Drupal.org.
Track major version changes, including Drupal 12 timing and PHP requirements, so the client can budget for upgrades in advance.
Confirm with the client which support level, response expectations and reporting cadence apply before the retainer starts.

Drupal CMS and Drupal Canvas site building