webjoke.de

Drupal4Gov EU 2026: How Drupal Powers European Institutions and National Governments wolfgang.ziegler Thu, 5 Feb 2026 - 16:37

In the third part of his deep dive, Luca Lusso explores how Drupal developers can use service collectors and AutowireIterator to group, inject, and optimize services efficiently. This guide continues the practical exploration of Drupal's powerful service container

AI Automators transforms complex AI workflows from code to configuration. This case study reveals how BetterRegulation built production-grade AI workflows processing 200+ documents monthly with 95%+ accuracy – using multi-step chains, background queues, and admin-managed prompts. No custom integration code required.

Using Composer Path Repositories to Handle Module Dependencies During Development

Sometimes working on a Drupal contributed module requires making changes to the module’s composer.json so that you can update a dependency. This blog post looks at how to accomplish that in a local development environment.

joe Thu, 02/05/2026 - 00:09

Take Away

At Tag1, we believe in proving AI within our own work before recommending it to clients. This post is part of our AI Applied content series, where team members share real stories of how they're using Artificial Intelligence and the insights and lessons they learn along the way. Here, Charles Tanton (Software Engineer) explores how AI supported his improvements to the Optional Field Widget Ordering issue in Drupal core by accelerating progress on a long-stalled 10-year old problem.

Project Summary

