Colan Schwartz: Want to Run Drupal in Kubernetes? Try Our New Terraform Module

Image removed.

This article was originally published on the BackUpScale blog.

Background

Our customer dashboard, which will soon be used for managing subscriptions to our backup service (and not just newsletters and our contact form, as we’re doing now), is built on the Drupal data management framework. Until now, we’ve been hosting it with a company that specializes in hosting very specific types of applications, like Drupal. This wasn’t working for us because our service is running in our Kubernetes cluster at a cloud service provider that specializes in managed Kubernetes hosting, which let’s us run whatever applications we want, and configure them however we need. The challenge was getting the dashboard to communicate securely with our other applications.

It needs to communicate with our back-end systems in the Kubernetes cluster to:

  1. send requests from customers to provision services,
  2. configure customer accounts, and
  3. receive status information from back-end services to create log entries that users can see in their accounts.

Why the old approach broke down

In order for things to work with the old set up, we’d have to:

  • expose internal applications to the Internet (so the dashboard site could access them), and
  • add additional layers of security to the communications to ensure privacy.

We didn’t feel as confident with this set-up as moving everything into our private Kubernetes network, which protects all of our services with a single firewall. Keeping non-public facing services within that network ensures that they’re not accessible by anyone on the greater Internet (except our staff using the company VPN), which ensures greater security and privacy for our users.

In order to make the change, we needed to be able to run a Drupal site within Kubernetes. Given that Drupal is a popular framework, and Kubernetes is a popular container orchestration system, we assumed that there would be good options for putting them together using open-source infrastructure as code (IaC) to handle the automated provisioning (we automate everything here). However, we weren’t able to find anything that could help us.

Evaluated options

We explored the following options:

The Bitnami Helm chart did at least one very strange thing: It was placing the Drupal code files on the persistent volume instead of placing them in the container image. We wanted the Drupal code (or at least the Composer files that build it along with any custom code) to be version controlled with Git. When we tried to work around this, they made it very difficult to make these changes.

Jeff Geerling simply stopped recommending his earlier approach (except for potentially hosting many sites on a hosting platform), and said that he currently uses his own Kubernetes primitives. So we took that idea, and expanded on it to build a fairly complete solution. Once we had something that worked for us, we believed we could make it generic enough to make it available to everyone else. So that’s what we did.

Image removed.

This move eliminated two Internet-facing endpoints and let us apply a single network-policy layer to all microservices. Additionally, running inside the cluster removes a public load balancer, and shrinks latency.

Meet “Drubernetes”

Because we automate all of our infrastructure with Terraform, we just released Drubernetes, a new module in the Terraform Registry, which provisions Drupal onto a generic Kubernetes cluster. It shouldn’t matter where your cluster is, who’s managing it for you, or if you’re managing it yourself on your own hardware. We wanted to provide something standardized that everyone can use and build from.

Contribute

Contributions are welcome! Please try it, and provide any feedback that you may have. The project is hosted on Gitlab.com, and any issues can be opened from the board.

As always, if you have questions or feedback, feel free to reach out. We appreciate your support and can’t wait to bring you the next chapter of BackupScale.

Colan Schwartz: From DevOps Headaches to Seamless Onboarding: How Dropping Chocolatey Made DDEV the Perfect Fit for a Client's Drupal Team

Image removed.

TL;DR

After watching my enterprise client’s Drupal developers lose hours every week wrestling with raw Docker Compose for local development, I championed a switch to DDEV, the open‑source tool that gives “container superpowers with zero required Docker skills” (ddev.com). One of the snags on their Windows laptops was the Chocolatey package manager, whose install path clashed with locked‑down corporate security policies. Working with DDEV maintainer Randy Fay, I removed the Chocolatey dependency, paving the way for a leaner installer that shipped in version 1.24.5. Development team members now onboard much quicker, and leadership can point to measurable productivity gains.

The Starting Point: Docker Compose Drag

My client’s legacy workflow relied on a bespoke Docker Compose stack. Developers routinely diverted time to babysit containers as well as copying their work in and out, instead of writing code. This echeos industry findings that more than 58% of engineers lose 5‑plus hours per week to “unproductive work”. This DevOps overhead impacts their developer experience (DX), which is a distraction from their actual work.

