Colan Schwartz: Want to Run Drupal in Kubernetes? Try Our New Terraform Module
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:
- send requests from customers to provision services,
- configure customer accounts, and
- 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:
- Bitnami’s Helm chart (no longer supported as of 2021)
- Jeff Geerling’s Drupal Operator (no longer supported as of early 2025)
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.
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
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:
- Zero Docker config:
ddev start
replaces hand‑rolled Compose files. - No central registry maintenance: Images build locally.
- Host‑level commands:
ddev drush status
orddev composer install
withoutdocker exec
. - Unified file system: The code lives on the host, eliminating copy‑in/out cycles.
- Safe rebuilds: Deleting containers never loses work.
- Always‑on Git:
blame
,diff
, andbranch
with the active code without stepping into the container. - 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
DDEV Blog: Using FrankenPHP with DDEV
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 thefrankenphp
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
- FrankenPHP documentation
- DDEV's generic web server
- FrankenPHP add-on
- FrankenPHP quickstart
- Hola FrankenPHP! Laravel Octane Servers Comparison: Pushing the Boundaries of Performance
Benchmarking
Using ddev-frankenphp-benchmark, I compared three setups:
nginx-fpm
: DDEV'snginx-fpm
web server withphp-fpm
generic-web
: DDEV'sgeneric
web server with FrankenPHP inside theweb
container (static binary)generic-addon
: DDEV'sgeneric
web server with FrankenPHP inside thefrankenphp
container (withpdo_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)
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
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?
-
Watch the recording: Welcome to the Drupal AI Initiative
-
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
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.
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!
Technical Lead
WSO2
Specbee: Is your SEO strategy missing AEO and GEO? Here’s how to keep up
joshics.in: Drupal 11 Dev Environments: DDEV, LAMP, and Beyond
Exploring DDEV, LAMP, and Local Server for Drupal 11
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 withcd my-site
initialize withddev config
(set docroot to "web" and PHP version, e.g., 8.1), start withddev 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 withsudo apt install mysql-server
and secure it withmysql_secure_installation
install PHP 8.1+ and modules withsudo 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 withsudo 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