This project focused on using AI to help resolve a long-standing Drupal core issue: Allow multiple field widgets to not use tabledrag (#2264739). The goal was simple but impactful: make it possible to disable drag-and-drop ordering for specific multi-value field widgets, instead of forcing all of them to be orderable. For years, the only practical option was a brittle patch that touched many core files and often broke on core updates, creating recurring maintenance work that nobody enjoyed. By pushing this core fix forward with AI as a coding partner, the aim is to remove that maintenance burden for good and give site builders more control over the form UX.

The Challenge

The core problem was that Drupal automatically renders multi-value fields in a table with tabledrag behavior, even when reordering is not needed. That table-based structure makes theming harder, complicates responsive layouts, and adds JavaScript overhead for no real benefit in many use cases. Our only workaround was a large, fragile patch from this very issue that had to be kept in sync across Drupal core releases by hand.

This AI Applied project set out to change that by getting a clean, configurable solution into core. The work included writing an improved merge request, updating the issue summary, and adding thorough test coverage, all geared toward making the change easy to understand, review, and eventually commit.

The Technical Overview

The first step was using AI to explore alternatives to the existing proposed fix and to see if there was a better architectural direction. After looking at the options together with AI, we confirmed that the original "orderable" setting approach was still the best fit, and then focused on strengthening it, especially around configuration schema. A key enhancement was the introduction of a shared field.widget.settings.base config schema so widgets could inherit the new orderable boolean cleanly instead of each re-defining it.

Across the project, AI helped with:

• Drafting a clearer, more complete issue summary that explains the problem, motivation, and proposed resolution.
• Building out comprehensive test coverage for affected multi-value widgets so regressions are caught automatically.
• Updating Twig templates and styling for the new non-orderable rendering path, including a simplified field-multiple-value-without-order-form template.
• Getting unstuck on Git and GitLab workflows specific to Drupal core contributions, including issue forks and merge requests.

AI also sped up UI work by letting me paste screenshots into the coding environment so it could adjust CSS more accurately, instead of iterating blindly. Here’s an example:

Figure 1: Screenshot with instructions uploaded to Claude to speed up UI work

Figure 2: The new UI provided by Claude

Over time, I shifted from an earlier extension to a smoother Claude Code setup, supported by installing the ddev-claude-code integration so the assistant could run directly inside the DDEV container with GitLab CLI access.

AI Workflow

A few workflow patterns turned out to be especially helpful on this project:

Dedicated context folder
I added a .claude folder in the repo to hold plans, reference snippets, and docs like the Drupal config schema guide. This let me carry context between sessions and ask the AI to "open and update" specific plan files instead of re-explaining everything.

Plan-driven development
For larger theming or testing tasks, I asked the AI to first write a plan to a file (for example, @.claude/theming-plan-22-nov.md), then execute it step by step, pausing after each item for review. That structure made it much easier to course-correct early rather than cleaning up after a big batch of code.

Voice prompts for speed
Using dictation for prompts in the terminal helped reduce friction for small, repetitive questions or instructions. It was surprisingly effective for "talking through" next steps in a more natural way.

Deep reasoning prompts
Adding a keyword like "ultrathink" in key prompts encouraged the AI to reason more thoroughly before proposing code, which was particularly useful for tricky config and test design work.

On top of that, the ddev-claude-code installation was straightforward and lives right alongside normal Drupal tooling:

composer config extra.drupal-scaffold.allowed-packages --json --merge '["drupal/claude_code"]' composer require --dev drupal/claude_code ddev add-on get FreelyGive/ddev-claude-code ddev restart ddev claude Results and Lessons Learned

The issue is still open, but the state of the work is very different from when this effort began. The implementation now uses a clean configuration schema pattern, has broad widget coverage, and includes extensive tests and documentation in the issue summary. Remaining tasks are mostly about theming and documentation polish before the merge request is ready for final review and potential commit.

This was my first serious use of AI for coding, so it naturally took longer than it would now that I have more experience. The upside is that it gave me a strong foundation for using AI as a regular programming tool, and it has since become part of my daily workflow.

If I were starting this same issue again today, I would:

• Ask the AI to generate full test coverage first, across all relevant widgets, to surface edge cases earlier.
• Lean heavily on a "plan mode" flow, approving each step in advance before code is written.
• Independently run and verify tests instead of trusting automated "all tests passed" claims.
• Keep prompts short and focused, especially around test generation, to avoid bloated code that is slow to review.

Real-World Applications

Contributions to Drupal core like this one tend to benefit every Drupal site over time. In this case, having an "Orderable" toggle for multi-value widgets will simplify maintenance by removing the need for a large, fragile patch and will improve form UX options for site builders. It's the kind of change that quietly pays off for years through cleaner upgrades and more flexible theming.

More broadly, this project is a concrete example of how teams can use AI to move long-standing open-source issues forward. It is especially valuable where the work involves a mix of architecture decisions, broad test coverage, and tedious but important updates across multiple components.

Expert Oversight Is Non-Negotiable

One of the most important lessons from this project is that expert oversight is essential. I saw multiple cases where the AI made questionable choices or leaned on weak assumptions in the code, which I only caught because I was reading closely and testing manually. Without that attention, the "help" would have turned into extra rework later.

Used well, AI acts as a powerful accelerator: it drafts, refactors, and suggests, while you stay accountable for direction, quality, and correctness. This project helped me build that mindset and gave me the confidence to make AI a normal part of my engineering toolkit. It also reaffirmed how valuable it is to practice with AI on internal or infrastructure-oriented work like this before applying it in higher-risk contexts.

This post is part of Tag1’s AI Applied series, where we share how we're using AI inside our own work before bringing it to clients. Our goal is to be transparent about what works, what doesn’t, and what we are still figuring out, so that together, we can build a more practical, responsible path for AI adoption.

Bring practical, proven AI adoption strategies to your organization, let's start a conversation! We'd love to hear from you.

Image by FranFrank96 from Shutterstock

The Algorithmic Bias Against Drupal Community Values

I don't usually fail at making my life easier, but hey, it's a whole new world lately. To try my hand at LLM during my trial of AI-assisted coding, I wanted to see if I could customize an LLM for a specific task: assigning user credit on Drupal Core issues. Depending on the complexity, activity, and number of contributors involved it can take me anywhere between 30 seconds and 30 minutes to assign credit when I commit an issue to Drupal Core. Maybe I could automate some of it?

theodore February 4, 2026

Drupal Commerce lets you serve both retail customers and business buyers from a single installation. Same products. Shared checkout flow. Same user experience—just adapted to the relationship. Different users can see different prices, payment options, and catalogs.

You don’t need a separate platform. You don’t need a different domain. You don’t need another way to manage content. Drupal Commerce already has the tools to support both B2C and B2B on the same website, using the same codebase, delivering a unified experience to all of your customers.

Even better, you can build a B2B portal in Drupal without any code. The capabilities are already there in existing features and modules.

On February 26th, I’ll show you how to do it. We’ll walk through building a B2B purchasing portal using Commerce Kickstart as a base. Sign up now.

Read more

A new solution to Drupal's messy mailing approach

Drupal core's mail module has been a mess for a long time and has seemingly not kept up with the modernization of the rest of the stack. Using the hook system to send emails feels archaic; therefore, a while ago, we started developing a module that:

• Allows for defining emails in code via a clean and powerful (chaining) object-oriented interface
• Supports sending HTML emails without any fuss
• Optionally allows for defining (HTML) emails as Twig templates
• Allows for translating said emails by simply adding more Twig templates in different languages (multilingual capabilities)
• Integrates with Drupal's default framework for email manipulation, which handles the transporting and formatting of outgoing emails
• Can be used as the backend for bespoke UI-driven mailing solutions

We have been using and improving Mail Composer and would love for that work to be reused and further built upon.

Let's talk codeJust sending an inline email

... is as simple as:

/** @var \Drupal\mail_composer\Manager $manager */ $manager = \Drupal::service('mail_composer.manager'); $manager ->compose() ->setFrom('foobar@foo.bar') ->setTo('foo@bar.bar') ->setSubject('Test subject') ->setBody(['This is the body of the email.']) ->send();

Neat, isn't it?

A close look at Charles Andrew Revkin: how an international upbringing quietly shaped a digital leader at UICC and his impact on global cancer initiatives.

Drupal CSS is broken when Aggregation is turned on

Here's some tips for debugging broken CSS in Drupal.

markconroy 4th Feb 2026

Meet Meridian, the newest Dripyard theme. We’re really excited about this release, as many hours went into Meridian along with updates to our other themes.

Flexibility

My favorite “feature” of Dripyard themes is flexibility. We market each theme toward a specific vertical, but in practice they are highly versatile. You can easily change the look and feel of an entire site by adjusting color schemes, border radiuses, and imagery.

Pictures are worth a thousand words, so we built our site to showcase multiple demos.

Drupal CMS 2.0 launched January 28. We asked Pam Barone—CTO of Technocrat and Product Owner of Drupal CMS—to talk about what's new and what she's most excited for people to try.

What makes Drupal CMS 2.0 different from version 1.0?

Drupal CMS 1.0 was really a proof of concept, to show that we could create a version of Drupal that bundled all of the best practices that many sites were using, and that the community would come together to make it happen in a short amount of time. We did prove the concept, but the 1.0 release did not represent any major innovations, because we were mostly just packaging functionality and tools that we already had and were familiar with. That is not to downplay the accomplishment at all, because it was a huge leap forward for the project, and it provided the foundation for the next steps.

With 2.0, we are introducing two big new concepts: Drupal Canvas and site templates. These represent another huge leap for the project, each in different ways, as we continue with the strategy to empower marketers to create exceptional digital experiences without relying on developers.

What are you personally most excited about for people to try in 2.0?

Drupal Canvas! I am so excited about Canvas and can’t wait to get it into the hands of our end users. There were times during the development of 2.0 when I was working in the Canvas editor and I thought, ‘Wow, I’m actually having fun!’ I can’t say I remember thinking that with previous Drupal page building tools.

And it’s not just about end users; one of the goals of 2.0 is to introduce Canvas within the community and showcase its potential. It’s a paradigm shift, and this level of change is always challenging, but after trying it out and getting familiar with the concepts, I think it’ll be clear that it’s worth it.

Site templates are a big part of this release. Can you explain what they are and why they matter?

Site templates are near-feature-complete starting points for Drupal sites based on specific use cases. They provide a content model, some example content, a polished look and feel, as well as the functionality you would expect based on the use case. The first site template – Byte, which is included in Drupal CMS 2.0 – is for a SaaS-based product marketing site. It includes all of the baseline functionality from 1.0, plus Canvas-powered landing pages, a blog, a newsletter signup and contact form, and a new theme with a dark style. 

During the development of 1.0, we realized that we couldn’t build something that was both generic and useful. Either we would have to build something simple that would be widely applicable, or we would be making a lot of assumptions about the site’s content model and functionality, and providing things that many users wouldn't want.

We decided that in order to really make it easy to launch sites, we had to provide many different starting points, across many use cases. By identifying the use case and being opinionated about how to solve it, site templates can start you off with 95 percent of what you need to launch.

Of course, that assumes there is a site template for your use case – which means we’re going to need a lot of them. We’re currently working with a group of Drupal agencies who have signed up for a pilot to develop new site templates for the launch of the site template Marketplace.

Let's talk about Canvas—how will this change the way marketers can build with Drupal?

The most obvious thing is just that it provides marketers with a modern, intuitive visual page builder of the kind that any competitive platform needs to have. Up until now, adopting Drupal meant getting its many benefits but compromising on the user experience, because the page building tools were clunky. With Canvas, that compromise is gone. We can provide the experience that marketers have come to expect.

In some ways it feels like we are playing catch-up, especially since it’s still early (the first release was in December) and there are some big gaps. But it also feels like a new era for Drupal, and the enthusiasm and pace of adoption so far is really encouraging. So I think we don’t really even know yet what changes will come, because when the community is presented with a new way to build cool things, the possibilities are endless.

You've mentioned making integrations easier with recipes. What does that look like in practice?

One of the benefits of using Drupal is that it can be integrated with pretty much anything, and all of the common integrations have modules to make it easier. But they always require some configuration, and it can be tricky to figure out. With recipes, we can add default configuration, and we can prompt for the necessary details, so you don’t have to go hunting around for where to add them.

Drupal CMS 1.0 included two integrations that use the recipe prompt already, for Google Analytics and the AI Assistant. They’re pretty simple in that you are just adding an ID or an API key, but they still are a big improvement over the manual setup. 

For 2.0, with site templates, we have the opportunity to include additional integrations that are relevant to the use case and wanted to tackle something a bit more complicated. Byte ships with a newsletter signup that uses a webform out of the box, and has an optional “Recommended add-on” to integrate with Mailchimp. The Mailchimp module already did most of the heavy lifting, but we worked with the maintainers to develop a recipe that configures the module (and its submodules), and once you authenticate your site with Mailchimp, will automatically create signup blocks for each of your audiences. From there, you can add them to any page via the Canvas editor.

We think that easy integrations are going to be really critical to making site templates attractive as an offering, so we are planning to continue working on that. 

In your recent presentations, you've talked about "making easy things less hard" versus "making easy things easy." Where does 2.0 fall on that spectrum?

The initial site templates are very intentionally on the “making easy things less hard” side. Not only is it a totally new concept, but they are leveraging Canvas, which is also new. So we thought that the best chance for success would be to keep it simple and try to really nail the use cases. Once we’ve all built a few, and we’ve gotten feedback from real users, we can move into the more complex sites where Drupal thrives.

Drupal CMS 2.0 is available now.

Try it now: drupal.org/drupal-cms/trial 

Download: drupal.org/download

Learn more: drupal.org/drupal-cms

Twenty-five years in. Still building.

New: Video Tutorial & OverviewA new video has been released as part of the Display Builder series: Display Builder: Installation and OverviewWhat it covers:

Drupal Configuration Management & Config Split: Still a Winning Combination john Tue, 02/03/2026 - 10:19

Recently, I decided to revisit the topic of Drupal configuration management, with a special focus on the Config Split module. Configuration management, first introduced in Drupal 8, was a fantastic addition to the platform and has paved the way for major improvements in CI/CD workflows over the years.

Information gathering, content writing, proofreading, SEO optimization, tag preparation – all these tasks consume a significant portion of the editorial team’s time. What if you could reduce this research time by up to 90% through automated content creation? In this article, I present a practical Drupal setup that uses AI-powered modules to generate editorial content with minimal manual input. This includes automatic information retrieval based on the title, tag generation, content creation, and detailed data fetching – all directly in your CMS, without switching between different tools. Read on or watch the episode from the Nowoczesny Drupal series.

Drupal Canvas (Experience Builder) limits WYSIWYG editing within its own text formats. Use the Canvas Full HTML module to remove these limitations, giving content editors full control over their rich text content.

The Drupal Views AI agent allows site builders to create and update Views using natural language prompts, without ever opening the Views UI.

We're excited to announce DDEV v1.25.0, featuring a completely revised Windows installer, XHGui as the default profiler, and updated system defaults including a move to Debian Trixie.

This release represents contributions from the entire DDEV community, with your suggestions, bug reports, code contributions, and financial support making it possible.

What's New and Updated

Default versions updated:

These updates mostly affect new projects. Existing projects typically continue to work without changes.

• Debian Trixie replaces Debian Bookworm as the base image for ddev-webserver and ddev-ssh-agent
• XHGui is now the default profiler (replacing prepend mode). See XHGui Feature blog post
• PHP 8.4 becomes the default for new projects, and PHP 8.5.2 is now available with full extension support including Xdebug
• Node.js 24 becomes the default for projects that don't specify another version
• MariaDB 11.8 becomes the default for new projects

Major new features:

• Revised Windows installer now uses per-user installation for WSL2 or traditional Windows (no admin account required). Download from ddev.com/download
• Reworked ddev share command with a new cloudflared share provider for free sharing options. See new docs.
• New diagnostic commands:
  • ddev utility xdebug-diagnose helps troubleshoot Xdebug issues. See (draft) Xdebug Understanding and Troubleshooting
  • ddev utility mutagen-diagnose helps debug Mutagen issues. See (draft) Mutagen Functionality and Debugging
• Faster snapshots: ddev snapshot now uses zstd instead of gzip for significantly faster exports and restores, thanks @deviantintegral
• Experimental Podman and Docker Rootless support: See Podman and Docker Rootless in DDEV
• FrankenPHP as an official add-on: ddev-frankenphp with many improvements. See updated (draft) Using FrankenPHP with DDEV
• Traefik configuration standardization: Project configuration now uses a single file: .ddev/traefik/config/<projectname>.yaml (all other files are ignored)

What You Need to Do After Upgrading

After upgrading to v1.25.0, follow these steps:

1. Run ddev poweroff (DDEV will prompt you for this)
2. Update your projects: Run ddev config --auto on each project to update to current configuration
3. Update installed add-ons: Run ddev add-on list --installed to see your add-ons, then update them as needed
4. Free up disk space: Run ddev delete images to remove old Docker image versions
5. Check compatibility notes below

Compatibility Notes and Things to Check 1. Debian Trixie base image

If your project has custom Dockerfiles or uses webimage_extra_packages and ddev start shows any problems, you may have a little work to do, but most projects are unaffected.

What to do: Test your project after upgrading. See Debian Trixie release notes for known issues.

Note: DDEV already includes the tzdata-legacy package to handle removed timezones in Debian Trixie, so no action is needed for timezone-related changes.

2. Profiler changed to XHGui

If you use XHProf profiling, it now defaults to XHGui mode instead of prepend mode.

What to do: If you prefer the previous prepend mode, run:

ddev config global --xhprof-mode=prepend 3. Nginx modules now come from Debian repository

If you use custom nginx modules, the package names and module loading have changed. DDEV now uses nginx bundled with Debian Trixie instead of maintaining an extra dependency on the nginx.org repository.

What to do: Update your nginx module configuration.

Example: Adding NJS (JavaScript) support to nginx in DDEV v1.25.0+:

ddev config --webimage-extra-packages="libnginx-mod-http-js,libnginx-mod-stream,libnginx-mod-stream-js" --ddev-version-constraint='>=v1.25.0' cat <<'EOF' > .ddev/web-build/Dockerfile.nginx RUN sed -i '1i load_module modules/ngx_stream_module.so;\nload_module modules/ngx_http_js_module.so;\nload_module modules/ngx_stream_js_module.so;\n' /etc/nginx/nginx.conf EOF 4. Removed commands and features

If you use these commands, you'll need to switch:

• ddev nvm: Switch to nodejs_version or install the ddev-nvm add-on
• ddev service: Use ddev add-on to install/remove services
• NFS performance mode: Switch to Mutagen instead

5. Updated ddev config flags

If you use these flags in scripts, update them:

• --mutagen-enabled → --performance-mode=mutagen
• --upload-dir → --upload-dirs
• --http-port → --router-http-port
• --https-port → --router-https-port
• --mailhog-port → --mailpit-http-port
• --mailhog-https-port → --mailpit-https-port
• --projectname → --project-name
• --projecttype, --apptype → --project-type
• --sitename → --project-name
• --image-defaults → --web-image-default

6. Traefik configuration

If you have custom Traefik configuration, note that:

• Only .ddev/traefik/config/<projectname>.yaml is used (other files are ignored)
• Put global Traefik configuration in $HOME/.ddev/traefik/custom-global-config/
• Traefik v3 syntax is now required

What to do if you have extra Traefik files:

1. Merge all your custom configuration into .ddev/traefik/config/<projectname>.yaml and remove the #ddev-generated comment from it
2. Track issue #8047 for potential future improvements to this workflow

Note: ddev-router no longer stops automatically when the last project stops. Use ddev poweroff to stop it manually.

7. Windows installation

If you're on traditional Windows (not WSL2): The installer may prompt you to uninstall the previous system-wide installation before installing the new per-user version.

Other Improvements

This release includes many other improvements:

• New Wagtail, CodeIgniter, and Drupal 12 project types
• Improved Pantheon integration with new environment variables and option to pull from existing backups or fresh database dumps
• Much faster ddev add-on list and ddev add-on search
• Shell autocompletion for ddev add-on get <TAB>
• SELinux environment detection with automatic bind mount labels
• More portable database collations for MySQL/MariaDB exports
• SSH config support in $HOME/.ddev/homeadditions/.ssh/config.d
• DBeaver support for traditional Windows

See the full release notes for complete details.

From the entire team, thanks for using, promoting, contributing, and supporting DDEV!

If you have questions, reach out in any of the support channels.

Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.

This article was edited and refined with assistance from Claude Code.

TL;DR: DDEV supports Podman and Docker Rootless as of v1.25.0. Podman and Docker Rootless are a bit more trouble than the recommended normal traditional Docker providers and have some serious trade-offs. With Podman on macOS you can't use the normal default ports 80 and 443. On Linux Docker Rootless you can't bind-mount directories, so the entire project has to be mutagen-synced. But Podman Rootless on Linux is pretty solid.

Jump to setup instructions: Linux/WSL2 · macOS · Windows

Note: This support is experimental. Report issues on the DDEV issue tracker.

Table of Contents

• Understanding Docker and Podman
  • Open Source Alternatives to Docker Desktop
  • Why Choose Podman?
  • Why Choose Docker Rootless?
• Key aim: Linux and WSL2 users
  • Do You Need an Alternative to Docker?
  • Installing Podman
  • Installing Docker CLI
  • Configuring Podman Rootless
  • Podman Rootless Performance Optimization
  • Configuring Podman Rootful
  • Setting Up Docker Rootless
• macOS
  • Do You Need an Alternative to Docker?
  • Installing Podman
  • Installing Docker CLI
  • Configuring Podman
• Windows
  • Do You Need an Alternative to Docker?
  • Installing Podman
• Running Multiple Container Runtimes
• Switching Runtimes with DDEV
• Which Runtime Should You Choose?
  • Runtime Comparison
  • Recommendations
• The Journey to Podman Support
• Supporting DDEV Development
• Conclusion

Understanding Docker and Podman Open Source Alternatives to Docker Desktop

A common misconception is that Podman is the only open-source alternative to Docker Desktop. This is not true. There are several fully open-source alternatives available on every platform:

• Docker Engine - The original open-source Docker, free to use
• Rancher Desktop - Open source container management with choice of dockerd or containerd
• Lima - Linux virtual machines
• Colima - Container runtime with minimal setup (built on Lima)
• Podman Desktop - GUI for Podman with Docker compatibility

All of these work with DDEV. The main reason to choose Podman specifically is if your organization forbids Docker entirely or if you want rootless operation by default.

Why Choose Podman?

Podman is rootless by default, making it the simplest option for secure container environments. Traditional Docker requires root daemons, which can be a security concern in corporate environments with strict policies. (Note that DDEV is targeted at local development, where there are few risks of specialized attacks using this vector anyway.)

Podman's rootless approach runs the daemon without elevated privileges:

• No root daemon on the system, only a rootless daemon in userspace
• Container processes cannot access root-owned files
• Reduced attack surface if a container is compromised

While DDEV already runs containers as unprivileged users, Podman eliminates the need for a root daemon entirely.

Why Choose Docker Rootless?

Docker Rootless provides the same security benefits as Podman Rootless while maintaining full Docker compatibility. It runs the daemon without root privileges, offering:

• No root daemon on the system
• Container processes cannot access root-owned files
• Reduced attack surface if a container is compromised

Unlike Podman which is rootless by default, Docker Rootless requires special setup to enable. Choose this option if you want to stay with Docker but need rootless security.

Key aim: Linux and WSL2 users

The primary focus for this article is Linux and WSL2 (we have test coverage for Linux only for now). Most features and configurations are well-tested on these platforms.

Do You Need an Alternative to Docker?

Before diving into setup, consider whether you need an alternative to traditional Docker:

Runtime Why would you do this? Key trade-offs Performance Setup Recommendation Traditional Docker Standard, widely-used option None Excellent Simple Recommended for most users Docker Rootless Security requirement for rootless daemon Must use --no-bind-mounts (everything via Mutagen), can't use default workflow Moderate (Mutagen overhead) Moderate Only if rootless security is required Podman Rootful Organization forbids Docker Slower than Docker, different behavior Slower than Docker Moderate Only if Docker not allowed Podman Rootless Organization forbids Docker + want rootless security May need sysctl changes for ports <1024, slower than Docker Slower than Docker Moderate Only if Docker not allowed and rootless required

Bottom line: Stick with traditional Docker unless organizational policy or security requirements force you to use an alternative. The alternatives work, but have significant trade-offs.

Installing Podman

Install Podman using your distribution's package manager. See the official Podman installation guide for Linux.

# Ubuntu/Debian sudo apt-get update && sudo apt-get install podman # Fedora sudo dnf install --refresh podman

Note: Some distributions may have outdated Podman versions. This is the case with Ubuntu 24.04, which has Podman 4.9.3. We require Podman 5.0 or newer for the best experience, because we didn't have success with Podman 4.x in our automated tests, but you can still use Podman 4.x ignoring the warning on ddev start.

You can also install Podman Desktop if you prefer a GUI.

For more information, see the Podman tutorials.

Installing Docker CLI

Podman provides a Docker-compatible API, which means you can use the Docker CLI as a frontend for Podman. This approach offers several benefits:

• Use familiar docker commands while Podman handles the actual container operations
• Switch between different container runtimes using Docker contexts
• Maintain compatibility with scripts and tools that expect the docker command

1. Set up Docker's repository

2. Install only the CLI:

   # Ubuntu/Debian sudo apt-get update && sudo apt-get install docker-ce-cli # Fedora sudo dnf install --refresh docker-ce-cli

   Note: You don't need to install docker-ce (the Docker engine).

Configuring Podman Rootless

This is the recommended configuration for most users.

1. Prepare the system by configuring subuid and subgid ranges and enabling userns options, see the Arch Linux Wiki for details:

   # Add subuid and subgid ranges if they don't exist for the current user grep "^$(id -un):\|^$(id -u):" /etc/subuid >/dev/null 2>&1 || sudo usermod --add-subuids 100000-165535 $(whoami) grep "^$(id -un):\|^$(id -u):" /etc/subgid >/dev/null 2>&1 || sudo usermod --add-subgids 100000-165535 $(whoami) # Propagate changes to subuid and subgid podman system migrate # Debian requires setting unprivileged_userns_clone if [ -f /proc/sys/kernel/unprivileged_userns_clone ]; then if [ "1" != "$(cat /proc/sys/kernel/unprivileged_userns_clone)" ]; then echo 'kernel.unprivileged_userns_clone=1' | sudo tee -a /etc/sysctl.d/60-rootless.conf sudo sysctl --system fi fi # Fedora requires setting max_user_namespaces if [ -f /proc/sys/user/max_user_namespaces ]; then if [ "0" = "$(cat /proc/sys/user/max_user_namespaces)" ]; then echo 'user.max_user_namespaces=28633' | sudo tee -a /etc/sysctl.d/60-rootless.conf sudo sysctl --system fi fi # Allow privileged port access if needed if [ -f /proc/sys/net/ipv4/ip_unprivileged_port_start ]; then if [ "1024" = "$(cat /proc/sys/net/ipv4/ip_unprivileged_port_start)" ]; then echo 'net.ipv4.ip_unprivileged_port_start=0' | sudo tee -a /etc/sysctl.d/60-rootless.conf sudo sysctl --system fi fi

2. Enable the Podman socket and verify it's running (Podman socket activation documentation):

   systemctl --user enable --now podman.socket # You should see `/run/user/1000/podman/podman.sock` (the number may vary): ls $XDG_RUNTIME_DIR/podman/podman.sock # You can also check the socket path with: podman info --format '{{.Host.RemoteSocket.Path}}'

3. Configure Docker API to use Podman (Podman rootless tutorial):

   # View existing contexts docker context ls # Create Podman rootless context docker context create podman-rootless \ --description "Podman (rootless)" \ --docker host="unix://$XDG_RUNTIME_DIR/podman/podman.sock" # Switch to the new context docker context use podman-rootless # Verify it works docker ps

4. Proceed with DDEV installation.

Podman Rootless Performance Optimization

Podman Rootless is significantly slower than Docker. See these resources:

• Podman run/build performance issues
• Podman Performance documentation

To improve performance, install fuse-overlayfs and configure the overlay storage driver:

Install fuse-overlayfs:

# Ubuntu/Debian sudo apt-get update && sudo apt-get install fuse-overlayfs # Fedora sudo dnf install --refresh fuse-overlayfs

Configure storage:

mkdir -p ~/.config/containers cat << 'EOF' > ~/.config/containers/storage.conf [storage] driver = "overlay" [storage.options.overlay] mount_program = "/usr/bin/fuse-overlayfs" EOF

Warning: If you already have Podman containers, images, or volumes, you'll need to reset Podman for this change to take effect:

podman system reset

This removes all existing containers, images, and volumes (similar to docker system prune -a).

Configuring Podman Rootful

Rootless Podman is recommended. Only use rootful Podman if your setup specifically requires it.

To configure rootful Podman:

1. Create a podman group (sudo groupadd podman) and add your user to it (sudo usermod -aG podman $USER).
2. Configure group permissions to allow non-root users to access the socket
3. Activate the socket with sudo systemctl enable --now podman.socket
4. Create a Docker context docker context create podman-rootful --description "Podman (root)" --docker host="unix:///var/run/podman/podman.sock"
5. Switch to the new context with docker context use podman-rootful

Setting Up Docker Rootless

Docker Rootless on Linux offers rootless security with full Docker compatibility.

1. Follow the official Docker Rootless installation guide.

2. Configure system:

   # Allow privileged port access if needed if [ -f /proc/sys/net/ipv4/ip_unprivileged_port_start ]; then if [ "1024" = "$(cat /proc/sys/net/ipv4/ip_unprivileged_port_start)" ]; then echo 'net.ipv4.ip_unprivileged_port_start=0' | sudo tee -a /etc/sysctl.d/60-rootless.conf sudo sysctl --system fi fi # Allow loopback connections (needed for working Xdebug) # See https://github.com/moby/moby/issues/47684#issuecomment-2166149845 mkdir -p ~/.config/systemd/user/docker.service.d cat << 'EOF' > ~/.config/systemd/user/docker.service.d/override.conf [Service] Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_DISABLE_HOST_LOOPBACK=false" EOF

3. Enable the Docker socket, and verify it's running:

   systemctl --user enable --now docker.socket # You should see `/run/user/1000/docker.sock` (the number may vary): ls $XDG_RUNTIME_DIR/docker.sock

4. Configure Docker API to use Docker rootless:

   # View existing contexts docker context ls # Create rootless context if it doesn't exist docker context inspect rootless >/dev/null 2>&1 || \ docker context create rootless \ --description "Rootless runtime socket" \ --docker host="unix://$XDG_RUNTIME_DIR/docker.sock" # Switch to the context docker context use rootless # Verify it works docker ps

5. Proceed with DDEV installation.

6. Docker Rootless requires no-bind-mounts mode

   Docker Rootless has a limitation with bind mounts that affects DDEV. You must enable no-bind-mounts mode:

   ddev config global --no-bind-mounts=true

   Why this is needed:

   Docker Rootless sets ownership for bind mounts to root inside containers. This is a known issue:

   • Mounting a volume with rootless always assigns ownership to root
   • Add ability to mount volume as user other than root

   The root user inside the container maps to your host user, but many services will not run as root:

   • nginx runs as root without problems
   • MySQL/MariaDB need extra configuration
   • Apache and PostgreSQL will not run as root

   Podman Rootless fixes this with the --userns=keep-id option, which keeps user IDs the same. Docker Rootless does not have this option.

   The no-bind-mounts mode fixes this by using Mutagen for the web container.

macOS

macOS users can use Podman and Podman Desktop, but setup has its own challenges. Docker Rootless is not available on macOS.

Do You Need an Alternative to Docker? Runtime Why would you do this? Key trade-offs Performance Setup Recommendation Traditional Docker Standard, widely-used option None Excellent Simple Recommended for most users Podman Avoid Docker entirely (organizational policy) Cannot use ports 80/443 (must use 8080/8443 instead), different behavior Slower than Docker Moderate Only if Docker not allowed

Bottom line: Use traditional Docker (OrbStack, Docker Desktop, Lima, Colima, or Rancher Desktop) unless your organization forbids it. The inability to use standard ports 80/443 with Podman creates a significantly different development experience.

Installing Podman

Install Podman using Homebrew:

brew install podman

Or install Podman Desktop if you prefer a GUI.

For more information, see the official Podman installation guide for macOS and Podman tutorials.

Installing Docker CLI

Podman provides a Docker-compatible API, which means you can use the Docker CLI as a frontend for Podman. This approach offers several benefits:

• Use familiar docker commands while Podman handles the actual container operations
• Switch between different container runtimes using Docker contexts
• Maintain compatibility with scripts and tools that expect the docker command

brew install docker Configuring Podman

1. Handle privileged ports (<1024):

   Important: Podman on macOS cannot bind to privileged ports (80/443). You must configure DDEV to use unprivileged ports:

   ddev config global --router-http-port=8080 \ --router-https-port=8443

   This means your DDEV projects will be accessible at https://yourproject.ddev.site:8443 instead of the standard https://yourproject.ddev.site.

   Note: switching to rootful mode with podman machine set --rootful --user-mode-networking=false doesn't help with privileged ports because the --user-mode-networking=false flag is not supported on macOS (it's only available for WSL).

