fidzu : Drupal

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

03 Feb 2026 5:00pm GMT

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.

03 Feb 2026 10:15am GMT

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.

03 Feb 2026 9:24am GMT

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

03 Feb 2026 12:09am GMT

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.

03 Feb 2026 12:00am GMT

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.

03 Feb 2026 12:00am GMT

02 Feb 2026 11:53pm GMT

02 Feb 2026 11:53pm GMT

Today we are talking about Development Workflows, Agentic Agents, and how they work together with guests Andy Giles & Matt Glaman. We'll also cover Drupal Canvas CLI as our module of the week.

For show notes visit: https://www.talkingDrupal.com/538

Topics

• Understanding Agentic Development Workflows
• Understanding UID Generation in AI Agents
• Exploring Generative AI and Traditional Programming
• Building Canvas Pages with AI Agents
• Using Writing Tools and APIs for Automation
• Introduction to MCP Server and Its Tools
• Agent to Agent Orchestration and External Tools
• Command Line Tools for Agent Coding
• Security and Privacy Concerns with AI Tools
• The Future of AI Tools and Their Sustainability
• Benefits of AI for Site Builders

Resources

• Decoupled frontend with Drupal Canvas
• AI workflows will reshape development organizations - mglaman.dev
• Agents.md
• AI is here to stay
• Autocomplete training 38:09 Code completion
• MCP
• Open Code
• Geerlingguy ai voice

Guests

Matt Glaman - mglaman.dev mglaman

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Andy Giles - dripyard.com andyg5000

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to sync components from a site using Drupal Canvas out to another project like a headless front end, or conversely, from an outside repo into Drupal Canvas? There's an NPM library for that
• Module name/project name:
  • Drupal Canvas CLI
• Brief history
  • How old: created in July 2025 (as xb-cli originally) by Bálint Kléri (balintbrews) of Acquia
  • Versions available: 0.6.2, and really only useful with Drupal Canvas, which works with Drupal core 11.2
• Maintainership
  • Actively maintained
  • Number of open issues: 8 open issues, 2 of which are bugs, but one of which was marked fixed in the past week
• Usage stats:
  • 128 weekly downloads according to npmjs.com
• Module features and usage
  • With the Drupal Canvas CLI installed, you'll have a command line tool that allows you to download (export) components from Canvas into your local filesystem. There are options to download just the components, just the global css, or everything, and more. If no flags are provided, the tool will interactively prompt you for which options you want to use.
  • There is also an upload command with a similar set of options. It's worth noting that the upload will also automatically run the build and validate commands, ensuring that the uploaded components will work smoothly with Drupal Canvas
  • I thought this would be relevant to our topic today because with this tool you can create a React component with the aid of the AI integration available for Canvas and then sync that, either to a headless front end built in something like Next.js or Astro or a tool like Storybook; or you could use an AI-enhanced tool like Cursor IDE to build a component locally and then sync that into a Drupal site using Canvas
  • There is a blog post Balint published that includes a demo, if you want to see this tool in action

02 Feb 2026 7:00pm GMT

Five years after the idea first surfaced, Drupal CMS 2.0 has arrived, with a clear focus on the early experience. Released on 28 January 2026, the update introduces real-time page editing via Drupal Canvas, a templating system with sector-specific defaults, and optional AI guidance. It's not a reinvention of Drupal. It's a response to what new users most often struggle with: getting started quickly without sacrificing long-term flexibility.

The release is built on Drupal Core 11.3, bringing the platform's biggest performance gains in over a decade-up to 33% faster request handling. Canvas replaces the standard editing workflow with a drag-and-drop interface, powered by the new Mercury component system. The first template, Byte, is preconfigured for SaaS marketing sites and installs in under three minutes. Optional AI tools support page scaffolding, alt text generation, and guided content modelling, with integration available for amazee.ai, OpenAI, and Anthropic.

On launch day, Dries Buytaert called the release "power without complexity," noting that it changes the starting point, not the system. Contributed module compatibility is preserved, and features from Drupal CMS 1, like automatic updates and the Gin admin UI, remain intact. For teams evaluating Drupal in 2026, CMS 2.0 sets a clearer baseline: real output, faster, with less overhead.

Discover Drupal

• Drupal CMS 2.0 Is Here - Power Without Complexity
• Drupal CRM Beta Launches to Replace Node-Based Contact Management
• Drupal.org Introduces New GitLab Issue Workflow for Migrated Projects
• Pivale Releases Commerce Referral Module for Flexible Incentive Workflows
• Shibin Das Demonstrates Loop Execution in FlowDrop Episode 4 Using Drupal
• Deuteros Speeds Up Drupal Unit Testing with AI‑Assisted PHP Library
• People-First Strategy Is Key to AI Web Creation, Says Aidan Foster of Foster Interactive

