This session untangles the confusion with one analogy: a restaurant. Your content is the pantry. Canvas Code Components are the recipe cards. Drupal Canvas is the ordering screen. And the two decisions that actually matter are who runs the restaurant (SaaS or PaaS) and who cooks the page (Drupal itself or a JavaScript app).
We will walk through the four ways Drupal content becomes a page (Twig themes, Canvas coupled, classic headless, and the emerging Canvas Headless) with honest trade-offs for editors, developers, and budgets. We will clarify what Drupal CMS 2.0 really changes, where each option can and cannot run, and the gotchas teams hit before promising "zero rework": version floors, theme readiness, hosting limitations, and the maturity of headless Canvas.
Attendees will leave with a practical decision framework they can use in their next architecture discussion, and an interactive guide to share with their teams and clients.
Learning outcomes
By the end of this session, attendees will be able to:
- Separate the two real decisions behind every Drupal frontend choice: the hosting model and the rendering model
- Compare the four rendering approaches and identify which one fits a given team, budget, and editorial need
- Explain what Drupal CMS 2.0 and Canvas change, and what they do not, for both new builds and existing sites
- Avoid common pitfalls, including Canvas version and theme requirements, SaaS hosting limits, and the experimental status of Canvas Headless
- Communicate these choices clearly to non-technical stakeholders using a shared vocabulary