Snapshots have been a beloved feature of DDEV for years, but in v1.25.4 there is so much more.
Read on (or watch, or both) to see:
A DDEV snapshot is a physical, "hot" backup of your database — mariadb-backup/xtrabackup for MariaDB and MySQL, or pg_basebackup for Postgres — not a text-based mysqldump. Because it copies the database's on-disk files instead of dumping SQL statements, it's much faster to create and restore, especially on large databases. All the basics about snapshots are in the docs.
Normally snapshots live in .ddev/db_snapshots/, and the filename encodes the database type and version, for example mariadb_11.8. That's why a snapshot only restores against a matching engine and version — restoring a mariadb_11.8 snapshot into a mariadb_10.11 project will fail.
Snapshots are compressed with zstd by default. --uncompressed skips the decompression step on restore, trading a much larger file on disk for a faster restore. Postgres doesn't support uncompressed snapshots.
Core CommandsIf your project has multiple Git worktrees, snapshots taken from other worktrees of the same repository are available too — by name, with --latest, or through the interactive list.
Snapshots as Migration CheckpointsTake a snapshot before each step of a migration or update: ddev snapshot --name=pre-migration-step3. If a step breaks something, restore the last good snapshot instead of restarting the migration from scratch. (ddev snapshot restore --latest can be a great technique if you do this religiously.)
ddev snapshot --list becomes a log of checkpoints, and ddev snapshot restore <name> or restore --latest jumps back to any of them instantly.
This builds on the workflow described in DDEV Database Management: snapshot, ddev restart --reset-database, restore. It's also a natural lead-in to seeding a new database volume directly from a snapshot, covered next.
The seed SnapshotDDEV projects have always automatically created a database named db to help you get started fast. But it's been an empty database, with no content. Now, in DDEV v1.25.4+, the seed snapshot has been added. You can create a snapshot named seed (with whatever content you want) and when somebody starts up a project for the first time, the content on the seed snapshot will automatically be loaded. You can even check the snapshot named seed into your Git repository if you don't object to its size, and it can help folks new to the project to get started that much faster. (The seed snapshot is only used when there is no database; your changes to the database are kept as always.)
To add the seed snapshot to Git:
git add -f .ddev/db_snapshots/seed-* git commit -m "Add default seed db for clean startup" Seeding New Projects with --seed-snapshotIf you want to start a project with an alternate seed snapshot, ddev start and ddev restart accept --seed-snapshot=<name-or-path>, which seeds the database volume from a snapshot instead of the stock seed database. This only applies when there's no existing database — DDEV errors otherwise, telling you to add --reset-database or use ddev snapshot restore.
<name-or-path> can be a short name from .ddev/db_snapshots/ or a full path:
ddev start --seed-snapshot=$HOME/tmp/mysnapshot-mariadb_11.8.zstThis works for every database type DDEV supports, unlike the baked-dbimage technique below, which is MariaDB/MySQL-only — it's restored the same way ddev snapshot restore does, just at volume-creation time.
Combine --seed-snapshot with --reset-database to reseed an existing project in one step:
ddev restart --reset-database --seed-snapshot=<name> -Oy-O (--omit-snapshot) skips the automatic snapshot save of the database being thrown away, and -y skips the confirmation prompt.
This is the lightweight alternative to baking a seeded database image: no custom image or registry, just a snapshot file — good for local or small-team use where a shared registry is overkill.
Seed Snapshots + --reset-databaseOnce you have a seed snapshot, ddev restart --reset-database -Oy repeatedly returns the project to that known-good state — handy between test runs.
Building a Seeded Database ImageYou can also create a replacement database image that has an alternate seed database built into it. This is especially great for delivering huge databases, as the process can be handled by the image, or an upstream process. All the image building does is copy a base_db.zst or base_db.mbstream into the /mysqlbase/custom directory of the DB image.
For teams that want to share a ready-to-go database via a Docker image registry instead of a snapshot file, build-and-push-seeded-image.sh is an example that builds a real multi-arch (linux/AMD64, linux/ARM64) image with a snapshot baked in:
build-and-push-seeded-image.sh --snapshot=uncompressed-2g \ --output-image=randyfay/uncompressed-2g:v1.25.4 --push \ --base-image=ddev/ddev-dbserver-mariadb-11.8:v1.25.4This technique relies on mariadb-backup/xtrabackup, so it doesn't support Postgres.
Uncompressed seeds make for a much larger image and a slower push, but a faster, decompress-free container startup. It's worth comparing the actual image sizes to see the bandwidth cost of each trade-off.
Using a Seeded Image via dbimage:Point a project at the seeded image using dbimage in .ddev/config.yaml (or .ddev/config.local.yaml):
# .ddev/config.yaml or .ddev/config.db.yaml or .ddev/config.local.yaml # Example dbimage dbimage: randyfay/uncompressed-2g:v1.25.4Then:
ddev restart --reset-database --omit-snapshot -y Examples and resourcesThis article was edited and refined with assistance from Claude Code.
Reposted from Acquia with permission from Acquia. Authored by Martin Anderson-Clutz (mandclu)
Drupal Canvas AI shifts content platforms from reading to writing, using governed context layers to help enterprise AI agents automate safely.What changes when an agent stops reading your content and starts writing it?
For the last two years, the conversation about AI and content has mostly been about reading. Retrieval, summarization, a chatbot that answers a question from your knowledge base. That problem is largely solved, and it is solved almost everywhere. Any serious platform can find a relevant paragraph and hand it back.
The shift that actually changes the job of a content platform is quieter. Agents have moved from "answer my question" to "do the work." They are no longer only reading your content. They are starting to write it, assembling pages and populating components and publishing the result. The category we have called content management for twenty years was built for the first job. It was never asked to do the second.
Where the Real Cost LandsAt this point a fair objection turns up: is this not exactly why we keep a human in the loop? It is. Any content platform worth running in an enterprise keeps a person between the agent and the published page. A system that lets an agent push unreviewed work straight to production is not showing you the risk of agentic content. It is showing you that it was never built for the enterprise to begin with.
So the risk worth talking about is not the rogue page. Review catches that. The risk is waste.
A read and a write still fail in opposite directions, and the cost is what separates them. When a retrieval system returns a weak answer, one person spends a moment sorting it out and moves on. When an agent produces a weak write, a layout that misses the brand or a component wired to the wrong relationship or a draft that ignored a business rule, someone has to notice it, correct it, and often send it back to be generated again. Every one of those steps costs the reviewer's time and burns the tokens that produced the work in the first place.
That cost lands on the exact person the agent was supposed to help. The promise of agentic content is leverage, so the specialist spends their time on judgment instead of assembly. A guessing agent quietly reverses the trade. Rather than assembling the page themselves, the reviewer now inspects a draft they did not write. They hunt for the places it went wrong and explain what to change. That is not leverage. It is rework wearing the costume of automation, and it scales the wrong way, because an agent that guesses does not guess once. It guesses across every draft, at machine volume.
This is why context is the whole game. A human in the loop is cheap when the work in front of them is already right, and expensive when it is not. Give the agent structured, governed context and the review step becomes a quick yes. Hand it flat fields and hope, and the review step becomes the job you were trying to automate, now done twice.
Every Generation Answered to a Different ConsumerIt helps to look at what actually changed, because the content platform has served three different consumers over its life.
Content Management System Headless and Composable Agentic Content Platform Primary consumer A person in a browser A front end serving a person Software that acts Content flows Outward, to one presentation Outward, to many presentations In both directions How editorial judgment is applied By hand, page by page By hand, page by page Encoded as context up front, confirmed at review Measure of success Editorial autonomy Reuse across channels Safe, accountable machine actionFor most of that history, judgment stayed with the editor. The system stored content and rendered it, while a person decided what was true, what was on-brand, and what was ready to publish. Headless moved content to more places, but it did not move that responsibility. A human still stood between the content and the world.
Agentic content management changes that. The agent now does the assembly the editor used to do, which means the judgment the editor brought to the work has to come from somewhere. A platform that carries it, with the business rules and the content relationships and the standards for what good looks like, hands the reviewer a draft that already reflects those things. A platform that cannot leaves every one of those calls for the person to supply by hand, one draft at a time. The judgment does not disappear. It moves back onto the reviewer the agent was supposed to free.
The Distinction the Category Is MissingHere is the line most tooling blurs, and the reason so many agentic demos fall apart the moment they meet a real enterprise. Content is not context.
Content is what you publish: the page, the article, the product description, the campaign.
Context is everything an agent draws on to produce that content safely. Your brand voice. Your content model. Your business rules, your reference material, and the relationships that connect all of it. Context is what turns a vague prompt into a result the organization would actually stand behind.
Most systems collapse the two. They hand an agent a set of flat fields and hope it infers the rest: the tone, the relationships, the governance that always lived in the editor's head. Guessing works beautifully in a demo and breaks in production, because the fields never carried the context to begin with. The agent was handed the output and asked to reconstruct the reasoning behind it.
Treating context as a governed layer of its own, with clear owners, review, version history, and scope, is what separates an agent that produces a plausible draft from one an enterprise can trust to publish. The prompt gets simpler. The result gets more accountable. The organization decides in advance what the agent is allowed to know and do.
What Structure Actually Buys YouHere the shape of the underlying system stops being an implementation detail and becomes the whole question.
An agent that writes needs things the read era never demanded. It needs to see the page as a structure it can reason about, with components, order, and resolved values, rather than a wall of markup it has to pattern-match. It needs to work inside the governance that already exists, the roles and permissions and workflows the organization spent years getting right, instead of routing around them. And it needs its output to land in a reviewable state, with a record of who initiated the work and what produced it, so a person can still say yes or no before anyone sees it. Structured context is what makes that review a quick confirmation rather than a second round of work.
None of that can be added after the fact. A platform that stores content as flat, disconnected fields cannot suddenly expose relationships it never modeled. A platform with shallow governance cannot suddenly supervise an agent it was never designed to hold. These are properties of the foundation. Either the structured content and the mature governance are already there, or you are trying to pour a footing under a building that already stands.
For years, careful content modeling and granular governance were treated as overhead, the slow and unglamorous work that held teams back. The agentic era inverts that. The same rigor is now what lets a team move quickly and safely at once, because it is exactly what an agent needs in order to act without guessing.
Where This Gets Real: Drupal CanvasPlenty of tools can turn a prompt into a layout now. That trick is becoming table stakes, and it is the wrong thing to be dazzled by. The real question is whether the layout that comes back is on-brand, relevant, usable on the devices your audience actually reaches for, and built on terms you control. The answer depends on the foundation under the prompt, and that is what Drupal Canvas is designed around.
Four differences show up the moment you move past the demo.
The first is how layouts get built. Canvas assembles them from Twig-based single-directory components, React-based code components, and Drupal blocks, so you work with the component technologies your team already knows rather than adopting one proprietary format wholesale.
The second is where the context comes from. Because Canvas can ground its work in the Context Control Center, the agent is not inventing your brand from a prompt. It is working from the voice, content model, business rules, and relationships your organization has already curated and approved. That is the difference between a layout that is merely plausible and one that is on-brand and relevant.
The third is the model underneath. Through a provider-agnostic AI layer, Canvas is not wired to a single vendor's model. You use the one that suits the task in front of you, and you change your mind later as the field moves, without re-platforming to chase whatever shipped this quarter.
The fourth is where the output can go. Coupled or decoupled, you manage the content once and render it across the front ends and devices your audience uses, so a traditional site and a headless build stay open to you from the same system.
Any one of these helps on its own. Together they are the distance between generating a layout and producing one you can put into production: on-brand because it is grounded in your context, usable anywhere because the output is ambidextrous, and built with whatever model best fits the work.
The Engine Behind It: The Drupal AI InitiativeNone of this is a single product feature or a one-vendor bet. It comes out of the Drupal AI Initiative, the funded and coordinated effort in the Drupal community to make the platform both a great place to build with AI and a safe place for agents to act. That initiative is the engine behind the capabilities that put Drupal in front on the things that matter here: structured content an agent can reason about, governance it has to respect, a provider-agnostic model layer, and the freedom to publish coupled or decoupled.
The work runs on two fronts. One brings common AI features directly into Drupal so they operate together instead of as disconnected add-ons. The other makes Drupal legible and callable to agents and tools working from outside, measured against an Agent Readiness scorecard that keeps the progress honest. Because it is happening in the open, on standards-based foundations, the improvements compound for everyone building on Drupal rather than accruing to one company.
The Context Control Center is a good marker of the pace. It turns the context an agent can draw on into a governed content entity, with ownership, workflow, revisions, translations, and scope, and its first stable release is expected in the days ahead. That moves the grounding layer from promising to production, which is the exact piece most platforms are still treating as a roadmap.
If you want to see where this is heading, DrupalCon Rotterdam has two AI Summits dedicated to it. I will be presenting at the AI Dev Summit, and my colleague Scott Falconer will present at the Enterprise AI Summit, one track for the people building with these tools and one for the people who have to answer for them in production.
Design It In, Do Not Patch It OnFaced with a fast-moving category, the tempting move is to wait for a winner and buy in later. The trouble is that the properties that matter here do not arrive as an upgrade. Structured content, relationship-aware data, a governed context layer, model choice, and the freedom to render coupled or decoupled are either in the foundation or they are not.
So the question for a content team is not which AI feature to switch on. It is harder and more useful than that. When an agent stops reading your content and starts writing it, does your platform still carry the judgment that used to live with your editors? Content answers to a person. Context is what lets software act in their place. The teams that see the difference, and that build on a foundation treating context, structure, and governance as first-class concerns, are the ones who will let agents do real work while keeping a hand on what ships.
File attachments: Image1.pngLaunching your site isn’t the end of the work. That’s the bad news.
Even after you settle back into your day-to-day, your website still needs you. There’s still so much you can and should do.
The good news: the work spreads out across the year, and the effort rises and falls. But measuring your data and making steady improvements is needed to keep your website effective long after launch.
About a week ago, I wrote about the simplytest.me rewrite and closed on what was next: site templates and recipes. You can now launch a sandbox for a site template. I'm excited that people can now easily try out all the site templates on Simplytest.me.
Compound field was released as an alpha release two days ago. It's getting a lot of people excited. Let's install it and see how it works.
markconroy 18th Sep 2026Today we are talking about Laravel, Marketing, and The PHP Foundation with guest Matt Stauffer. We'll also cover Formdazzle as our module of the week.
For show notes visit: https://www.talkingDrupal.com/570
TopicsMatt Stauffer - mattstauffer.com
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Amber Matz - tugboatqa.com [amber himes matz](https://www.drupal.org/u/amber himes matz)
MOTW CorrespondentBernardo Martinez - bernardm28
Prices, specifications and proof buried in body copy are hard to compare, filter or reuse across pages, feeds and AI answers.
Drupal content modeling stores those facts as fields, connects related records with entity references and leaves prose for explanation. Maciej Lukianski walks through buyer-question audits, product and service field tables, migration stages and coverage reports that turn one edit into every output.
AI crawlers already fetch product pages during live conversations, but citations stay rare. Drupal sites cited by AI need one fact in fields, then the same value on the page, in JSON-LD, in feeds and through JSON:API or MCP tools.
Maciej Lukianski walks through what fetchers need, which Drupal modules cover Markdown, llms.txt and MCP Server today, and where configuration still decides whether a bot can quote your catalogue.
At DrupalCon Vienna, Tim Lehnen presented on the main costs for running Drupal.org. Around 50% of the total cost of running drupal.org, or approximately $1.5m, is infrastructure costs. A significant slice of infrastructure costs comes from drupal.org's self-hosted GitLab, and in turn much of that cost is due to GitLab CI for Drupal core and contributed modules.
Figure 1: Drupal Engineering activities compared to the various funding sourcesDrupal core is the single biggest project in terms of CI minutes, both due to the sheer number of tests as well as the level of activity in Drupal core issues, with hundreds of commits per month and activity on thousands of issues and Merge Requests ("MRs").
Figure 2: Drupal CI minutes by project, July 2026, core issue forks are treated as separate projectsSince Drupal originally moved to Gitlab CI from our previous Jenkins-based CI infrastructure in 2023, we've been working on reducing the time taken for Drupal core test runs.
The primary end goal of this work was to reduce the wall time for pipelines on MRs. These started at around 55 minutes when we originally moved to Gitlab CI (approximately the same as they were on Drupal CI), and now generally finish in 5-7 minutes. The 55 minute runtimes already relied on previous known optimizations like using a ramdisk for both the database and filesystem, applied to GitLab runners. GitLab does not support this out of the box.
Five minute turnaround times on pipelines have made a huge difference to Drupal core velocity. Whereas core contributors used to push to a branch, then go and eat lunch or dinner while waiting for the pipeline to finish, there's now barely enough time to make a cup of coffee, let alone drink it.
Figure 3: Contibutors recognizing and commenting the time improvement of waiting for the pipeline to finishHowever, the bulk of the initial gains we made to core CI pipeline performance was in wall time, with much less impact on CPU minutes. This is now starting to change, as we're finding ways to reduce the CPU minutes while also keeping wall times as short as possible.
Reducing Pipeline Wall TimesWe reduced pipeline wall times via the following approaches.
Concurrent Test Running and Parallel CI JobsDrupal's run-tests.sh has supported running tests concurrently for a long time. We added support for Gitlab's parallel test runs, splitting test groups with thousands of tests into smaller groups so that they can be run on multiple test runners at once. For example Drupal's functional test group is executed in 8 parallel jobs, at 15 concurrency, with a CPU request of 10 per job. This runs 150 test classes at a time on 100 CPUs. By running smaller sized individual jobs, there is also a higher chance of them fitting into test runners that become available rather than requiring a new AWS instance to be spun up.
Slowest Tests Run FirstTests are always run slowest first. Drupal's test runner has supported a #slow group for a long time, so that very slow tests can be run first. We now also order tests by the number of methods, so that tests with more methods, which overall tend to be slower, run first too. This is critical for other optimizations to be effective. If a single class takes three minutes to run, starting it at the beginning when the rest of the tests can also be completed in three minutes means the entire test run can be finished in three minutes. But if that job started last, the job could take six minutes, with just that one test being run for half the time, leading to slower wall times and idle CPUs.
Optimize or Split Up the Very Slowest TestsIn some cases we have had individual test classes that took more than 10 minutes to run. For these very slow running tests, we've split them into smaller test classes so that they can be run in parallel, and/or optimized the test set-up requirements so that no individual test takes longer than a full run.
Reducing CPU Time for Test PipelinesWith these techniques, we've been able to balance CPU requests and concurrency across the various core test types, so that every job finishes within approximately 3-4 minutes. This has given us a solid framework for keeping pipeline wall times to a minimum while allowing us to adjust CPU requests and concurrency for individual test types to match the scope of core's overall test coverage. As far as we know there are no longer obvious optimizations to make via tweaking concurrency and test running order.
While we've been working on optimizing the tests themselves, in recent months focus is increasingly shifting in that direction as the best way to further optimize test runtimes, but more importantly, reduce CI minutes and the resulting infrastructure cost for the Drupal Association overall.
Test TypesDrupal core started with only one type of test: SimpleTest 'functional tests' that require a full Drupal install into a separate site that the tests are then run against. Over time with the adoption of PHPUnit, we've added unit tests, 'kernel tests' which include a full dependency injection container but don't do a full install, functional JavaScript tests which use a real browser, and build tests which allow creation of a completely separate code base in its own directory. There is an ongoing effort to convert functional tests to kernel and unit tests where this can be done without losing test coverage, with the recent addition of http request testing to kernel tests making many more tests eligible. Converting a functional test to a kernel test can reduce the time it takes by 3/4, so for the tests where this is possible it's one of the most effective ways to make gains, although the conversions have to happen test by test across dozens or hundreds of test classes.
Over the past couple of years there has been a concerted effort to improve Drupal core performance. Many runtime performance improvements don't necessarily make a lot of difference to test runtimes as a whole. But because functional and functional JavaScript tests install a full Drupal site and request real pages, anything which improves installer or cold cache performance tends to have an outsized effect on test runs. Installer performance generally doesn't affect production sites (because they're already installed!) and cold cache performance is often not a priority for production sites because it tends to affect a low percentage of overall requests, however as well as CI times, it can also make huge differences to the user experience for new users as well as improving responsiveness after deployments and cache clears.
Installer Improvements for Functional TestsIn 11.2.0, we changed module install to support installing multiple modules at once without a separate dependency injection container rebuild between each module. Instead of doing 50 or 60 container rebuilds during an install, we do more like 11 or 12. This took tens of seconds off Drupal installs, whether via the UI, Drush, or during test runs.
Figure 4: Installing multiple modules in Drupal 11.2Source: Figure 4: Installing multiple modules in Drupal 11.2.
In Drupal 11.4, we made container rebuilds during the installer more conditional, reducing container rebuilds during a functional test from 11 to 8.
Recently, I've been looking at whether it would be possible to reduce the 8 remaining container rebuilds further, without necessarily an expectation that there would be much room for improvement, and found some. With all of those changes, some of which are not committed yet, we should be able to get down to an absolute minimum of 2 container rebuilds in tests. While some of the optimizations are test-specific, a real-life Drupal install of the minimal profile takes less than 2 seconds.
This investigation also uncovered further possible performance improvements in the installer.
While the combination of these changes probably saves only around 5 seconds at most from an install during a test run, this saving is multiplied by every install that occurs, with thousands of Drupal installs on every test run, this adds up to several minutes of CI time.
This has already allowed us to reduce the total CPU request for functional tests from 128 to 80 with no increase in wall time. We expect to be able to reduce the CPU request for both functional and functional JavaScript tests further once more optimizations land.
Kernel Test Performance ImprovementsKernel tests in general run much faster than functional tests, however there is still a per-method overhead which is a lot higher than unit tests. We are looking at adding an option to kernel tests to share the database state between test methods which will remove a lot of that overhead. This in turn will allow us to re-use the dependency injection container between methods. As we move functional tests to kernel tests, this should increase the impact of that change on resource usage even more.
Re-Evaluating On-Commit PipelinesDrupal core has daily, weekly, and on-commit jobs on its branches, as well as those that run on individual MRs. In looking at the information we get from those jobs, we realised that the on-commit jobs, which on average run several times per day, and run the full test suite against multiple different database types (Mysql, MariaDB, SQlite, PostgreSQL) don't necessarily give us information that we can't otherwise get from MR, daily and weekly runs. For release branches, we need immediate post-commit feedback in case something is unexpectedly broken, which sometimes happens when two independent commits are fine individually, don't have merge conflicts, but break when combined anyway. However, we're in the process of trialling running our development branches without on-commit pipelines whatsoever. This should reduce CI minutes for core purely via running pipelines less often, on top of the in-pipeline optimizations above.
Reducing Wall Time for Contrib CI RunsWhile individual contrib projects are not the biggest user of CI minutes, there are thousands of contributed projects. Several of the performance optimizations for the installer, functional tests, and kernel tests will apply to contributed module tests too, since those have to install core the same way as core tests do.
Additionally, there has been recent work to switch contrib's gitlab_templates shared pipeline definitions to running concurrent tests by default. Contrib tests previously used raw phpunit which runs each test sequentially with an option to switch to concurrent test running via run-tests.sh; the default flipped to run-tests.sh by default in September 2026. Because contrib tests should also benefit from core's 'slowest test first' strategy, this should compress pipeline times in contrib and it may have a positive impact in reducing CI minutes overall if runners are able to complete jobs in a shorter time with the same CPU request.
Effect on the Drupal Association's Hosting CostsTaken together, these changes lower the cost of running core's CI run by run, through shorter wall times, fewer CPU minutes, and fewer pipelines overall. As Figure 2 shows, core is the single biggest consumer of CI minutes on drupal.org, so that work is aimed at the largest single driver of the GitLab CI costs behind the Drupal Association's infrastructure bill.
What that adds up to on the bill itself is a separate measurement, and will take longer to validate. Total cost depends not only on the cost per run but on how many runs happen, and core activity (commits, issues, and merge requests) is holding steady or rising. So the effect on the DA's hosting costs has to be read from same-month comparisons year over year, or averages across several months, rather than any single snapshot. We’ll be keeping a close eye on this as the latest round of changes are committed.
Newsletters are meant to keep audiences connected in a consistent way, building familiarity and trust. They carry updates, stories, and ideas straight into inboxes. It’s a format that rewards consistency over noise, and clarity over clever tricks. A good newsletter feels less like marketing and more like a friendly letter that arrives just when you need it.
Written by Duncan Worrell (dunx)
DrupalCon Rotterdam is almost here. Alongside two dedicated AI summits and the main conference keynote, the program is stacked with high-value AI content for developers, strategists, and leaders alike. Whether you're looking to push agentic workflows, scale digital governance, streamline content operations, or keep your AI integrations trustworthy, here is a complete breakdown of the top AI sessions to help you optimize your schedule.
Full schedule at https://events.drupal.org/rotterdam2026/schedule
Tickets at https://events.drupal.org/rotterdam2026/registration-information
All session times are local CEST.
SummitsIn addition to the main DrupalCon event, there are two AI-specific summits being held catering for two very different audiences.
Enterprise Drupal AI SummitAn executive-focused event for CXOs, Heads of Digital, and enterprise leaders connecting with curated Drupal AI partners. Hosted on the historic former ocean liner, SS Rotterdam.
Date & Time: All day Monday, 28 September
Event details here: https://summit.enterprisedrupal.eu/schedule.html
Getting Drupal developers up to speed on AI coding tools, AI in PHP/Symfony/Drupal frameworks, Canvas, and Drupal CMS innovations.
Date & Time: All day Monday, 28 September
Event details here: https://events.drupal.org/rotterdam2026/ai-dev-summit
For many, the DriesNote by Drupal founder Dries Buytaert is the week’s highlight. Expect a keynote packed with the latest AI roadmap updates, architectural reveals, and live technical demos.
Date & Time: Tuesday, September 29, 2026 - 10:30 to 11:45
DriesNote will live stream on YouTube if you can’t make the event in person.
SessionsEvery session is likely to mention “AI” but we expect these sessions to be focused on AI.
Unblocking AI: Why Programmes Stall at Pilot Stage, and How to Move Past ItResearch and strategies for moving AI initiatives past the pilot phase to deliver real-world impact.
Date & Time: Tuesday, 29 September 2026, 13:00 – 13:10
Speakers: Amanda Falshaw (AI Enablement Lead at Reading Room) & Megan Harvey (Reading Room)
Features AI-assisted content creation as part of an open-source Drupal intranet workspace.
Date & Time: Tuesday, 29 September 2026, 13:15 – 13:25
Speaker: Maciej Łukiański (CEO and Co-founder of Droptica)
Leadership and organizational change management required to guide teams through fast-moving AI adoption.
Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15Reviewer-Friendly AI: A Practical Drupal Contribution Workshop
Practical AI-assisted workflows designed to turn ideas into high-quality, review-ready open-source contributions.
Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)
Engineering reliable, trustworthy AI agent integrations in Drupal using modules like AI, ECA, and agentic tools.
Date & Time: Tuesday, 29 September 2026, 13:30 – 14:15
Speaker: Shibin Devadas Kakanat (Backend Pro Lead at Factorial)
Structuring, scoping, and natively managing AI context within Drupal CMS for downstream agents and tools.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speakers: Emma Horrell (User Experience Manager University of Edinburgh and UX Research Lead for Drupal CMS) & James Abrahams (Technical Director at Freelygive)
Applying UX research methods to train and ground AI content tools to output domain-specific quality.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speaker: Aidan Foster (Senior UX Strategist at Kanopi Studios)
Addressing data security, compliance, provider selection, and cost control as AI adoption scales.
Date & Time: Tuesday, 29 September 2026, 14:25 – 15:10
Speaker: Michael Schmid (Head of Technology and Co-Founder of amazee.io)
Testing AI coding agents on live projects to automate complex site migrations into Drupal Canvas, examining real metrics, wins, and limitations.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speakers: Wolfgang Ziegler (Architect, Founder of drunomics) & Jeremy Chinquist (Project Manager at drunomics)
Automating inclusive governance and identifying accessibility errors early by bridging code, humans, and AI workflows.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speaker: Mike Gifford (Senior Accessibility Strategist at CivicActions)
Adapting content architecture for direct answer delivery to AI systems while increasing Drupal’s strategic value.
Date & Time: Wednesday, 30 September 2026, 10:45 – 11:30
Speakers: Tomi Mikola & Ulla Koho (both digital strategists and content architects at Wunder)
Maintaining human readability, software architecture, and clean code standards when using AI generators.
Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25
Speaker: Len Swaneveld (Senior Drupal Developer at iO)
Unifying 35 national voices into a cohesive travel brand using generative AI integrated into Drupal.
Date & Time: Wednesday, 30 September 2026, 11:40 – 12:25
Speakers: Krisztián Kása & Zsófia Alföldi (both Project Managers at Brainsum)
Leveraging Drupal’s structured architecture to build optimized environments for AI Agents running inside and outside CMS boundaries.
Date & Time: Wednesday, 30 September 2026, 12:30 – 12:40
Speaker: James Abrahams (Technical Director at Freelygive)
How autonomous AI agents act as primary decision-makers selecting, building, and verifying Drupal systems.
Date & Time: Wednesday, 30 September 2026, 12:45 – 13:30
Speaker: Scott Falconer (Senior Principal Software Engineer at Acquia)
Official product update from the Drupal AI Initiative leadership on building production-ready Agentic CMS capabilities.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25
Speakers: Niels Aers (CTO/AI Tech Lead at Dropsolid) & Dr. Christoph Breidert (CEO and Founder of 1xINTERNET)
Generating governed, high-quality draft campaign pages straight from PDF briefs in minutes without code tickets.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:00
Speaker: Kieran Cott (Executive Creative Technology Director at Delete Agency)
Open discussion on improving how LLMs describe, evaluate, and recommend Drupal to users.
Date & Time: Wednesday, 30 September 2026, 13:40 – 14:25
Speaker: Larissa Tropp (Digital Marketing & Growth Specialist at 1xINTERNET)
Leveraging AI tools to simplify, re-architect, and map legacy un-typed data into clean destination bundles during migrations.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Roberto Peruzzo (Principal Architect and Founder of Sparklingboys)
Honest post-mortems on AI project failures and pragmatic ways to navigate rapid technological shifts.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speakers: Dieter Blomme (Drupal Architect at Dropsolid) & Valery Lourie (Lead Software Engineer at EPAM Systems)
Running lightweight, client-side search powered by Pagefind with an AI layer for query expansion and summaries.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Jeremy Andrews (CEO and Founder of Tag1 Consulting)
Training AI agents to generate Single Directory Components, insert them into pages, and verify browser rendering.
Date & Time: Wednesday, 30 September 2026, 14:45 – 15:30
Speaker: Matt Glaman (Principal Software Engineer at Acquia)
Agentic translation and governance workflows developed for the European Commission across 24 languages.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speakers: David Galeano & Adam Nagy (both work in the DIGIT department at the European Commission)
Enabling non-technical users to build, style, and structure complete Drupal sites via conversational prompts.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speakers: Francesco Pesenti & Francesco Quagliati (both are Developer Advocates and Solution Engineers at Platform.sh)
From Drupal Content to AI Answers: Learnings from EPSY
Designing constrained AI search engines over standard chatbots to deliver structured content answers.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speaker: Antonella Picarella (Head of Digital Communications & Content Strategy at BFF Banking Group)
Strategic shifts from Search Engine Optimization to Generative Engine Optimization as AI engines handle discovery.
Date & Time: Wednesday, 30 September 2026, 16:00 – 16:45
Speaker: Wouter De Bruycker (Digital Marketing Strategist at Dropsolid)
Translating and moderating hundreds of high-volume personal stories across 60+ languages using AI tools.
Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45
Speakers: Charles Andrew Revkin & Diego Fernando Costa (both part of the digital communications team at the Union for International Cancer Control (UICC), which runs World Cancer Day)
Practical tactics for Answer Engine Optimization (AEO) and maintaining content discoverability in AI platforms.
Date & Time: Wednesday, 30 September 2026, 17:00 – 17:45
Speakers: Reena Tripathi (Digital Marketing Manager at OpenSense Labs) & Anubhav Gupta (CEO/Technical Architect at OpenSense Labs)
Whether you’re coming to DrupalCon Rotterdam to build with AI, figure out how to govern it, or understand where it is taking Drupal next, there is a lot to choose from. From the two Monday summits through the DriesNote and a packed slate of sessions, AI is clearly woven throughout this year’s programme. Check the full schedule, plan around the sessions that matter most to you, and we’ll see you in Rotterdam.
File attachments: DrupalCon_Rotterdam_2026___Drupal_Events.png