Event

• Drupal Pivot in Ghent Marks Turning Point for CMS, AI, and Sovereignty
• Acquia to Host Webinar on AI-Driven Content Execution and the Rise of LLMs
• DrupalCamp Grenoble 2026 Opens Ticket Sales for Three-Day Community Event
• Drupal Ottawa Meetup to Spotlight CMS 2.0 and Preview 2026 DrupalCamp
• DrupalCamp England Opens Registration for 'Drupal in a Day' Workshop

Organization News

• Zoocha Rebrands as Digital Experience Agency Powered by Drupal
• CKEditor Updates Add Footnotes, Line Height, and Restricted Editing to Drupal Modules

Free Software

• Dries Buytaert: AI Is Adding Work, Not Relief, for Open Source Maintainers

We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now. For timely updates, follow us on LinkedIn, Twitter, Bluesky, and Facebook. You can also join us on Drupal Slack at #thedroptimes.

Thank you.

Kazima Abbas
Sub-editor
The Drop Times

02 Feb 2026 4:31pm GMT

Drupal's default workflow doesn't always meet user needs. When you have to review content before publishing, the Content Moderation module becomes a key tool. It allows you to define and control content workflows. Discover how the Content Moderation module can help you manage content in Drupal.

02 Feb 2026 2:19pm GMT

02 Feb 2026 1:01pm GMT

Lots of people working in technology have a choice between working for clients or working for consultants. We work on one side of the relationship thinking how nice it would be to have the advantages of being on the other; the preverbal grass is always seems greener.

I spent a little more than ten years as a client before I became a consultant. I spent just a bit longer as a consultant before becoming a client again. There are things I've learned in each role that help me do the other better. To ensure a mutually beneficial engagement it is helpful to understand the perspective of the other team.

Why is understand both sides useful?

The goals of a consultant and a client organization are misaligned. That doesn't mean you can't do great things together, but if you don't understand the goals of your partner you are likely to step on each other's toes.

The goals of clients

Client looks to consultants for one of two primary reasons:

• Add to team capacity
• Solve a problem

We either need to complete a project that our team does not have the time to tackle, or we need expertise it does not make sense for us to keep on staff. Sometimes we're looking to reduce costs by having a group of part time people fill the roles of a smaller number of fulltime team members.

I like to have my team's staffing level sufficient to complete all day-to-day tasks and to bring in outside help to take on special projects. Other people like to have consultants around consistently to provide the outside perspective and the diverse expertise that consultants bring. Both of those strategies are foundationally aimed at those two needs.

A smart client wants to spend the money needed to be successful, but not more. We want the most value for our money we can possibly get.

The goals of consultants

Consultants have a different pair of primary goals:

• Record billable hours and/or ensure profit margin
• Have a happy client who refers more business

Some consultants will protest that they have the goal to solves client's problems through good work. My perspective is those are way to achieve those two goals. Some clients are happy when you do good work (but not all). All clients are paying to have a problem solved (see above).

Profit motive isn't evil or wrong - even when supporting nonprofits and other socially beneficial institutions (having spent much of my career in nonprofits, we think about this a lot). Consultants need to make money to stay afloat. A consulting firm has people to pay, overhead to manage, and founders/investors to reward. Independent consultants need to eat, pay their mortgage, and so on. The larger the firm, the more pressure there is for larger profit margins.

To get new clients, consultants need "referable" clients. That means having clients who are so happy with the work done they will serve as a reference. I wish that always meant creating the best solution possible. What it means in practice is building the solution that makes the client happy. As a consultant I gave clients my best advice, and when they disagreed and insisted on a different solution, we build that instead. If they ran out of money along the way we still tried to keep them happy, even if we had the duct tape the last bits.

In the end, consultants build what clients pay for, and that's not always the best solution.

Finding the balance

With consultants trying to make the most money they can, and clients trying to get a successful solution for the least money, there is an inherent tension in the system. Still, there is a balance to be had, where everyone wins, and great things happen. The trick is to make it a healthy tension that forces everyone to be better. Finding that balance doesn't require that everyone involved has spent time on the other side the relationships, but it certainly helps.

When you understand the needs and goals of the other side of the relationship you can adjust your approach to make sure everyone is aligned to win.

Lessons to take from being a client

One of the things I learned along the way was that a lot of the advice given to new consultants contradicts what I knew from being a client. Spending time as a client gives you insights into how to best serve customers that many pure consultants don't understand.