2. Initialize and start the Podman machine:

   # check `podman machine init -h` for more options podman machine init --memory 8192 podman machine start

   Check for the Podman socket path using podman machine inspect:

   ~ % podman machine inspect ... "ConnectionInfo": { "PodmanSocket": { "Path": "/var/folders/z5/lhpyjf2n7xj2djl0bw_7kb3m0000gn/T/podman/podman-machine-default-api.sock" }, "PodmanPipe": null }, ...

3. Configure Docker CLI to use Podman. Choose one of two approaches:

   Option 1: Create a Docker context (recommended, more flexible):

   # Create Podman context (path to socket may vary) # Use the socket path from `podman machine inspect` output docker context create podman-rootless \ --description "Podman (rootless)" \ --docker host="unix:///var/folders/z5/lhpyjf2n7xj2djl0bw_7kb3m0000gn/T/podman/podman-machine-default-api.sock" # Switch to the new context docker context use podman-rootless # Verify it works docker ps

   This approach uses Docker contexts to switch between different container runtimes without modifying system sockets. This is more flexible if you want to use multiple Docker providers.

   Option 2: Use the default Docker socket (simpler, but less flexible):

   # Install podman-mac-helper # Use the command from `podman machine start` output sudo /opt/homebrew/Cellar/podman/5.7.1/bin/podman-mac-helper install podman machine stop podman machine start # Verify it works docker ps