Enter DDEV

DDEV abstracts all that Docker plumbing with simple commands (e.g. ddev start, ddev stop) while still running everything locally. Its promise, “environments in minutes, multiple concurrent projects, and less time to deployment”, resonated immediately.

Why It Mattered for Drupal

A Drupal codebase is never just PHP; it drags along Composer, Drush, front‑end toolchains, and database snapshots. DDEV’s predefined Drupal preset provides a reproducible stack with Nginx/Apache, MariaDB, and Mailhog out of the box.

A Windows Speed‑Bump Called Chocolatey

The developers work on locked‑down Windows laptops. DDEV’s install script used the Chocolatey package manager, which corporate policies block from writing to its default location. Workarounds involved various hurdles, exactly the sort of DevOps toil they wanted to eliminate.

Collaborating Upstream: Issue #6636 → PR #7049

While in research mode, I discovered Issue #6636, maintainers themselves wanted to drop Chocolatey but hadn’t had the bandwidth to do so. I volunteered a pull request that:

  • removed Chocolatey from the installation process, and
  • no longer required an Administrator Powershell; an unprivileged user could install it in a terminal.

The patch was merged on April 10, 2025.

Release v1.24.5: Goodbye Chocolatey

A month later, the change landed in v1.24.5 with a shout‑out in the release notes: “Chocolatey removed from automated Windows installation scripts. Thanks to @colans.” It’s now simpler for Windows developers to install DDEV, and they don’t have to be an administrator.

Business Case (as pitched to leadership)

“Container superpowers with zero required Docker skills” isn’t just marketing. Here’s the quantified rationale I presented:

  1. Zero Docker config: ddev start replaces hand‑rolled Compose files.
  2. No central registry maintenance: Images build locally.
  3. Host‑level commands: ddev drush status or ddev composer install without docker exec.
  4. Unified file system: The code lives on the host, eliminating copy‑in/out cycles.
  5. Safe rebuilds: Deleting containers never loses work.
  6. Always‑on Git: blame, diff, and branch with the active code without stepping into the container.
  7. First‑class Composer: Composer‑managed Drupal is just a ddev composer require away.

Outcomes

  • Onboarding time dropped from half a day (or more) to an hour (or less).
  • Additonal support for broken sandboxes fell to nearly zero.
  • Developers now focus on development, not troubleshooting containers, or moving code in and out of them.

Gratitude

I’d like to thank Randy Fay for prompt code reviews, patient feedback, and for shepherding the change into a release.

Ready to Try?

Head to the official DDEV installation documentation and give it a spin. And if you’re stuck on Windows, it’s now much easier to install.

The Drop Times: What Noah’s Page Builder Just Quietly Solved in Drupal—And Why It Matters

Noah’s Page Builder rolls out its biggest update yet bringing AI-assisted text, instant multilingual translation, reusable widgets, and a revamped interface to the Drupal ecosystem. Built with full transparency and no paywalls, this tool continues to prioritize the community over monetisation.

DDEV Blog: Using FrankenPHP with DDEV

Image removed.

Introduction

The PHP ecosystem is changing fast, with tools like FrankenPHP improving both performance and developer experience.

FrankenPHP is now officially supported by The PHP Foundation.

This guide explains two ways to integrate FrankenPHP, based on my experience.

You can either run FrankenPHP as a separate service (lets you install extra PHP extensions) or inside DDEV's web container (uses a static binary without support for extra extensions).

Generic web server

This blog shows examples of the recently added DDEV's generic web server, which supports flexible configurations. It allows you to use any custom web server you want, including Node.js, Python, Ruby, etc.

DDEV FrankenPHP Add-on

I created the stasadev/ddev-frankenphp add-on to experiment with FrankenPHP as a separate service with some additional features:

  • Ability to install PHP extensions (Redis, Xdebug, SPX, etc.)
  • Better resource isolation

⚙️ Installation:

ddev config --webserver-type=generic ddev add-on get stasadev/ddev-frankenphp ddev restart

To add PHP extensions (see supported extensions here):

ddev dotenv set .ddev/.env.frankenphp --frankenphp-php-extensions="redis pdo_mysql" ddev add-on get stasadev/ddev-frankenphp ddev stop && ddev debug rebuild -s frankenphp && ddev start