Be the consultant you want to hire

When you work at an organization that hires consultants you see different approaches taken by different firms. You learn your preferences about what you like and don't like in a consulting partner. While no one style is the best fit for everyone it's unlikely that you are so unique that there aren't lots of other people who like that same style.

Default to the Golden Rule: treat clients the way you wanted to be treated by consultants.

You can't always do that 100% of the way - sure as a client I want everything free, but that's not reasonable. But by approaching the client the way I would have wanted to be treated consistently went a long way to helping smooth over challenges.

Start there, and over time you'll learn to adapt your approach when specific clients prefer a different style.

Be honest about your limitations

Do. Not. Lie. To. Me.

Do not guess without admitting it. If I wanted made up answers, I'd ask an AI.

Consultants always want to appear to be the expert in the room, and so they feel they have to answer every question. Too often that leads to consultants making up answers to show how smart they are; clients will catch you eventually.

One of the best ways to build trust with a client is admit when you don't know the answer to a question, and then come back later with the answer. Do not say "I don't know" and leave it there, go for some form of "I will need to go look that up/ask around/figure that out."

Great consultants find solutions, they don't always have the answer right away. We can wait for you to do some research when we stump you. That is a lot easier to explain than when you have to walk back having given us the wrong answer.

Focus on what the client needs to succeed

Clients should always have an outcome in mind that supports their work. Consultants are focused on the solution they are building. When everything is going well, that solution is what the client needs to support their work. If those stop being the same thing you have a very big problem.

Both clients and consultants can easily forget to consistently re-check that alignment. As a client and as a consultant I've been part of projects where the delivered solution didn't solve the actual problem - even when it fulfilled the spec and SOW. These moments frequently lead to energetic discussions that often become loud. No one wins when that happens.

Regularly check with the client, and with yourself, to see if the solution will solve the client's problem. When you see misalignment raise your hand early and often.

Lessons to take from being a consultant

Of course consultants know and learn stuff that isn't obvious to any given client. Consultants bring wider experiences, different perspectives, and a different energy to a project. That is part of what makes them valuable. Clients should hire a consultant they trust, and listen to their consultant. Think hard before deciding you know better.

Always learn new things, even if they aren't important today

As a client we tend to learn deeply about the tools we use and our work. Consultants work on a lot of projects with a lot of clients. Along the way they use a lot tools, and see at lot of ideas. That creates a culture and need for constantly learning. Often they are learning about things that don't seem useful right away.

The higher the role you have as a consultant, the more you are expected to be at least conversant about technology you haven't used yet. You also need to be conversant about the work of your clients. That's a lot of learning.

I had good learning habits going in to being a consultant. They served me extremely well as a consultant, and are serving me well again as a client.

The broad knowledge of a consultant is extremely useful and everyone benefits from more people knowing more stuff. Having that breadth of knowledge also helps when you do run into the places where you don't know something. It gives you the confidence that you can go learn the next thing you need to know quickly (see Be honest about your limitations above).

Know how to work to a deadline

Consultants are always working within time and budget constraints - usually tight ones. That forces them to learn to be efficient. Sometimes that means they cut corners (see next section) usually that just means they move fast. Good consultants have a high degree of dexterity with their tools, they learn to line up their work to knock out tasks, and they learn what's needed and what's just nice to have.

New consultants often feel like they are sprinting all the time, but experienced consultants learn to balance the sprints with jogging. The pace is nearly always high (at least if sales are going well), but it still ebbs and flows. Consultants learn to hit their deadlines, but rarely are ready to deliver early.

As a consultant if a deadline was far in the future it gave me time to do careful work, balance other clients, do research, or just time off. Far off deadlines gave me time to recover from sprints and make sure I had the energy for high intensity moment. That intensity is important to driving client success - but hitting the deadline is more important.

Hitting deadlines is also important for a client to do. Consultants need you to hit your deadlines so they can balance their workload to hit their deadlines. They may also have penalties embedded in the contract (see Read the Contract below) that could cost you time or money over the course of your project.

Perfect is the enemy of the good

Okay, this isn't something just consultants know, but it is something consultants often learn to deal with the hard way.

Consultants need a solution that meets the requirements, fits in the budget, and pleases the client. They are not there to create a solution that is perfect, or even elegant. In any project there is a balance to be had between carefully polished, and just barely good enough to be successful. Consultants learn to thread that needle. As long as the project is successful that's a good thing.

I have seen developers spend hours, days, even months, trying to build to the perfect level of abstraction, with the perfect naming conventions, and drive for the perfect code, only to have the project fail because it's overdue, over budget, and was outmoded by someone who worked twice as fast.