4. Proceed with DDEV installation.

Windows

Windows users can use Podman Desktop, but setup has its own challenges. Docker Rootless is not available on traditional Windows (it works in WSL2, see the Linux and WSL2 section).

Do You Need an Alternative to Docker? Runtime Why would you do this? Key trade-offs Performance Setup Recommendation Traditional Docker Standard, widely-used option None Excellent Simple Recommended for most users Podman Avoid Docker entirely (organizational policy) Different behavior, less mature on Windows Slower than Docker Moderate Only if Docker not allowed

Bottom line: Use traditional Docker (Docker Desktop or alternatives) unless your organization forbids it. Podman on Windows works but is less mature than on Linux.

Installing Podman

Install Podman Desktop, which includes Podman.

Alternatively, install Podman directly following the official Podman installation guide for Windows.

For more information, see the Podman tutorials.

The setup and configuration follow similar patterns to the Linux/WSL2 setup, but with Podman Desktop managing the VM for you. Follow the Linux and WSL2 instructions.

Running Multiple Container Runtimes

You can run Docker and Podman sockets simultaneously and switch between them using Docker contexts.

For example, here's a system with four active Docker contexts:

$ docker context ls NAME DESCRIPTION DOCKER ENDPOINT default Current DOCKER_HOST based configuration unix:///var/run/docker.sock podman Podman (rootful) unix:///var/run/podman/podman.sock podman-rootless * Podman (rootless) unix:///run/user/1000/podman/podman.sock rootless Rootless runtime socket unix:///run/user/1000/docker.sock

