Images are the heart of any website’s design — they tell stories, capture attention, and shape the user experience. But to make a real impact, they need to be polished, properly formatted, and optimized for both aesthetics and performance.
It's been almost 5 years since Apple introduced its ARM64-based Macs, and the world has loved them. But they threw a complete monkey wrench into the software works, which had expected the Intel/AMD64 architecture for many, many years. (Read more: ARM64! Apple Silicon! M-Series! DDEV! What does it all mean?)
Almost all systems that distributed binary artifacts had extensive troubles. That included compiled binaries, Docker images, libraries, etc. In some cases the problem was just the fundamental assumptions in the software.
Apple released Rosetta 2 with the initial Apple Silicon macs, and it was great for simple situations, but it was initially quite unpredictable for Docker-based applications. You may know that I resisted any use of Rosetta for some years because of initial experiences of unpredictability. However, everything has gotten better around Rosetta over the years, but more than that, almost everything is available as a native app or native Docker image these days (and that has always included all DDEV apps and Docker images, from the very beginning).
But it doesn't include everything. Microsoft continues to publish AMD64-only binaries and Docker images, and Oracle is just as guilty. Surely they'll come around.
In the meantime, here are some techniques to get niche AMD64-only applications going with DDEV. I recommend these techniques only if you have no good alternative, because native performance and reliability are much higher.
platform: linux/amd64 if only AMD64 Docker images are availableplatform: linux/amd64 if you absolutely must install AMD64-only software in there (this happens most often with npm packages).linux/amd64There are still a few Docker images that have not been properly updated to multi-platform builds, including typo3solr and mssql/server.
With these, if you have a docker-compose.*.yaml file that names an image which is only available as AMD64, you can just add to it this line:
platform: linux/amd64
And if you're using a Docker provider like Orbstack or Docker Desktop that has robust Rosetta support (and you have Rosetta enabled) then it will "just work". It will have reduced performance, but it may work just fine for your application.
I recently added this setup to the ddev-sqlsrv DDEV add-on, which previously was limited to Intel users only. Adding these lines to the service's docker-compose.sqlsrv.yaml made the add-on work fine on Apple Silicon:
# On macOS Apple Silicon, this only works with Rosetta enabled
image: ${MSSQL_DOCKER_IMAGE:-mcr.microsoft.com/mssql/server:2022-CU18-ubuntu-22.04}
platform: linux/amd64
Sometimes the problem is adding software that is Intel-specific to the DDEV web container. For example, the classic npm packages node-sass and puppeteer had this problem for years. (Now both seem to build somewhat successfully on ARM64 and they also have clear "no-longer-maintained" notices sending you to other packages.)
However, as I recently experience with Oracle client-side ddev-oci8 DDEV add-on, you can make the DDEV web container run as linux/amd64 in the same exact way, and then if you need to npm-install some odd package that is Intel-only, you can do it. Add a .ddev/docker-compose.amd64.yaml like this:
services:
web:
# Force the DDEV web image to run as `linux/amd64` on Apple Silicon with Rosetta
platform: linux/amd64
As well as those techniques work, it seems unlikely that you'd want to run everything as AMD64, but DDEV on Intel... on Apple Silicon tells you how!
I don't recommend using either of these techniques if you have the option of updating to native software or images, but they're pretty nice if you can't!
Do you have specific examples of Intel-focused software or images that you've had trouble with? I'd love to hear about it, and hear your solutions. I'd love to update this article with more specific examples.
I'd love to hear your experience. Join us in Discord or open an issue or send an email if you have success (or failure 😀).
Thanks for your support and engagement with DDEV!
Welcome to the last article in the series. Today, we’ll wrap up by covering how to debug migrations, performance considerations, and the importance of checking your site for broken links before launch. We’ll also briefly discuss migrating into Drupal CMS and using AI to assist with the migration process.
mauricio Tue, 04/15/2025 - 06:24Dear Readers,
Open-source communities depend on more than just code. They rely on discussion, disagreement, and collaboration to shape projects' progress. In Drupal, dialogue is the anatomy of every decision. When the stakes are high or the path isn’t apparent, the process often begins with people asking questions, sharing use cases, and voicing concerns. DrupalCon Atlanta is in the books, but one update by Dries Buytaert is just getting started. During the Driesnote, Dries officially announced the launch of the Drupal Marketplace Initiative. Think of it as shelf space for the community’s best work, not just a place to download themes but a real way to explore, test, and launch starter sites confidently.
Marketplace Initiative is a clear example of an approach through dialogues. It's a proposal with practical goals but also a test of how Drupal makes decisions as a community. The core idea is to build a public marketplace for Drupal site templates, giving users easier ways to get started while making real examples of Drupal's capabilities more visible. The proposal includes both free and commercial templates. That last part has sparked debate, not because it's technically difficult, but because it touches on long-standing questions about values, equity, and direction.
Rather than settle those questions behind closed doors, the initiative is designed to gather input from across the Drupal ecosystem. It’s about how decisions get made in a project that serves many users with different needs. Whether you're excited about the potential or cautious about the trade-offs, this is the right time to speak up, and what comes next will be shaped by the people who show up now.
Right now, there are multiple ways to get involved. The working group has opened a Slack channel #drupal-cms-marketplace where you can jump into discussions, share ideas, and react to ongoing prompts. They’ve also released the first in a series of community surveys, starting with one focused on contributors, agencies, and Drupal Certified Partners. There are live community sessions planned too, open to anyone who wants to help shape how this all unfolds.
Dries didn’t take a side but made the case for a conversation. Many organizations already pay for templates off-platform through agencies or contractors. Bringing that activity into the open could create better options, reward contributors, and strengthen the ecosystem. But it also raises questions about fairness, values, and long-term sustainability. Those questions are now on the table; everyone is invited to weigh in.
This is how decisions happen in Drupal: not with final announcements but with open discussions that invite more people into the room. Dialogue remains the structure we build on. With that, let's move on to the important stories from last week.
We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now.
To get timely updates, follow us on LinkedIn, Twitter and Facebook. You can also join us on Drupal Slack at #thedroptimes.
Thank you,
Sincerely
Alka Elizabeth
Sub-editor, The DropTimes.
Open source, sometimes you keep up with the notifications, and sometimes the notifications keep up with you.
Drupal 11.2 alpha phase begins May 7
In preparation for the minor release, Drupal 11.2.x will enter the alpha phase the week of May 7, 2025. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release.
The 11.2.0-alpha1 deadline for most core patches is May 7, 2025.
The 10.6.x release branch of core will be created for the next maintenance minor release.
Developers and site owners can begin testing the alpha after its release.
The 11.2.x release branch of core will be created before the alpha is tagged. Future feature and API additions will continue to be targeted against the main development branch, 11.x.
After 11.2.x is branched but before 11.2.0-alpha1 is tagged, alpha experimental modules will be removed from the 11.2.x codebase. Their development will continue in 11.x only.
Following the release of Drupal 11.2 and 10.5, only security issues will be fixed in Drupal 11.1 and 10.4. Additionally, Drupal 11.0 and 10.3 will become end-of-life (EOL).
During the alpha phase, core issues will be committed according to the following policy:
Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Once the beta commit freeze begins, issues in the Reviewed & Tested by the Community (RTBC) queue will be committed to the next minor release only.
The release candidate phase will begin the week of June 2.
See the Drupal core release process overview, the Drupal core release schedule, allowed changes during the Drupal 10 and 11 release cycles, and Drupal 10 and 11 backwards compatibility and internal API policy for more information.