Yes, we all want good solutions to our technical problems. But no solution is going to be perfect. You should aim for perfection and know you are going to miss. When you learn to accept that, it'll be easier to move forward and be successful.

Things everyone should know regardless of role

For all there are things that each side brings something to the table, there are habits that everyone should have as part of their role. There are lessons I learned, or was taught, in both roles that are super important.

Read, and understand, the contract

Everyone on a project benefits from having working knowledge of the contract. In the end, when push comes to shove, all that matters is the words on the paper. You can usually avoid the pushing and shoving by understanding what everyone agreed to up front.

The biggest issues I've seen on consulting projects was when one side, or the other, didn't pay attention to the agreement.

Sometimes this happens because everyone is working in good faith, and no one remembers to amend the agreement when needs changed. In those cases you can often recover by continuing to work with each other in good faith.

Sometimes this happens when someone signed a contract they didn't read and understand. I once had a client yell at me because I added a paragraph to the contract outlining the resources they were responsible for providing and he didn't read it before we asked him for those resources (these clauses are really standard, and the one I wrote was extremely simple).

If everyone on the team takes the time to read and understand the contract it greatly reduces friction. Clients who understand the bounds and assumptions in a contract are able to get the most from their vendor without creating tension. Consultants who track the required deliverables of the contract don't frustrate clients by skipping required elements. It doesn't take long. The more you read them the faster we'll be at reading the next one.

Once you have read a bunch of contracts you'll know what's normal and what's not. At this point, if I don't understand the contract language I see that as a red flag even before I send it out for legal review.

Discuss problems and be solution oriented

Projects go best when everyone is open about what problems exist and then pivots to solving them.

Technology should be deployed to solve problems. That means starting by talking about problems. Being problem focused at the start makes it easy to be hung up talking only about those problems, or about new problems that come up while solving the first problem.

Having a good problem statement is critical to creating good solutions. But once you have the problem outlined you need to focus on solving it. Yes, raise problems, concerns, challenges, threats, weaknesses, etc. Talk openly about all those things. Then make the pivot into problem solving mode once the issue is well understood.

The best projects come together when when everyone collaborates on finding the best solutions to the problems at hand.

Quality matters

Everyone needs to focus on the quality of the outcome. Consultants, for all their fast moving creation of imperfect solutions, must still do good work. Clients should hold their vendors, and themselves, to high standards.

Every message that goes back and forth is a chance for misunderstand that gets in the way. Every input into discovery and every deliverable is a chance for gaps to form. If anyone takes their eye off the ball mistakes can happen and the solution no longer threads the quality needle correctly.

Mistakes will happen, and everyone will have to help course correct. But the higher the quality of the work done before the mistake, the faster it will be to recover and better and overall solution the client will get.

The Grass is Greener

One final note on the way out. If you are trying to decide between being a consultant or being a client, I recommend the switch - whichever you are today try being the other if you haven't yet. Not everyone loves both roles, and different roles have been right for me at different times.

As a client I loved what I did. We were helping make the world better. I was pushing things forward and helping the organizations succeed. But eventually the things they needed me to learn, and the pace I wanted to grow, weren't aligned to the organization's needs.

I'd been there a decade, I left on great terms, but it was time to go.

When I first became a consultant it was exciting. I got to work on a variety of projects, with more technologies than any one organization generally needs. The pace was higher and I was frequently pushing myself in new directions. Consulting gave me insights into how different organizations worked (for both better and worse). And I made more money.

Interesting work, exciting environment, more money, great!

As a consultant I spent less time in positions, the billable grind was exhausting, I missed being focused. When I returned to the client side, I got to focus again. I have one org to worry about, one set of organizational politics to understand, and so on. I get to learn the work of the organization deeply again and really understand the market we serve. In my case I, again, got more money - but that was at least partially luck as much as anything; consultants are often paid better than in-house team members.

Focused work, no billable hours target, calmer work environment, great!

Each really does have it's advantages. But so does understanding what it's like to be the person on the other side the relationship. Try them both, learn from both, decide what's the best fit for you.

31 Jan 2026 5:36pm GMT

My LocalGov Drupal contributions for January 2026

markconroy 30th Jan 2026

30 Jan 2026 3:44pm GMT

30 Jan 2026 2:09pm GMT

Held in Ghent during EU Open Source Week, Drupal Pivot brought together agencies and contributors for open conversations on resilience, AI, and digital sovereignty. Its timing, with the release of Drupal CMS 2.0, made it a point of reflection and transition.

30 Jan 2026 1:33pm GMT