Switch between them with:

docker context use "<context-name>"

Note: Running both Docker and Podman in rootful mode at the same time may cause network conflicts. See Podman and Docker network problem on Fedora 41.

Switching Runtimes with DDEV

DDEV automatically detects your active container runtime. To switch:

1. Stop DDEV projects:

   ddev poweroff

2. Switch Docker context or change the DOCKER_HOST environment variable

3. Start your project:

   ddev start

Which Runtime Should You Choose? Runtime Comparison Feature Standard Docker Docker Rootless Podman Rootful Podman Rootless Platform Support All Linux, WSL2 All All Rootless Daemon ❌ ✅ ❌ ✅ Has automated testing in DDEV ✅ ✅ ❌ ✅ Mutagen ✅ ✅ ✅ ✅ Bind Mounts ✅ ❌, requires no-bind-mounts ✅ ✅ (with --userns=keep-id) Performance Excellent Moderate (because of no-bind-mounts) Slow compared to Docker Slow compared to Docker Privileged Ports (<1024) Works by default Requires sysctl config Works by default Requires sysctl config or may not work Setup Complexity Simple Moderate Moderate Moderate Maturity Most mature Experimental Experimental Experimental Recommended For Most users Docker users needing rootless Organizations that forbid Docker Organizations that forbid Docker Recommendations