⚠️ Limitations:

  • Standard Linux and DDEV tools are installed in the web container, not in the frankenphp container.
  • See the add-on README for adding Xdebug (ddev xdebug does not work here).
  • Enabling or disabling Xdebug requires rebuilding the frankenphp container.
  • ddev launch does not work because the web server runs in a different container.

If you want to suggest some feature or found a bug, feel free to open an issue.

Running FrankenPHP in the Web Container

Alternatively, FrankenPHP can be run inside the web container. This example from the DDEV quickstart shows a setup (for a Drupal 11 project) where FrankenPHP is added as an extra daemon.

⚙️ Installation:

export FRANKENPHP_SITENAME=my-frankenphp-site mkdir ${FRANKENPHP_SITENAME} && cd ${FRANKENPHP_SITENAME} ddev config --project-type=drupal11 --webserver-type=generic --docroot=web --php-version=8.4 ddev start cat <<'EOF' > .ddev/config.frankenphp.yaml web_extra_daemons: - name: "frankenphp" command: "frankenphp php-server --listen=0.0.0.0:80 --root=\"/var/www/html/${DDEV_DOCROOT:-}\" -v -a" directory: /var/www/html web_extra_exposed_ports: - name: "frankenphp" container_port: 80 http_port: 80 https_port: 443 EOF cat <<'DOCKERFILEEND' >.ddev/web-build/Dockerfile.frankenphp RUN curl -s https://frankenphp.dev/install.sh | sh RUN mv frankenphp /usr/local/bin/ RUN mkdir -p /usr/local/etc && ln -s /etc/php/${DDEV_PHP_VERSION}/fpm /usr/local/etc/php DOCKERFILEEND ddev composer create-project drupal/recommended-project ddev composer require drush/drush ddev restart ddev drush site:install demo_umami --account-name=admin --account-pass=admin -y ddev launch # or automatically log in with ddev launch $(ddev drush uli)

⚠️ Limitations:

  • It's not possible to install additional PHP extensions (requires ZTS build).
  • Limited debugging capabilities, ddev xdebug doesn't work.

Resources

Benchmarking

Using ddev-frankenphp-benchmark, I compared three setups:

  • nginx-fpm: DDEV's nginx-fpm web server with php-fpm
  • generic-web: DDEV's generic web server with FrankenPHP inside the web container (static binary)
  • generic-addon: DDEV's generic web server with FrankenPHP inside the frankenphp container (with pdo_mysql extension)

Summary:

  • All configurations delivered comparable and adequate performance.
  • FrankenPHP is a win where there is an upstream hosting environment using FrankenPHP.
  • Benchmarks used default DDEV settings, not production-optimized configurations.
  • Laravel Octane (FrankenPHP worker mode) was not used and could yield better results.
  • CPU and memory usage were not measured.

Benchmarking Results

Software:
DDEV: v1.24.6
Mutagen: disabled
PHP: v8.4
Laravel: v12.19.3
FrankenPHP: v1.7.0
Docker Engine: v28.3.0
Operating System: Manjaro Linux AMD64
Kernel Version: 6.12.35-1-MANJARO

Hardware:
Intel i7 8750H (6 Core/12 Thread, 2.2 Ghz, Turbo 4.1 Ghz)
32 GB DDR4 2667 Mhz
Samsung 870 Evo SSD (530w/560r MB/s)

Image removed.

Image removed.

Image removed.

Image removed.

Image removed.

Image removed.

If you find DDEV (and its add-ons like FrankenPHP) useful, consider supporting its development. Thank you!

Drupal AI Initiative: Welcome to the Drupal AI Initiative: What We Learned from Our June 26 Webinar

Image removed.

The BIG Idea: Open, Safe AI for Everyone

At its core, the Drupal AI Initiative is about helping organisations adopt AI responsibly. As Paul Johnson put it:

“We’re looking to tell the amazing story of how Drupal AI can help organisations that want to adopt AI that is safe and in a way where freedom remains to make their own choices.” - Paul Johnson

The group shared updates on work happening in AI Core, including modules for agents, logging, testing, and a new Experience Builder that aims to make page creation smarter without compromising on security or trust.

“I’m not a programmer myself. Everything we've done with AI we’ve tried to build in a way that analysts, PMs, even content editors can make use of.” - Jamie Abrahams

Key Points From the Q&A

Attendees asked important questions, and were answered transparently:

  • Funding: Smaller agencies raised concerns about staying competitive in a rapidly evolving AI space. The group discussed options like the Makers funding program and collaborative approaches to share costs.

  • Safe adoption: Several participants asked how to keep up with AI’s breakneck pace while avoiding dead-ends. The consensus: stick to open standards, contribute upstream, and share what works.

  • Contribution paths: For developers and marketers alike, there are plenty of ways to get involved, from writing documentation to building modules to promoting best practices. Join the Drupal AI Marketing Weekly to pitch in.

“Most important, we are here to listen to your feedback.” - Baddy Breidert

How To Get Involved

All the slides from the session are available here. You’ll also find handy links:

What Can You Do Next?

  • Join the conversation: Hop into the AI issue queue, Slack channels, or reach out to the working group.

  • Stay tuned: More sessions, training, and contribution sprints are on the way, including the Drupal GovCon AI training and hack-a-thon later this year.

This initiative will only succeed if it’s shaped by the whole community. If you care about building a safe, open, and innovative Drupal AI ecosystem. Your input matters.

“Please stay tuned for the upcoming webinars and upcoming news.” - Lenny Moskalyk

And See you next time!

LN Webworks: Custom Marketplace for Your Next Big Project

Image removed.

Introduction

The ecommerce industry is already undergoing a new revolution with marketplaces helping the customers to discover a variety of sellers which they can access on a single platform.

Approximately 30 percent of the total purchase orders on the internet across the world are made via online market platforms

And that is the nutshell actually; why not take a chance when your brain child could be the next disruptor!

DrupalCon News & Updates: DrupalCon Vienna 2025: A Journey Through Drupal’s Past, Present, and Future

In 2025, Drupal continues to evolve as a powerful, open-source content management framework that balances flexibility, scalability, and extensibility. As we prepare to gather in Vienna a city rich in both culture and innovation, this year's DrupalCon is more than a conference. It's a comprehensive reflection on how Drupal has matured over the years, where it stands today, and where it’s headed next.

Image removed.

 

Drupal’s Origins: Laying the Foundation for Open Web Platforms

Drupal began as a simple message board over two decades ago, yet its architecture was built on a vision of extensibility and community collaboration. What started as a hobby project grew into a full-fledged CMS adopted by developers, governments, universities, and enterprises around the globe.

From the early introduction of modules and hooks to the groundbreaking adoption of Symfony components and modern PHP standards, Drupal's architecture has consistently prioritized maintainability and reusability. The rise of the Form API, Entity API, and Configuration Management System laid the groundwork for scalable content-driven applications.

Key innovations in the early years:

  • Introduction of a modular system enabling rapid extension of core functionality

     
  • The evolution from procedural to object-oriented code structures

     
  • Strong community governance and open contribution models

     

These early decisions positioned Drupal as a future-ready framework long before terms like "composable DXP" or "headless CMS" entered the mainstream.

 

Drupal Today: Engineered for Modern Digital Operations

In 2025, Drupal is no longer just a CMS, it's a backend digital experience engine that powers mission-critical applications across sectors. Its flexibility has enabled it to adapt to a changing landscape of decoupled front ends, API integrations, and marketing automation.

Technical highlights of Drupal today:

  • API-First Design: Drupal 10 and 11 offer robust REST, JSON:API, and GraphQL support out-of-the-box, making integration with JavaScript frameworks and external services seamless.

     
  • Advanced Content Modeling: With custom entities, paragraphs, taxonomy systems, and fieldable content types, teams can represent structured and reusable data at any scale.

     
  • Decoupled and Progressive Decoupling: From fully headless implementations to progressively enhanced Twig-based front ends, Drupal supports a spectrum of architectural patterns.

     
  • Multisite + Multilingual: Multisite capabilities combined with flexible language modules enable the deployment of global, multi-brand, and localized content ecosystems.

     