Use of the many standard Docker providers if:

• You're comfortable with the most widely used container runtime
• You don't have rootless security requirements

This is the recommended option for the vast majority of users.

Use Podman Rootless if:

• Your organization forbids Docker
• You want rootless security by default

Use Podman Rootful if:

• Your organization forbids Docker
• You want traditional container permissions without user namespace mapping overhead

Use Docker Rootless if:

• You need full Docker compatibility
• You want rootless security without changing runtimes

The Journey to Podman Support

Supporting Podman and Docker Rootless required major changes to DDEV's Docker integration:

• Switched to official Docker client library (#5787): DDEV previously used an unofficial library to communicate with the Docker API. We migrated to Docker's official client library for better compatibility and long-term support.
• Replaced direct CLI calls with proper API usage (#7189): DDEV used to call docker context inspect directly, which doesn't work with Podman. We switched to using the docker/cli library to handle context operations properly.
• Modernized SSH authentication (#7511): The ddev auth ssh command used to call docker run directly. We rewrote it to use the Docker API, making it compatible with alternative runtimes.
• Optimized API call performance (#7587): DDEV's Docker API logic was inefficient, making redundant calls without caching. We restructured the code to cache data and reduce unnecessary API requests.
• Removed legacy docker-compose features (#7642): Podman refuses to work with deprecated links and external_links directives in docker-compose files. We removed these legacy features and modernized DDEV's compose file generation.
• Added Podman and Docker Rootless support (#7702): DDEV now detects and supports Podman (rootful and rootless) and Docker Rootless. We added handling for Podman-specific limitations and enabled rootless environments to work without root privileges.
• Added support for SELinux environments (#7939): Podman has SELinux enabled by default on Fedora and some other distributions. We added support for SELinux by configuring volume mounts with the appropriate labels.

These changes enabled Podman and Docker Rootless support. These features were developed together because Podman's primary use case is rootless operation. Once DDEV could handle rootless runtimes, supporting both became natural. They share the same security model and similar technical constraints.

Supporting DDEV Development

This Podman and Docker Rootless support was made possible by community financial support. The changes required hundreds of hours of development, code reviews, and testing.

DDEV relies on support from individuals and organizations who use it. With Podman rootless support, DDEV now works in corporate environments where Docker Desktop is not allowed. If you or your organization uses DDEV, please consider sponsoring the project to help keep DDEV free and open source.

Conclusion

DDEV now supports Podman and Docker Rootless as experimental features. This opens DDEV to corporate environments where traditional Docker is not allowed.

DDEV automatically detects your runtime and handles the complexity. Whether you choose Podman for rootless security, Docker Rootless for compatibility, or standard Docker, setup is straightforward.

This article was edited and refined with assistance from Claude Code.

Every year on 4th February, the world unites to mark World Cancer Day (WCD), a campaign that raises awareness, amplifies voices, and inspires collective action against cancer. Behind the scenes, the World Cancer Day website, built with Drupal, powers millions of people, providing a central platform for global engagement.

Project overview

• Project: World Cancer Day
• Industry: Non-profit
• Solutions: CMS, hosting, artificial intelligence
• Main technology: Drupal
• Digital partner: 1xINTERNET
• Website: worldcancerday.org

Campaign and its impact

The World Cancer Day 2025-2027 campaign embraces the theme “United by Unique”, emphasizing people-centered care. This approach prioritizes the needs, values, and active participation of individuals, families, and communities in cancer care. By putting people at the heart of the conversation, the campaign promotes a shift toward more inclusive, responsive, and compassionate health systems.

The 2025 campaign achieved remarkable global engagement:

• +900 activities in 120 countries
• +600 stories shared in text, video, and art
• +1,000 participants in the Upside Down Challenge
• +30,000 press mentions in 162 countries
• 6 billion digital impressions and 9 million social media engagements
• 530,000 website visitors and +300,000 campaign video views

These numbers highlight both the scale of the campaign and the critical need for a platform that can reliably support millions of users simultaneously.

Explore more about the campaign and join the global action at World Cancer Day.

Supporting global action with Drupal

Supporting a high-profile global campaign requires flexibility, scalability, and robustness, capabilities that are fundamental to Drupal’s architecture.

Key features

• Multilingual CMS: Centralized content management across multiple languages ensures the website can reach a large global audience.
• Scalable hosting: Drupal handles traffic surges exceeding 194 GB per hour, delivering consistent performance during peak activity.
• Complex interactive tools: Custom features such as poster creation, event planning tools, and a global activities map make it easy for users to participate and share initiatives.
• Dynamic content delivery: Scrollytelling, multimedia content, and personal stories from those affected by cancer create an engaging, meaningful experience.
• Accessibility: Drupal’s accessibility capabilities reinforce inclusivity by supporting diverse audiences at scale.

"I've been pleased with my experience with Drupal. While the earlier versions were sometimes technically complex, it always felt like a solid, robust platform to build upon. I have been genuinely pleased that we chose to stick with it over the long term and to witness its evolution into a more mature and flexible platform." 

Charles Andrew Revkin  Senior Digital Strategy Manager  Union for International Cancer Control ( UICC)

Scaling impact with Drupal AI

To manage the vast volume of user-submitted stories while maintaining quality, relevance and inclusivity, WCD integrated Drupal AI. This automation helps with content moderation and reduces manual workload, allowing more people to share their experiences and supporting the campaign’s people-centered mission as it scales.

Why Open Source matters for global health initiatives

For non-profit organizations in the healthcare sector, efficiency, transparency, and long-term sustainability are essential, especially when every investment must directly support the mission. As an open-source platform, Drupal eliminates licensing costs and avoids vendor lock-in, allowing resources to be focused on participation and impact rather than software fees. Supported by a global contributor community, Drupal benefits from continuous improvements in security, accessibility, and performance, making it a trusted foundation for sensitive, high-impact initiatives like World Cancer Day.

Technology that serves people at scale

The global fight against cancer requires collective action, and Drupal plays an important role in enabling that engagement. By managing large-scale data, complex interactive features, and high-traffic performance, the platform ensures that the campaign can reach millions of people, foster participation, and support socially impactful initiatives year after year.

Read the full case study on 1xINTERNET website

File attachments:  CS_WCD_01.png