Industry Applications:

  • Government: Role-based access control, WCAG compliance, multilingual content management, and enterprise security protocols are supported natively, making Drupal ideal for secure and accessible government portals.

     
  • Enterprise Marketing: Marketers and developers benefit from multisite capabilities, flexible editorial workflows, and seamless integration with CRM, DAM, and analytics tools — all critical for omnichannel delivery.

     
  • Education & eLearning: Institutions leverage Drupal as the core CMS for AI-assisted platforms that recommend content, track learning progress, and personalize student engagement through decoupled UIs and custom APIs.

     

This modular and composable architecture enables Drupal to function not only as a website builder but also as the integration layer between diverse enterprise systems.

 

Looking Ahead: Drupal’s Technical Roadmap

As we look beyond Drupal 10 and 11, the project continues to invest in modernization and developer experience. The core roadmap emphasizes:

  • Enhanced Admin UI: React-based administrative themes and improved UX for non-technical users

     
  • Automatic Updates: Secure and stable auto-updates for core and contributed modules

     
  • Project Browser: A visual interface to discover, install, and evaluate contributed modules from within the admin UI

     
  • Better Decoupling Support: Continued investment in GraphQL schemas, real-time data synchronization, and rendering decoupled menus/navigation

     
  • Developer Tooling: Improved DX through Composer support, API stabilization, and increased PHP type safety

     

Community initiatives such as GitLab CI/CD integration, increased test coverage, and standardization around frontend tooling (Webpack, Vite, etc.) are also helping push Drupal closer to being a developer-first platform without sacrificing editorial ease-of-use.

 

 Join the Evolution in Vienna

DrupalCon Vienna 2025 offers a rare opportunity to immerse yourself in the full journey of Drupal from its humble origins to its role in powering complex, enterprise-grade applications. Whether you're a backend architect, frontend engineer, digital strategist, or platform lead, there’s something for everyone.

What to expect:

  • Sessions from core maintainers and initiative leads

     
  • Hands-on workshops for developers transitioning to decoupled and API-first builds

     
  • Real-world architecture case studies from large-scale Drupal implementations

     
  • Opportunities to contribute to the Drupal project and shape its future

     

 Why It Matters

In a world where digital transformation is no longer optional, Drupal continues to prove its value by being adaptable, secure, and deeply rooted in the principles of open collaboration. Its future depends not just on the technology, but on the people contributors, builders, and thinkers who continue to push the platform forward.

At DrupalCon Vienna 2025, you won’t just learn about where Drupal has been. You’ll help shape where it’s going next.

Mark Your Calendars

🗓️ Dates: October 14–17, 2025
 📍 Location: Austria Center Vienna, Vienna, Austria
 🌐 Official Website & Registration: https://events.drupal.org/vienna2025/registration-information
 🐦 Follow the buzz: #DrupalConVienna #DrupalCon2025

Stay Tuned!

This blog is just the beginning. Over the next few weeks, I’ll be sharing:

  • Technical spotlights on Drupal CMS features
  • Speaker highlights and session previews
  • Tips for first-time technical attendees and contributors

     

So bookmark this space, and get ready to experience DrupalCon Vienna 2025 like never before.

Are you coming? Let’s connect!

 

By Iwantha Lekamge

Technical Lead
WSO2

joshics.in: Drupal 11 Dev Environments: DDEV, LAMP, and Beyond

Drupal 11 Dev Environments: DDEV, LAMP, and Beyond bhavinhjoshi Wed, 07/02/2025 - 15:52

Exploring DDEV, LAMP, and Local Server for Drupal 11

Image removed.

Drupal 11 offers API-first features and enhanced performance, making the choice of development environment critical.

I’ve worked with DDEV, LAMP, and Local Server setups like XAMPP or MAMP to assess their strengths.

This guide delivers a detailed breakdown with setup instructions, configuration options, practical examples, and a comparison table, serving as a resource to match your project needs.

Understanding Your Options

A solid development environment is essential for Drupal 11 projects. The sections below provide in-depth details on DDEV, LAMP, and Local Server, based on my hands-on experience.

DDEV

DDEV is the official local development tool for Drupal, built on Docker and supported by the community, with documentation at https://www.drupal.org/docs/official_docs/local-development-guide.

  • Setup Process: Install Docker from docker.com following OS-specific instructions (download and CLI setup), create a Drupal project with composer create-project drupal/recommended-project my-site navigate to the directory with cd my-site initialize with ddev config (set docroot to "web" and PHP version, e.g., 8.1), start with ddev start.
  • Configuration Options: Edit .ddev/config.yaml to add custom domains, multiple databases, or integrate tools like MailHog for email testing, adjust PHP versions or enable extensions via the YAML file.
  • Practical Applications: Used on a 12-site project, configuring custom domains and databases in the YAML file, added SSL for local development to mirror production.
  • Considerations: Requires learning Docker basics (a few hours), needs 4GB RAM minimum (8GB recommended), configuration changes may need community forum support.

Try tweaking config.yaml to set PHP versions, enable Xdebug for debugging, or add services like Redis based on your project requirements.

LAMP

LAMP, made up of Linux, Apache, MySQL, and PHP, is a traditional stack offering detailed control, widely used for Drupal development.

  • Setup Process: Use a Linux distro like Ubuntu, update the system and install Apache with sudo apt update && sudo apt install apache2, install MySQL with sudo apt install mysql-server and secure it with mysql_secure_installation install PHP 8.1+ and modules with sudo apt install php8.1 php8.1-mysql php8.1-cli php8.1-mbstring.
  • Configuration Options: Create a virtual host file (e.g., /etc/apache2/sites-available/drupal.conf) with DocumentRoot set to your Drupal directory, enable it with sudo a2ensite drupal.conf restart Apache with sudo systemctl restart apache2 tweak .htaccess or MySQL settings for performance.
  • Practical Applications: Built a small news site, optimizing .htaccess for caching and MySQL queries, required manual load balancing as traffic hit 600 users daily.
  • Considerations: Setup can take a day due to dependency issues, updates and security patches are manual, scaling needs additional infrastructure like reverse proxies.

Consider adding phpMyAdmin for database management and Drush 12 for automating tasks like cache clears or module updates.

Local Server (XAMPP, MAMP)

XAMPP and MAMP provide a pre-configured bundle of Apache, MySQL, and PHP, ideal for quick local development, especially for beginners.

  • Setup Process: Download XAMPP from xampp.org or MAMP from mamp.info, run the installer for your OS (Windows, macOS, Linux), start Apache and MySQL via the control panel, place Drupal 11 files in htdocs (XAMPP) or htdocs (MAMP) and access at http://localhost (15-20 minutes total).
  • Configuration Options: Adjust ports (e.g., Apache to 8080) in the control panel if conflicts occur, enable PHP extensions like mysqli or gd through the configuration interface.
  • Practical Applications: Prototyped a client portfolio site in under an hour, required port changes for a second site, showing limits with multiple projects.
  • Considerations: Not suited for large sites (lag with 50+ pages), port conflicts possible with other apps, requires at least 2GB RAM, with older hardware struggling over time.

Check the control panel for port adjustments and review PHP error logs (in htdocs/logs) to troubleshoot setup issues.

Comparison Overview

This table compares DDEV, LAMP, and Local Server across key development factors based on observed performance.

Aspect DDEV LAMP Local Server (XAMPP/MAMP) Ease of Setup Moderate (Docker required) Complex (manual configuration) Easy (pre-configured) Scalability High (multi-site support) Moderate (requires tuning) Low (best for small projects) Performance High (optimized environment) Variable (depends on tuning) Moderate (basic setup) Community Support Strong (open-source community) Good (widely documented) Limited (vendor support) Resource Requirements High (Docker overhead) Low (minimal base setup) Medium (bundled components)

Key Considerations

  • Ensure PHP 8.1+ is active—verify with php -v.
  • Keep Composer current—run composer update regularly.
  • Always back up before changes—use drush archive-dump to save your work.

DDEV, LAMP, and Local Server each bring unique capabilities to Drupal 11 development, from community-driven consistency to hands-on control or rapid setup. This guide aims to equip you with the knowledge to choose what fits your goals. Take your time to assess your project’s scale, team needs, and resource availability—your decision will shape the foundation of your work.

Drupal 11 DDEV LAMP Drupal Planet

Share this

Copied to clipboard

Add new comment