coder.ddev.com is a free, experimental cloud DDEV service. You log in with GitHub, create a workspace, and get a full DDEV environment in the cloud — no local Docker, no local installation needed.
\n:::warning[Experimental Service]\nThis is an experimental service with no guarantees of data retention, uptime, or long-term availability. The future of its maintenance and sustainability is uncertain. Do not store irreplaceable work here without pushing it to Git. Treat it as a convenience, not a platform to depend on.\n:::
\nWant a quick overview? Watch the 6-minute intro video starting from the very beginning:
\ncoder.ddev.com runs on Coder, an open-source platform for remote development environments. Each workspace is an isolated container (using the Sysbox runtime for secure Docker-in-Docker) with DDEV, Docker, and VS Code pre-installed.
\nYour files persist on a remote volume across workspace restarts. When you delete a workspace, the data is gone — so push your work to Git before deleting. But until you delete the workspace, or it's garbage-collected (not yet implemented), your work persists..
\nThe source code for the templates and Docker image is at github.com/ddev/coder-ddev. Other projects can use this and deploy their own fully-DDEV-capable Coder instances.
\nGo to coder.ddev.com and click Login with GitHub. No separate account needed. coder.ddev.com receives read-only access to your email addresses, public profile, and GitHub organization membership — no code access, no write access.
From the dashboard, click Create Workspace and choose a template:
\nGive your workspace a name and click Create Workspace. Most workspaces start in under a minute. The drupal-core template (with seed cache) is ready in about 30 seconds.
\nOnce running, you have several options to use your workspace:
\ncoder.ddev.com, use the many options, including web-based terminal, VS Code for Web, and VS Code Desktop.coder CLI: Install the Coder CLI, then coder login https://coder.ddev.com and coder ssh <workspace-name>.The drupal-core template sets up a complete Drupal core contribution environment automatically using joachim-n/drupal-core-development-project. Drupal core is cloned, Composer dependencies are installed, and a demo site is installed — all in about 30 seconds when a seed cache is available.
\nChoose your Drupal version when creating the workspace:
\nThe template automatically selects the correct PHP version and DDEV project type for the chosen branch.
\nLog in to the site with admin / admin.
This takes less than 4 minutes, try it out:
\nThe freeform template adds Traefik routing integration so your DDEV project and services like Mailpit get stable subdomain URLs (no port numbers). After creating a workspace, run ddev coder-setup once in your project directory, then ddev start. Routing updates automatically on every start.
One of the most useful features for Drupal contributors is the Drupal Issue Picker at start.coder.ddev.com/drupal-issue.
\n\nPaste any drupal.org issue URL (for example, https://www.drupal.org/project/drupal/issues/3568144) and the picker launches a drupal-core workspace with:
This replaces the workflow that DrupalPod (Gitpod-based) provided for contribution days. You can hand someone an issue URL, they paste it into the picker, and within 30 seconds they have a working environment with the issue branch ready.
\nDemonstrating this from start to finish in about 6 minutes:
\n\"VS Code Web\" runs in the browser and supports most extensions. You can install extensions from the marketplace, configure settings, and use the integrated terminal — all without installing anything locally.
\nClicking on \"VS Code Desktop\" opens up your local installation of VS Code and then automatically uses the Remote-SSH extension to connect to your Coder workspace. It's nice, I used it a lot in preparing this blog and even in some recent work on Coder.ddev.com itself. All VS Code features work.
\nXdebug works in Coder workspaces the same way as local DDEV with the DDEV VS Code Extension.
\nThe Coder CLI provides SSH access, port forwarding, file transfer, and workspace management. It's a completely different way of interacting with your workspace. Install with brew install coder or other options.
# Login\ncoder login https://coder.ddev.com\n\n# List workspaces\ncoder list\n\n# SSH into workspace\ncoder ssh my-workspace\n\n# Forward a port locally\ncoder port-forward my-workspace --tcp 8080:80\n\n# Stop workspace (preserves data)\ncoder stop my-workspace\nBecause DDEV runs inside a cloud container, the usual *.ddev.site URLs don't work. Instead, access your project via the DDEV Web app link in the Coder dashboard, or use port forwarding, and ddev start, ddev launch and ddev describe also give URL information.
The freeform template handles this automatically with Traefik routing — you get stable subdomain URLs like https://<workspace>--<workspace>--<owner>.coder.ddev.com/.
Stop: Stops the container and frees compute resources. All files in /home/coder are preserved. Use this when you are done for the day.
Delete: Permanently removes the workspace and all data. Always push your code to Git before deleting.
\nThis can also be done from the command-line on your local machine (after coder login https://coder.ddev.com):
coder list\ncoder stop my-workspace # Stop (data preserved)\ncoder delete my-workspace # Delete (data lost permanently)\nUse the coder publickey command to get the publickey associated with your coder.ddev.com projects (it's the same for all projects). You can then add that to GitHub/GitLab/Drupalcode/Remote SSH to allow you to access those resources.
The full details are in the repository at github.com/ddev/coder-ddev.
\nThis is running on a 64GB Hetzner bare-metal Ubuntu 24.04 machine in Helsinki, Finland. It has lots of disk and costs about $50/month.
\nThe world of open source is amazing. Coder.com is a shockingly mature project, and so many of these things worked just great out of the box.
\nThe templates and image are open source at github.com/ddev/coder-ddev. Contributions, bug reports, and feature requests are welcome.
\n#support-and-discussion channelDDEV v1.25.1 introduced validation that checks for Docker Buildx, and you may encounter an error when running ddev start if your system isn't configured correctly. This post explains why this dependency exists, who's affected, and how to resolve it. Note that DDEV v1.25.2 will bundle a private Docker Buildx to eliminate this configuration requirement.
Most users won't need to do anything. Docker Desktop, OrbStack, and Rancher Desktop bundle Docker Buildx automatically.
\nYou may need to take action if you're using:
\nIf you're running Docker Desktop, OrbStack, or Rancher Desktop, you can skip this article.
\nWhen running ddev start on DDEV v1.25.1 without a compatible Buildx version, you'll see:
$ ddev start\nDocker buildx check failed: compose build requires buildx 0.17.0 or later: docker CLI plugin \"buildx\" not found.\nPlease install buildx: https://github.com/docker/buildx#installing\nOr if Buildx is installed but doesn't match the required version:
\n$ ddev start\nDocker buildx check failed: compose build requires buildx 0.17.0 or later.\nInstalled docker buildx: 0.13.1 (plugin path: /usr/lib/docker/cli-plugins/docker-buildx)\nPlease update buildx: https://github.com/docker/buildx#installing\nThis is an upstream dependency from Docker Compose, not a DDEV-specific choice.
\nHere's how we got here:
\nThe requirement comes from Docker Compose itself. DDEV now validates your system configuration to prevent confusing build failures.
\nInstall Docker Buildx via Homebrew:
\nbrew install docker-buildx\nAfter installation, configure Docker to find the plugin. Add cliPluginsExtraDirs to $HOME/.docker/config.json:
{\n \"cliPluginsExtraDirs\": [\"/opt/homebrew/lib/docker/cli-plugins\"]\n}\nYou can see this information anytime with:
\nbrew info docker-buildx\nThe post-install messages from Homebrew will show you the exact path for your system.
\nDebian 13 (Trixie) includes Docker Buildx v0.13.1 from the Debian repositories, which doesn't meet the ≥0.17.0 requirement.
\nSolution: Switch to Docker from the official Docker repositories.
\nddev snapshot -a.The official Docker repositories provide current versions of all Docker components including Docker Buildx ≥0.17.0.
\nNixOS users should track DDEV issue #8183. A NixOS patch is available - once merged, you'll get the fix through normal system updates without manual intervention.
\nIf the platform-specific solutions above don't work, you can manually place the docker-buildx binary in one of Docker's expected plugin directories:
Linux/macOS:
\n$HOME/.docker/cli-plugins//usr/local/lib/docker/cli-plugins//usr/local/libexec/docker/cli-plugins//usr/lib/docker/cli-plugins//usr/libexec/docker/cli-plugins/Traditional Windows (not needed for WSL2):
\n%USERPROFILE%\\.docker\\cli-plugins\\%ProgramFiles%\\Docker\\cli-plugins\\See Docker's plugin manager source for Linux/macOS and Windows for the complete list.
\nAlternatively, place the binary anywhere and configure Docker to find it by adding cliPluginsExtraDirs to $HOME/.docker/config.json (or %USERPROFILE%\\.docker\\config.json on Windows):
{\n \"cliPluginsExtraDirs\": [\"/path/to/your/custom/plugin/directory\"]\n}\nWe're working to make this smoother in upcoming releases:
\nDDEV v1.25.2 (upcoming) will likely bundle a private Docker Buildx that DDEV uses exclusively. This eliminates the system configuration requirement for most users. I'm working on this in PR #8198.
\nFuture releases will transition from our private Docker Compose binary to the Docker Compose SDK. This gives DDEV more control over upstream dependencies and reduces configuration complexity.
\nIf you're still seeing issues after following these steps, reach out in any of the support channels.
\nThis article was edited and refined with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/ddev-ci-warpbuild","url":"https://ddev.com/blog/ddev-ci-warpbuild","title":"Using WarpBuild to speed up DDEV in CI","content_html":"For most developers, DDEV solves a common challenge: making sure that each developer has a consistent, stable local environment for building their web application. We had more and more success with DDEV at Lullabot, but another related issue kept coming up: how do we grow and develop our use of continuous integration and automated testing while avoiding the same challenges DDEV solved for us?
\nA typical CI/CD pipeline is implemented using the tools and systems provided by the CI service itself. For example, at a basic level you can place shell commands inside configuration files to run tests and tools. Running those commands locally in DDEV is possible, but it's a painful copy/paste process. If you're a back-end or DevOps engineer, odds are high you've wasted hours trying to figure out why a test you wrote locally isn't passing in CI – or vice versa!
\nAs a first step, we used Task to improve our velocity. Having a unified task runner that works outside PHP lets us standardize CI tasks more easily. However, this still left a big surface area for differences between local and CI environments. For example, in GitHub, the shivammathur/setup-php action is used to install PHP and extensions, but the action is not identical to DDEV. Underlying system libraries and packages installed with apt-get could also be different, causing unexpected issues. Finally, there was often a lag in detecting when local test environments broke because those changes weren't tested in CI.
This brought us to using DDEV for CI. It's a great solution! Running all of our builds and tasks in CI solved nearly every \"it works on my machine\" problem we had. However, it introduced a new challenge: CI startup performance.
\nUnlike using a CI-provider's built-in tooling, DDEV is not typically cached or included in CI runners. Just running the setup-ddev action can take up to a minute on a bad day. That doesn't include any additional packages or Dockerfile customizations a project may include. At Lullabot, we use ddev-playwright to run end-to-end tests. Browser engines and their dependencies are heavy! System dependencies can be north of 1GB of compressed packages (that then have to be installed), and browsers themselves can be several hundred MB. This was adding several minutes of setup time just to run a single test.
\nLuckily, based on our experience building Tugboat, we knew that the technology to improve startup performance existed. When WarpBuild was announced with Snapshot support in 2024, we immediately started testing it out. We theorized that the performance improvement of snapshots would result in significant startup time improvement. Here's how we set it up!
\nWe had three parallel jobs that all required DDEV:
\nNote that our Playwright tests themselves run in parallel on a single worker as well, using lullabot/playwright-drupal. This allows us to optimize the additional startup time for installing Drupal itself (which can't be cached in a snapshot) across many tests.
\nAfter linking WarpBuild to our GitHub repository, we had to update our workflows. For the full combined example, see the repository at ddev/ddev-ci-warpbuild-example.
\nHere is an example representing the changes we made to our workflow after enabling Snapshots in the WarpBuild UI. At a high level, here's the flow we want to create with our GitHub jobs:
\nflowchart TD\n A[determine-snapshot: <br>Hash key files] --> B[Request WarpBuild runner<br>with snapshot key]\n B --> C{Snapshot exists?}\n C -->|\"Yes (fast path)\"| D[Restore snapshot<br>DDEV pre-installed]\n C -->|\"No (first run)\"| E[Install DDEV, browsers,<br>and dependencies]\n D --> F[Start DDEV & run tests]\n E --> F\n F --> G{First run?}\n G -->|Yes| H[Clean up & save snapshot]\n G -->|No| I[Done!]\n H --> I\nStart with a basic workflow to trigger on pull requests and on merges to main.
name: \"WarpBuild Snapshot Example\"\n\non:\n push:\n branches: [main]\n pull_request:\nBefore running our real work, we need to know what snapshot we could restore from. We start by creating a hash of key files that affect what gets saved in the snapshot. For example, if Playwright (and its browser and system dependencies) are upgraded by Renovate, we want a new snapshot to be created. Extend or modify these files to match your own project setup.
\njobs:\n determine-snapshot:\n # This could be a WarpBuild runner too!\n runs-on: ubuntu-24.04\n outputs:\n snapshot: ${{ steps.snapshot-base.outputs.snapshot }}\n steps:\n - uses: actions/checkout@v6\n\n - name: Determine Snapshot Base\n id: snapshot-base\n run: |\n set -x\n hash=$(cat .github/workflows/test.yml test/playwright/.yarnrc.yml test/playwright/yarn.lock | md5sum | cut -c 1-8)\n echo \"snapshot=$hash\" >> $GITHUB_OUTPUT\n shell: bash\nWarpBuild needs some additional configuration to tell GitHub Actions to use it as a runner. This could be as simple as runs-on: 'warp-<runner-type>' if you aren't using snapshots. WarpBuild has many runner options available, including ARM and spot instances to reduce costs further.
The runs-on statement:
\nWe also switch to the WarpBuild cache (so it's local to the runner) and check out the project. Update the cache paths as appropriate for your project.
\njobs:\n # other jobs...\n build-and-test:\n needs: [determine-snapshot]\n runs-on:\n \"${{ contains(github.event.head_commit.message, '[warp-no-snapshot]') &&\n 'warp-ubuntu-2404-x64-16x' ||\n format('warp-ubuntu-2404-x64-16x;snapshot.key=my-project-ddev-1.25.1-v1-{0}', needs.determine-snapshot.outputs.snapshot) }}\"\n\n steps:\n - uses: WarpBuilds/cache@v1\n with:\n path: |\n ${{ github.workspace }}/.ddev/.drainpipe-composer-cache\n ${{ github.workspace }}/vendor\n ${{ github.workspace }}/web/core\n ${{ github.workspace }}/web/modules/contrib\n key: ${{ runner.os }}-composer-full-${{ hashFiles('**/composer.lock') }}\n\n - uses: actions/checkout@v6\nWe need to add logic to either start from scratch and install everything or restore from a snapshot. Since DDEV isn't installed by default in runners, we can use its presence to easily determine if we're running from inside a snapshot or not. We save these values for later use.
\njobs:\n # other jobs...\n build-and-test:\n steps:\n # ... previous steps ...\n - name: Find ddev\n id: find-ddev\n run: |\n DDEV_PATH=$(which ddev) || DDEV_PATH=''\n echo \"ddev-path=$DDEV_PATH\" >> \"$GITHUB_OUTPUT\"\n if [ -n \"$DDEV_PATH\" ]; then\n echo \"ddev found at: $DDEV_PATH (restored from snapshot)\"\n else\n echo \"ddev not found (fresh runner, will install)\"\n fi\nIf ddev exists, we can skip installing it:
\njobs:\n # other jobs...\n build-and-test:\n steps:\n # ... previous steps ...\n - name: Install ddev\n uses: ddev/github-action-setup-ddev@v1\n if: ${{ steps.find-ddev.outputs.ddev-path != '/usr/bin/ddev' }}\n with:\n autostart: false\n # When updating this version, also update the snapshot key above\n version: 1.25.1\nAt this point, we've got DDEV ready to go, so we can start it and run tests or anything else.
\njobs:\n # other jobs...\n build-and-test:\n steps:\n # ... previous steps ...\n - name: Start ddev\n run: |\n # Playwright users may want to run `ddev install-playwright` here.\n ddev start\n ddev describe\n\n - name: Run tests\n run: |\n ddev exec echo \"Running tests...\"\n # Replace this with one or more test commands for your project.\n ddev task test:playwright\nNow, tests have passed and we can create a snapshot if needed. If tests fail, we never create a snapshot so that we don't accidentally commit a broken environment.
\nWe shut down DDEV since we're going to clean up generated files. This keeps our snapshot a bit smaller and gives us an opportunity to clean up any credentials that might be used as a part of the job. While we don't typically need a Pantheon token for tests, we do need it for some other jobs we run with DDEV.
\njobs:\n # other jobs...\n build-and-test:\n steps:\n # ... previous steps ...\n - name: Clean up for snapshot\n if: ${{ steps.find-ddev.outputs.ddev-path != '/usr/bin/ddev' }}\n run: |\n # Stop ddev to ensure clean state\n ddev poweroff\n # Remove any cached credentials or tokens\n rm -f ~/.terminus/cache/session\n # Clean git state and temporary files\n git clean -ffdx\nNow we can actually save the snapshot. We skip this if we can since it takes a bit of time to save and upload. There's no point in rewriting our snapshot if it hasn't changed! The wait-timeout-minutes is set very high, but in practice this step only takes a minute or two. We just don't want this step to fail if Amazon is slow.
jobs:\n # other jobs...\n build-and-test:\n steps:\n # ... previous steps ...\n - name: Save WarpBuild snapshot\n uses: WarpBuilds/snapshot-save@v1\n if: ${{ steps.find-ddev.outputs.ddev-path != '/usr/bin/ddev' }}\n # Using a matrix build? Avoid thrashing snapshots by only saving from one shard.\n # if: ${{ matrix.shard == 1 && steps.find-ddev.outputs.ddev-path != '/usr/bin/ddev'}}\n with:\n # Must match the snapshot.key in runs-on above\n alias: \"my-project-ddev-1.25.1-v1-${{ needs.determine-snapshot.outputs.snapshot }}\"\n fail-on-error: true\n wait-timeout-minutes: 30\nTo test, once you have jobs passing, you can rerun them from the GitHub Actions UI. If everything is working, you will see all steps related to installing DDEV skipped.
\nNote: We don't pin actions to hashes in these examples for easy copypaste, but for security we always use Renovate to pin hashes for us. We would also like to use Renovate Custom Managers to automatically offer DDEV upgrades and keep the version number in sync across all files and locations.
\nddev start command.While this seems like a lot of work, it was only about half a day to set up and test – and that was when WarpBuild was in beta, had minimal documentation and some rough edges. We haven't really had to touch this code since. Setting up new projects is an hour, at most.
\nDo you have other optimizations for DDEV in CI to share? Post in the comments, we'd love to hear them!
\n"},{"id":"https://ddev.com/blog/ddev-february-2026-newsletter","url":"https://ddev.com/blog/ddev-february-2026-newsletter","title":"DDEV February 2026: v1.25.0 Ships, 72% Market Share, and New Training Posts","content_html":"DDEV v1.25.0 is here, and the community response has been strong. This month also brought three new training blog posts and a survey result that speaks for itself.
\nddev share Provider System → Free Cloudflare Tunnel support, no login or token required. A modular provider system with hooks and CMS-specific configuration. Read more↗ddev utility mutagen-diagnose command. Read more↗ddev utility xdebug-diagnose command. Read more↗The 2026 CraftQuest Community Survey↗ collected responses from 253 Craft CMS developers and found DDEV at 72% market share for local development environments. The report notes: \"This near-standardization simplifies onboarding for newcomers, reduces support burden for plugin developers, and means the ecosystem can optimize tooling around a single local dev workflow.\"
\nI'll be at Florida Drupalcamp this week, and will speak on how to use git worktree to run multiple versions of the same site. I'd love to see you and sit down and hear your experience with DDEV and ways you think it could be better.
Then in March I'll be at DrupalCon Chicago and as usual will do lots of Birds-of-a-Feather sessions about DDEV and related topics. Catch me in the hall, or let's sit down and have a coffee.
\n\n\n\"I was today years old when I found out that DDEV exists. Now I am busy migrating all projects to Docker containers.\" — @themuellerman.bsky.social↗
\n
\n\n\"ddev is the reason I don't throw my laptop out of the window during local setup wars. one command to run the stack and forget the rest. simple as that.\" — @OMascatinho on X↗
\n
Every major release brings some friction, and v1.25.0 is no exception. These will generally be solved in v1.25.1, which will be out soon. Here's what to watch for:
\nddev start for users still on v1.24.10 who needed to rebuild containers. We pushed updated images for v1.24.10, so you can either ddev poweroff && ddev utility download-images or just go ahead and upgrade to v1.25.0, which shipped with the updated key. Details↗drush sql-cli and similar tools on MariaDB versions below 10.11. Workaround: add extra: \"--skip-ssl\" to your drush/drush.yml under command.sql.options, or upgrade your database to MariaDB 10.11+. Details↗.ddev/mysql/*.cnf doesn't work as expected. #8130↗ #8129↗*.ddev.site hostnames. Details↗~/.ddev/traefik/config — leftover v1.25.0 Traefik configuration breaks the older version. Details↗ddev start and ddev list, which looks alarming but is harmless. Details↗ddev npm and working_dir → ddev npm doesn't currently respect the working_dir web setting, a difference from v1.24.10. Details↗As always, please open an issue↗ if you run into trouble — it helps us fix things faster. You're the reason DDEV works so well!
\nJoin us for upcoming training sessions for contributors and users.
\nFebruary 26, 2026 at 10:00 US ET / 16:00 CET — Git bisect for fun and profit\nAdd to Google Calendar •\nDownload .ics
\nMarch 26, 2026 at 10:00 US ET / 15:00 CET — Using git worktree with DDEV projects and with DDEV itself\nAdd to Google Calendar •\nDownload .ics
April 23, 2026 at 10:00 US ET / 16:00 CEST — Creating, maintaining and testing add-ons\n2026-updated version of our popular add-on training. Previous session recording↗\nAdd to Google Calendar •\nDownload .ics
\nZoom Info:\nLink: Join Zoom Meeting\nPasscode: 12345
\nAfter the community rallied in January, sponsorship has held steady and ticked up slightly. Thank you!
\nPrevious status (January 2026): ~$8,208/month (68% of goal)
\nFebruary 2026: ~$8,422/month (70% of goal)
\nIf DDEV has helped your team, now is the time to give back. Whether you're an individual developer, an agency, or an organization — your contribution makes a difference. → Become a sponsor↗
\nContact us to discuss sponsorship options that work for your organization.
\nCompiled and edited with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/xdebug-step-debugging-understanding-and-troubleshooting","url":"https://ddev.com/blog/xdebug-step-debugging-understanding-and-troubleshooting","title":"Xdebug in DDEV: Understanding, Debugging, and Troubleshooting Step Debugging","content_html":"For most people, Xdebug step debugging in DDEV just works: ddev xdebug on, set a breakpoint, start your IDE's debug listener, and go. DDEV handles all the Docker networking automatically. If you're having trouble, run ddev utility xdebug-diagnose and ddev utility xdebug-diagnose --interactive — they check your configuration and connectivity and tells you exactly what to fix.
This post explains how the pieces fit together and what to do if things do go wrong.
\nddev xdebug onindex.php or web/index.php)If it doesn't work:
\nddev utility xdebug-diagnose\nOr for guided, step-by-step troubleshooting:
\nddev utility xdebug-diagnose --interactive\nThe diagnostic checks port 9003 listener status, host.docker.internal resolution, WSL2 configuration, xdebug_ide_location, network connectivity, and whether Xdebug is loaded. It gives actionable fix recommendations.
Xdebug lets you set breakpoints, step through code, and inspect variables — interactive debugging instead of var_dump().
The connection model is a reverse connection: your IDE listens on port 9003 (it's the TCP server), and PHP with Xdebug initiates the connection (it's the TCP client). Your IDE must be listening before PHP tries to connect.
\n:::note\nThe Xdebug documentation uses the opposite terminology, calling the IDE the \"client.\" We use standard TCP terminology here.\n:::
\nDDEV configures Xdebug to connect to host.docker.internal:9003. This special hostname resolves to the host machine's IP address from inside the container, so PHP can reach your IDE across the Docker boundary.
The tricky part is that host.docker.internal works differently across platforms. DDEV handles this automatically:
host.docker.internal nativelyYou can verify the resolution with:
\nddev exec getent hosts host.docker.internal\nddev xdebug on / off / toggle — Enable, disable, or toggle Xdebugddev xdebug status — Check if Xdebug is enabledddev xdebug info — Show configuration and connection detailsZero-configuration debugging works out of the box:
\nPhpStorm auto-detects the server and path mappings. If mappings are wrong, check Settings → PHP → Servers and verify /var/www/html maps to your project root.
The PhpStorm DDEV Integration plugin handles this automatically.
\nInstall the PHP Debug extension and create .vscode/launch.json:
{\n \"version\": \"0.2.0\",\n \"configurations\": [\n {\n \"name\": \"Listen for Xdebug\",\n \"type\": \"php\",\n \"request\": \"launch\",\n \"port\": 9003,\n \"hostname\": \"0.0.0.0\",\n \"pathMappings\": {\n \"/var/www/html\": \"${workspaceFolder}\"\n }\n }\n ]\n}\nThe VS Code DDEV Manager extension can set this up for you.
\nWSL2 + VS Code with WSL extension: Install the PHP Debug extension in WSL, not Windows.
\nMost problems fall into a few categories. The ddev utility xdebug-diagnose tool checks for all of these automatically.
Breakpoint in code that doesn't execute: The #1 issue. Start with a breakpoint in your entry point (index.php) to confirm Xdebug works, then move to the code you actually want to debug.
IDE not listening: Make sure you've started the debug listener. PhpStorm: click the phone icon. VS Code: press F5.
\nIncorrect path mappings: Xdebug reports container paths (/var/www/html), and your IDE needs to map them to your local project. PhpStorm usually auto-detects this; VS Code needs the pathMappings in launch.json.
Firewall blocking the connection: Especially common on WSL2, where Windows Defender Firewall blocks connections from the Docker container. Quick test: temporarily disable your firewall. If debugging works, add a firewall rule for port 9003.
\nWSL2 adds networking complexity. The most common problems:
\nWindows Defender Firewall blocks connections from WSL2 to Windows. Temporarily disable it to test; if debugging works, add a rule for port 9003.
\nMirrored mode requires hostAddressLoopback=true in C:\\Users\\<username>\\.wslconfig:
[experimental]\nhostAddressLoopback=true\nThen wsl --shutdown to apply.
IDE in WSL2 (VS Code + WSL extension): Set ddev config global --xdebug-ide-location=wsl2
Container-based IDEs (VS Code Remote Containers, JetBrains Gateway):
\nddev config global --xdebug-ide-location=container\nCommand-line debugging: Works the same way — ddev xdebug on, start your IDE listener, then ddev exec php myscript.php. Works for Drush, WP-CLI, Artisan, and any PHP executed in the container.
Debugging Composer: Composer disables Xdebug by default. Override with:
\nddev exec COMPOSER_ALLOW_XDEBUG=1 composer install\nCustom port: Create .ddev/php/xdebug_client_port.ini with xdebug.client_port=9000 (rarely needed).
Debugging host.docker.internal resolution: Run DDEV_DEBUG=true ddev start to see how DDEV determines the IP.
xdebugctl: DDEV includes the xdebugctl utility for dynamically querying and modifying Xdebug settings, switching modes (debug, profile, trace), and more. Run ddev exec xdebugctl --help. See the xdebugctl documentation.
Xdebug map feature: Recent Xdebug versions can remap file paths during debugging, useful when container paths don't match local paths in complex ways. This complements IDE path mappings.
\nPerformance: Xdebug adds overhead. Use ddev xdebug off or ddev xdebug toggle when you're not actively debugging.
Claude Code was used to create an initial draft for this blog, and for subsequent reviews.
\n"},{"id":"https://ddev.com/blog/mutagen-functionality-issues-debugging","url":"https://ddev.com/blog/mutagen-functionality-issues-debugging","title":"Mutagen in DDEV: Functionality, Issues, and Debugging","content_html":"Mutagen has been a part of DDEV for years, providing dramatic performance improvements for macOS and traditional Windows users. It's enabled by default on these platforms, but understanding how it works, what can go wrong, and how to debug issues is key to getting the most out of DDEV.
\nIf you're here because you just need to debug a Mutagen problem, this will probably help:
\nddev utility mutagen-diagnose\nSee more below.
\nThis blog is based on the Mutagen Fundamentals and Troubleshooting Contributor Training held on January 22, 2026.
\nSee the slides for the training video.
\nMutagen is an asynchronous file synchronization tool that decouples in-container reads and writes from reads and writes on the host machine. Each filesystem enjoys near-native speed because neither is stuck waiting on the other.
\nTraditional Docker bind-mounts check every file access against the file on the host. On macOS and Windows, Docker's implementation of these checks is not performant. Mutagen solves this by maintaining a cached copy of your project files in a Docker volume, syncing changes between host and container asynchronously.
\nThe primary target of Mutagen syncing is PHP files. These were the fundamental problem with Docker as the number of files in a Docker-hosted PHP website grew into the Composer generation with tens of thousands of files, so php-fpm had to open so very many of them all at once. Now with DDEV on macOS using Mutagen, php-fpm is opening files that are just on its local Linux filesystem, not opening ten thousand files that all have to be verified on the host.
Mutagen has delighted many developers with its web-serving performance. One dev said \"the first time I tried it I cried.\"
\nMutagen supports filesystem notifications (inotify/fsnotify), so file-watchers on both the host and inside the container are notified when changes occur. This is a significant advantage for development tools that would otherwise need to poll for changes.
When Mutagen is enabled, DDEV:
\n/var/www inside the web containerddev start: Starts the Mutagen daemon on the host if not running, creates or resumes sync sessionddev stop: Flushes sync session to ensure consistency, then pauses itddev composer: Triggers synchronous flush after completion to sync massive filesystem changesddev mutagen reset: Removes the Docker volume and the sync session will then be recreated from scratch (from the host-side contents) on ddev start.DDEV automatically excludes user-generated files in upload_dirs from Mutagen syncing, using bind-mounts instead. For most CMS types, this is configured automatically, for example:
sites/default/fileswp-content/uploadsfileadmin, uploadsIf your project has non-standard locations, override defaults by setting upload_dirs in .ddev/config.yaml.
We do note that upload_dirs is not an adequate description for this behavior. It was originally intended for user-generated files, but now is used for heavy directories like node_modules, etc.
The first-time Mutagen sync takes 5-60 seconds depending on project size. A Magento 2 site with sample data might take 48 seconds initially, 12 seconds on subsequent starts. If sync takes longer than a minute, you're likely syncing large files or directories unnecessarily.
\nnode_modules DirectoriesFrontend build tools create massive node_modules directories that slow Mutagen sync significantly. Solution: Add node_modules to upload_dirs:
upload_dirs: #upload_dirs entries are relative to docroot\n - sites/default/files # Keep existing CMS defaults\n - ../node_modules # Exclude from Mutagen\nThen run ddev restart. The directory remains available in the container via Docker bind-mount.
If you change files (checking out branches, running git pull, deleting files) while DDEV is stopped, Mutagen has no awareness of these changes. When you start again, it may restore old files from the volume.
Solution: Run ddev mutagen reset before restarting if you've made significant changes while stopped. That removes the volume so everything comes first from the host side in a fresh sync.
If the same file changes on both host and container while out of sync, conflicts can occur. This is quite rare but possible with:
\nnpm install or yarn install operationsBest practices:
\nddev composer for most composer operationsddev mutagen sync after major Git branch changesddev mutagen sync after manual Composer operations done inside the containerMutagen increases disk usage because project code exists both on your computer and inside a Docker volume. The upload_dirs directories are excluded to mitigate this.
Watch for volumes larger than 5GB (warning) or 10GB (critical). Use ddev utility mutagen-diagnose --all to check all projects.
ddev utility mutagen-diagnose CommandDDEV now includes a diagnostic tool that automatically checks for common issues:
\nddev utility mutagen-diagnose\nThis command analyzes:
\nnode_modules and other large directories being syncedUse --all flag to analyze all Mutagen volumes system-wide:
ddev utility mutagen-diagnose --all\nThe diagnostic provides actionable recommendations like:
\n⚠ 3 node_modules directories exist but are not excluded from sync (can cause slow sync)\n → Add to .ddev/config.yaml:\n upload_dirs:\n - sites/default/files\n - web/themes/custom/mytheme/node_modules\n - web/themes/contrib/bootstrap/node_modules\n - app/node_modules\n → Then run: ddev restart\nIf ddev start takes longer than a minute and ddev utility mutagen-diagnose doesn't give you clues about why, watch what Mutagen is syncing:
ddev mutagen reset # Start from scratch\nddev start\nIn another terminal:
\nwhile true; do ddev mutagen st -l | grep \"^Current\"; sleep 1; done\nThis shows which files Mutagen is working on:
\nCurrent file: vendor/bin/large-binary (306 MB/5.2 GB)\nCurrent file: vendor/bin/large-binary (687 MB/5.2 GB)\nCurrent file: vendor/bin/large-binary (1.1 GB/5.2 GB)\nAdd problem directories to upload_dirs or move them to .tarballs (automatically excluded).
Watch real-time sync activity:
\nddev mutagen monitor\nThis shows when Mutagen responds to changes and helps identify sync delays.
\nForce an explicit sync:
\nddev mutagen sync\nCheck sync status:
\nddev mutagen status\nView detailed status:
\nddev mutagen status -l\nVerify that your project works without Mutagen:
\nddev config --performance-mode=none && ddev restart\nRun diagnostics:
\nddev utility mutagen-diagnose\nReset to clean .ddev/mutagen/mutagen.yml:
# Backup customizations first\nmv .ddev/mutagen/mutagen.yml .ddev/mutagen/mutagen.yml.bak\nddev restart\nReset Mutagen volume and recreate it:
\nddev mutagen reset\nddev restart\nEnable debug output:
\nDDEV_DEBUG=true ddev start\nView Mutagen logs:
\nddev mutagen logs\nRestart Mutagen daemon:
\nddev utility mutagen daemon stop\nddev utility mutagen daemon start\nRecommended approach: Use upload_dirs in .ddev/config.yaml:
upload_dirs:\n - sites/default/files # CMS uploads\n - ../node_modules # Build dependencies\n - ../vendor/bin # Large binaries\nAdvanced approach: Edit .ddev/mutagen/mutagen.yml after removing the #ddev-generated line:
ignore:\n paths:\n - \"/web/themes/custom/mytheme/node_modules\"\n - \"/vendor/large-package\"\nThen add corresponding bind-mounts in .ddev/docker-compose.bindmount.yaml:
services:\n web:\n volumes:\n - \"../web/themes/custom/mytheme/node_modules:/var/www/html/web/themes/custom/mytheme/node_modules\"\nAlways run ddev mutagen reset after changing mutagen.yml.
Add .git/hooks/post-checkout and make it executable:
#!/usr/bin/env bash\nddev mutagen sync || true\nchmod +x .git/hooks/post-checkout\nperformance_modeThe standard practice is to use global configuration for performance_mode so that each user does what's normal for them, and the project configuration does not have configuration that might not work for another team member.
Most people don't have to change this anyway; macOS and traditional Windows default to performance_mode: mutagen and Linux/WSL default to performance_mode: none.
Disable Mutagen if:
\nDisable per-project:
\nddev mutagen reset && ddev config --performance-mode=none && ddev restart\nDisable globally:
\nddev config global --performance-mode=none\nDDEV uses its own Mutagen installation, normally in ~/.ddev, but using $XDG_CONFIG_HOME when that is defined.
$HOME/.ddev/bin/mutagen or ${XDG_CONFIG_HOME}/ddev/bin/mutagen$HOME/.ddev_mutagen_data_directoryAccess Mutagen directly:
\nddev utility mutagen sync list\nddev utility mutagen sync monitor <projectname>\nMutagen provides dramatic performance improvements for macOS and traditional Windows users, but understanding its asynchronous nature is key to avoiding issues:
\nddev utility mutagen-diagnose as your first debugging stepupload_dirs to exclude large directories like node_modules or heavy user-generated files directoriesddev mutagen reset after file changes when DDEV is stoppedddev mutagen monitor when troubleshootingThe benefits far outweigh the caveats for most projects, especially with the new diagnostic tools that identify and help resolve common issues automatically.
\nFor more information, see the DDEV Performance Documentation and the Mutagen documentation.
\nCopilot was used to create an initial draft for this blog, and for subsequent reviews.
\n"},{"id":"https://ddev.com/blog/share-providers","url":"https://ddev.com/blog/share-providers","title":"New `ddev share` Provider System: Cloudflare tunnel with no login or token","content_html":"Sharing your local development environment with clients, colleagues, or testing services has always been a valuable DDEV feature. DDEV v1.25.0 makes this easier and more flexible than ever with a complete redesign of ddev share. The biggest news is that you can now share your projects for free using Cloudflare Tunnel—no account signup or token setup required.
ddev sharePrevious versions of DDEV relied exclusively on ngrok for sharing. While ngrok remains a solid choice with advanced features, v1.25.0 introduces a modular provider system allowing more options and flexibility. DDEV now ships with two built-in providers:
\nYou can select providers via command flags, project configuration, or global defaults. Existing projects using ngrok continue working unchanged, and ngrok remains the default provider.
\nCloudflare Tunnel provides production-grade infrastructure for sharing your local environments at zero cost. After installing the cloudflared CLI, getting started is:
ddev share --provider=cloudflared\nNo account creation, no authentication setup, no subscription tiers—just immediate access to share your work. This removes barriers for individual developers and teams who need occasional sharing without the overhead of managing service accounts.
\nWhen should you use cloudflared vs ngrok? Use cloudflared for quick, free sharing during development and testing. Choose ngrok if you need stable subdomains, custom domains, or advanced features like IP allowlisting and OAuth protection. (However, if you control a domain registered at Cloudflare you can use that for stable domains. This will be covered in a future blog.)
\nYou can set your preferred provider at multiple levels:
\n# Use a specific provider for this session\nddev share --provider=cloudflared\n\n# Set default provider for the current project\nddev config --share-default-provider=cloudflared\n\n# Set global default for all projects\nddev config global --share-default-provider=cloudflared\nThis flexibility lets you use different providers for different projects or standardize across your entire development setup.
\nTip: Your CMS or framework may have \"trusted host patterns\" configuration that denies access to the site when hosted at an unknown URL. You'll need to configure to allow all or specific URLs. For example, in Drupal, $settings['trusted_host_patterns'] = ['.*']; or in TYPO3 'trustedHostsPattern' => '.*.*'.
pre-share hooks and $DDEV_SHARE_URLWhen you run ddev share, DDEV now exports the tunnel URL as the DDEV_SHARE_URL environment variable. This enables automation through hooks, particularly useful for integration testing, webhooks, or CI workflows that need the public URL.
WordPress is always difficult because it embeds the URL right in the database. For sites to use a different URL the wp search-replace tool is the classic way to deal with this, so the hook demonstration below can be used to make ddev share work even when the URL is dynamic.
# .ddev/config.yaml\nhooks:\n pre-share:\n # provide DDEV_SHARE_URL in container\n - exec-host: echo \"${DDEV_SHARE_URL}\" >.ddev/share_url.txt\n # Save database for restore later\n - exec-host: ddev export-db --file=/tmp/tmpdump.sql.gz\n # Change the URL in the database\n - exec: wp search-replace ${DDEV_PRIMARY_URL} $(cat /mnt/ddev_config/share_url.txt) | grep Success\n # Fix the wp-config-ddev.php to use the DDEV_SHARE_URL\n - exec: cp wp-config-ddev.php wp-config-ddev.php.bak\n - exec: sed -i.bak \"s|${DDEV_PRIMARY_URL}|$(cat /mnt/ddev_config/share_url.txt)|g\" wp-config-ddev.php\n - exec: wp cache flush\n post-share:\n # Put back the things we changed\n - exec: cp wp-config-ddev.php.bak wp-config-ddev.php\n - exec-host: ddev import-db --file=/tmp/tmpdump.sql.gz\nThis approach works for any CMS that stores base URLs in its configuration or database. The pre-share hook updates URLs automatically, and you can use post-share hooks to restore them when sharing ends. This eliminates the manual configuration work that sharing previously required for many CMSs.
\nTYPO3 usually puts the site URL into config/sites/*/config.yaml as base: <url>, and then it won't respond to the different URLs in a ddev share. The hooks here temporarily remove the base: element:
hooks:\n pre-share:\n # Make a backup of config/sites\n - exec: cp -r ${DDEV_APPROOT}/config/sites ${DDEV_APPROOT}/config/sites.bak\n - exec-host: echo \"removing 'base' from site config for sharing to ${DDEV_SHARE_URL}\"\n # Remove `base:` from the various site configs\n - exec: sed -i 's|^base:|#base:|g' ${DDEV_APPROOT}/config/sites/*/config.yaml\n - exec-host: echo \"shared on ${DDEV_SHARE_URL}\"\n post-share:\n # Restore the original configuration\n - exec: rm -rf ${DDEV_APPROOT}/config/sites\n - exec: mv ${DDEV_APPROOT}/config/sites.bak ${DDEV_APPROOT}/config/sites\n - exec-host: ddev mutagen sync\n - exec-host: echo \"changes to config/sites reverted\"\nMagento2 has pretty easy control of the URL, so the hooks are pretty simple:
\nhooks:\n pre-share:\n # Switch magento to the share URL\n - exec-host: ddev magento setup:store-config:set --base-url=\"${DDEV_SHARE_URL}\"\n post-share:\n # Switch back to the normal local URL\n - exec-host: ddev magento setup:store-config:set --base-url=\"${DDEV_PRIMARY_URL}\"\nThe new provider system is script-based, allowing you to create custom providers for internal tunneling solutions or other services. Place Bash scripts in .ddev/share-providers/ (project-level) or $HOME/.ddev/share-providers/ (global), and DDEV will recognize them as available providers.
For details on creating custom providers, see the sharing documentation.
\nAn example of a share provider for localtunnel is provided in .ddev/share-providers/localtunnel.sh.example and you can experiment with it by just copying that to .ddev/share-providers/localtunnel.sh.
.ddev/share-providers/ (project-level) or $HOME/.ddev/share-providers/ (global). See the sharing documentation for implementation details.DDEV v1.25.0 is now available. Use the techniques above, and try out Cloudflared to see if you like it.
\nFor complete details on the new sharing system, see the sharing documentation.
\nJoin us on Discord, follow us on Mastodon, Bluesky, or LinkedIn, and subscribe to our newsletter for updates.
\nThis blog was drafted and reviewed by AI including Claude Code.
\n"},{"id":"https://ddev.com/blog/podman-and-docker-rootless","url":"https://ddev.com/blog/podman-and-docker-rootless","title":"Podman and Docker Rootless in DDEV","content_html":"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.
\nJump to setup instructions: Linux/WSL2 · macOS · Windows
\nNote: This support is experimental. Report issues on the DDEV issue tracker.
\nA 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:
\nAll 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.
\nPodman 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.)
\nPodman's rootless approach runs the daemon without elevated privileges:
\nWhile DDEV already runs containers as unprivileged users, Podman eliminates the need for a root daemon entirely.
\nDocker Rootless provides the same security benefits as Podman Rootless while maintaining full Docker compatibility. It runs the daemon without root privileges, offering:
\nUnlike 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.
\nThe 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.
\nBefore diving into setup, consider whether you need an alternative to traditional Docker:
\n| Runtime | \nWhy would you do this? | \nKey trade-offs | \nPerformance | \nSetup | \nRecommendation | \n
|---|---|---|---|---|---|
| Traditional Docker | \nStandard, widely-used option | \nNone | \nExcellent | \nSimple | \nRecommended for most users | \n
| Docker Rootless | \nSecurity requirement for rootless daemon | \nMust use --no-bind-mounts (everything via Mutagen), can't use default workflow | \nModerate (Mutagen overhead) | \nModerate | \nOnly if rootless security is required | \n
| Podman Rootful | \nOrganization forbids Docker | \nSlower than Docker, different behavior | \nSlower than Docker | \nModerate | \nOnly if Docker not allowed | \n
| Podman Rootless | \nOrganization forbids Docker + want rootless security | \nMay need sysctl changes for ports <1024, slower than Docker | \nSlower than Docker | \nModerate | \nOnly if Docker not allowed and rootless required | \n
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.
\nInstall Podman using your distribution's package manager. See the official Podman installation guide for Linux.
\n# Ubuntu/Debian\nsudo apt-get update && sudo apt-get install podman\n# Fedora\nsudo dnf install --refresh podman\nNote: 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.
\nFor more information, see the Podman tutorials.
\nPodman provides a Docker-compatible API, which means you can use the Docker CLI as a frontend for Podman. This approach offers several benefits:
\ndocker commands while Podman handles the actual container operationsdocker commandInstall only the CLI:
\n# Ubuntu/Debian\nsudo apt-get update && sudo apt-get install docker-ce-cli\n# Fedora\nsudo dnf install --refresh docker-ce-cli\nNote: You don't need to install docker-ce (the Docker engine).
This is the recommended configuration for most users.
\nPrepare the system by configuring subuid and subgid ranges and enabling userns options, see the Arch Linux Wiki for details:
\n# Add subuid and subgid ranges if they don't exist for the current user\ngrep \"^$(id -un):\\|^$(id -u):\" /etc/subuid >/dev/null 2>&1 || sudo usermod --add-subuids 100000-165535 $(whoami)\ngrep \"^$(id -un):\\|^$(id -u):\" /etc/subgid >/dev/null 2>&1 || sudo usermod --add-subgids 100000-165535 $(whoami)\n# Propagate changes to subuid and subgid\npodman system migrate\n# Debian requires setting unprivileged_userns_clone\nif [ -f /proc/sys/kernel/unprivileged_userns_clone ]; then\n if [ \"1\" != \"$(cat /proc/sys/kernel/unprivileged_userns_clone)\" ]; then\n echo 'kernel.unprivileged_userns_clone=1' | sudo tee -a /etc/sysctl.d/60-rootless.conf\n sudo sysctl --system\n fi\nfi\n# Fedora requires setting max_user_namespaces\nif [ -f /proc/sys/user/max_user_namespaces ]; then\n if [ \"0\" = \"$(cat /proc/sys/user/max_user_namespaces)\" ]; then\n echo 'user.max_user_namespaces=28633' | sudo tee -a /etc/sysctl.d/60-rootless.conf\n sudo sysctl --system\n fi\nfi\n# Allow privileged port access if needed\nif [ -f /proc/sys/net/ipv4/ip_unprivileged_port_start ]; then\n if [ \"1024\" = \"$(cat /proc/sys/net/ipv4/ip_unprivileged_port_start)\" ]; then\n echo 'net.ipv4.ip_unprivileged_port_start=0' | sudo tee -a /etc/sysctl.d/60-rootless.conf\n sudo sysctl --system\n fi\nfi\nEnable the Podman socket and verify it's running (Podman socket activation documentation):
\nsystemctl --user enable --now podman.socket\n\n# You should see `/run/user/1000/podman/podman.sock` (the number may vary):\nls $XDG_RUNTIME_DIR/podman/podman.sock\n\n# You can also check the socket path with:\npodman info --format '{{.Host.RemoteSocket.Path}}'\nConfigure Docker API to use Podman (Podman rootless tutorial):
\n# View existing contexts\ndocker context ls\n\n# Create Podman rootless context\ndocker context create podman-rootless \\\n --description \"Podman (rootless)\" \\\n --docker host=\"unix://$XDG_RUNTIME_DIR/podman/podman.sock\"\n\n# Switch to the new context\ndocker context use podman-rootless\n\n# Verify it works\ndocker ps\nProceed with DDEV installation.
\nPodman Rootless is significantly slower than Docker. See these resources:
\n\nTo improve performance, install fuse-overlayfs and configure the overlay storage driver:
Install fuse-overlayfs:
\n# Ubuntu/Debian\nsudo apt-get update && sudo apt-get install fuse-overlayfs\n# Fedora\nsudo dnf install --refresh fuse-overlayfs\nConfigure storage:
\nmkdir -p ~/.config/containers\ncat << 'EOF' > ~/.config/containers/storage.conf\n[storage]\ndriver = \"overlay\"\n[storage.options.overlay]\nmount_program = \"/usr/bin/fuse-overlayfs\"\nEOF\nWarning: If you already have Podman containers, images, or volumes, you'll need to reset Podman for this change to take effect:
\npodman system reset\nThis removes all existing containers, images, and volumes (similar to docker system prune -a).
Rootless Podman is recommended. Only use rootful Podman if your setup specifically requires it.
\nTo configure rootful Podman:
\npodman group (sudo groupadd podman) and add your user to it (sudo usermod -aG podman $USER).sudo systemctl enable --now podman.socketdocker context create podman-rootful --description \"Podman (root)\" --docker host=\"unix:///var/run/podman/podman.sock\"docker context use podman-rootfulDocker Rootless on Linux offers rootless security with full Docker compatibility.
\nFollow the official Docker Rootless installation guide.
\nConfigure system:
\n# Allow privileged port access if needed\nif [ -f /proc/sys/net/ipv4/ip_unprivileged_port_start ]; then\n if [ \"1024\" = \"$(cat /proc/sys/net/ipv4/ip_unprivileged_port_start)\" ]; then\n echo 'net.ipv4.ip_unprivileged_port_start=0' | sudo tee -a /etc/sysctl.d/60-rootless.conf\n sudo sysctl --system\n fi\nfi\n# Allow loopback connections (needed for working Xdebug)\n# See https://github.com/moby/moby/issues/47684#issuecomment-2166149845\nmkdir -p ~/.config/systemd/user/docker.service.d\ncat << 'EOF' > ~/.config/systemd/user/docker.service.d/override.conf\n[Service]\nEnvironment=\"DOCKERD_ROOTLESS_ROOTLESSKIT_DISABLE_HOST_LOOPBACK=false\"\nEOF\nEnable the Docker socket, and verify it's running:
\nsystemctl --user enable --now docker.socket\n\n# You should see `/run/user/1000/docker.sock` (the number may vary):\nls $XDG_RUNTIME_DIR/docker.sock\nConfigure Docker API to use Docker rootless:
\n# View existing contexts\ndocker context ls\n\n# Create rootless context if it doesn't exist\ndocker context inspect rootless >/dev/null 2>&1 || \\\n docker context create rootless \\\n --description \"Rootless runtime socket\" \\\n --docker host=\"unix://$XDG_RUNTIME_DIR/docker.sock\"\n\n# Switch to the context\ndocker context use rootless\n\n# Verify it works\ndocker ps\nProceed with DDEV installation.
\nDocker Rootless requires no-bind-mounts mode
\nDocker Rootless has a limitation with bind mounts that affects DDEV. You must enable no-bind-mounts mode:
ddev config global --no-bind-mounts=true\nWhy this is needed:
\nDocker Rootless sets ownership for bind mounts to root inside containers. This is a known issue:
The root user inside the container maps to your host user, but many services 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 users can use Podman and Podman Desktop, but setup has its own challenges. Docker Rootless is not available on macOS.
\n| Runtime | \nWhy would you do this? | \nKey trade-offs | \nPerformance | \nSetup | \nRecommendation | \n
|---|---|---|---|---|---|
| Traditional Docker | \nStandard, widely-used option | \nNone | \nExcellent | \nSimple | \nRecommended for most users | \n
| Podman | \nAvoid Docker entirely (organizational policy) | \nCannot use ports 80/443 (must use 8080/8443 instead), different behavior | \nSlower than Docker | \nModerate | \nOnly if Docker not allowed | \n
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.
\nInstall Podman using Homebrew:
\nbrew install podman\nOr install Podman Desktop if you prefer a GUI.
\nFor more information, see the official Podman installation guide for macOS and Podman tutorials.
\nPodman provides a Docker-compatible API, which means you can use the Docker CLI as a frontend for Podman. This approach offers several benefits:
\ndocker commands while Podman handles the actual container operationsdocker commandbrew install docker\nHandle privileged ports (<1024):
\nImportant: Podman on macOS cannot bind to privileged ports (80/443). You must configure DDEV to use unprivileged ports:
\nddev config global --router-http-port=8080 \\\n --router-https-port=8443\nThis 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).
Initialize and start the Podman machine:
\n# check `podman machine init -h` for more options\npodman machine init --memory 8192\npodman machine start\nCheck for the Podman socket path using podman machine inspect:
~ % podman machine inspect\n...\n \"ConnectionInfo\": {\n \"PodmanSocket\": {\n \"Path\": \"/var/folders/z5/lhpyjf2n7xj2djl0bw_7kb3m0000gn/T/podman/podman-machine-default-api.sock\"\n },\n \"PodmanPipe\": null\n },\n...\nConfigure Docker CLI to use Podman. Choose one of two approaches:
\nOption 1: Create a Docker context (recommended, more flexible):
\n# Create Podman context (path to socket may vary)\n# Use the socket path from `podman machine inspect` output\ndocker context create podman-rootless \\\n --description \"Podman (rootless)\" \\\n --docker host=\"unix:///var/folders/z5/lhpyjf2n7xj2djl0bw_7kb3m0000gn/T/podman/podman-machine-default-api.sock\"\n\n# Switch to the new context\ndocker context use podman-rootless\n\n# Verify it works\ndocker ps\nThis 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.
\nOption 2: Use the default Docker socket (simpler, but less flexible):
\n# Install podman-mac-helper\n# Use the command from `podman machine start` output\nsudo /opt/homebrew/Cellar/podman/5.7.1/bin/podman-mac-helper install\npodman machine stop\npodman machine start\n\n# Verify it works\ndocker ps\nProceed with DDEV installation.
\nWindows 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).
\n| Runtime | \nWhy would you do this? | \nKey trade-offs | \nPerformance | \nSetup | \nRecommendation | \n
|---|---|---|---|---|---|
| Traditional Docker | \nStandard, widely-used option | \nNone | \nExcellent | \nSimple | \nRecommended for most users | \n
| Podman | \nAvoid Docker entirely (organizational policy) | \nDifferent behavior, less mature on Windows | \nSlower than Docker | \nModerate | \nOnly if Docker not allowed | \n
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.
\nInstall Podman Desktop, which includes Podman.
\nAlternatively, install Podman directly following the official Podman installation guide for Windows.
\nFor more information, see the Podman tutorials.
\nThe 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.
\nYou can run Docker and Podman sockets simultaneously and switch between them using Docker contexts.
\nFor example, here's a system with four active Docker contexts:
\n$ docker context ls\nNAME DESCRIPTION DOCKER ENDPOINT\ndefault Current DOCKER_HOST based configuration unix:///var/run/docker.sock\npodman Podman (rootful) unix:///var/run/podman/podman.sock\npodman-rootless * Podman (rootless) unix:///run/user/1000/podman/podman.sock\nrootless Rootless runtime socket unix:///run/user/1000/docker.sock\nSwitch between them with:
\ndocker context use \"<context-name>\"\nNote: 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.
\nDDEV automatically detects your active container runtime. To switch:
\nStop DDEV projects:
\nddev poweroff\nSwitch Docker context or change the DOCKER_HOST environment variable
Start your project:
\nddev start\n| Feature | \nStandard Docker | \nDocker Rootless | \nPodman Rootful | \nPodman Rootless | \n
|---|---|---|---|---|
| Platform Support | \nAll | \nLinux, WSL2 | \nAll | \nAll | \n
| Rootless Daemon | \n❌ | \n✅ | \n❌ | \n✅ | \n
| Has automated testing in DDEV | \n✅ | \n✅ | \n❌ | \n✅ | \n
| Mutagen | \n✅ | \n✅ | \n✅ | \n✅ | \n
| Bind Mounts | \n✅ | \n❌, requires no-bind-mounts | \n✅ | \n✅ (with --userns=keep-id) | \n
| Performance | \nExcellent | \nModerate (because of no-bind-mounts) | \nSlow compared to Docker | \nSlow compared to Docker | \n
| Privileged Ports (<1024) | \nWorks by default | \nRequires sysctl config | \nWorks by default | \nRequires sysctl config or may not work | \n
| Setup Complexity | \nSimple | \nModerate | \nModerate | \nModerate | \n
| Maturity | \nMost mature | \nExperimental | \nExperimental | \nExperimental | \n
| Recommended For | \nMost users | \nDocker users needing rootless | \nOrganizations that forbid Docker | \nOrganizations that forbid Docker | \n
Use of the many standard Docker providers if:
\nThis is the recommended option for the vast majority of users.
\nUse Podman Rootless if:
\nUse Podman Rootful if:
\nUse Docker Rootless if:
\nSupporting Podman and Docker Rootless required major changes to DDEV's Docker integration:
\ndocker context inspect directly, which doesn't work with Podman. We switched to using the docker/cli library to handle context operations properly.ddev auth ssh command used to call docker run directly. We rewrote it to use the Docker API, making it compatible with alternative runtimes.links and external_links directives in docker-compose files. We removed these legacy features and modernized DDEV's compose file generation.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.
\nThis Podman and Docker Rootless support was made possible by community financial support. The changes required hundreds of hours of development, code reviews, and testing.
\nDDEV 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.
\nDDEV now supports Podman and Docker Rootless as experimental features. This opens DDEV to corporate environments where traditional Docker is not allowed.
\nDDEV 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.
\nThis article was edited and refined with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/release-v1250","url":"https://ddev.com/blog/release-v1250","title":"DDEV v1.25.0: Improved Windows Support, Faster Debugging, and Modern Defaults","content_html":"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.
\nThis release represents contributions from the entire DDEV community, with your suggestions, bug reports, code contributions, and financial support making it possible.
\nDefault versions updated:
\nThese updates mostly affect new projects. Existing projects typically continue to work without changes.
\nddev-webserver and ddev-ssh-agentMajor new features:
\nddev share command with a new cloudflared share provider for free sharing options. See new docs and blogddev utility xdebug-diagnose helps troubleshoot Xdebug issues. See Xdebug Understanding and Troubleshootingddev utility mutagen-diagnose helps debug Mutagen issues. See Mutagen in DDEV: Functionality, Issues, and Debuggingddev snapshot now uses zstd instead of gzip for significantly faster exports and restores, thanks @deviantintegralddev-frankenphp with many improvements. See updated Using FrankenPHP with DDEV.ddev/traefik/config/<projectname>.yaml (all other files are ignored)After upgrading to v1.25.0, follow these steps:
\nddev poweroff (DDEV will prompt you for this)ddev config --auto on each project to update to current configurationddev add-on list --installed to see your add-ons, then update them as neededddev delete images to remove old Docker image versionsIf 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.
\nNote: DDEV already includes the tzdata-legacy package to handle removed timezones in Debian Trixie, so no action is needed for timezone-related changes.
If you use XHProf profiling, it now defaults to XHGui mode instead of prepend mode.
\nWhat to do: If you prefer the previous prepend mode, run:
\nddev config global --xhprof-mode=prepend\nIf 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.
\nWhat to do: Update your nginx module configuration.
\nExample: Adding NJS (JavaScript) support to nginx in DDEV v1.25.0+:
\nddev config --webimage-extra-packages=\"libnginx-mod-http-js,libnginx-mod-stream,libnginx-mod-stream-js\" --ddev-version-constraint='>=v1.25.0'\n\ncat <<'EOF' > .ddev/web-build/Dockerfile.nginx\nRUN 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\nEOF\nIf you use these commands, you'll need to switch:
\nddev nvm: Switch to nodejs_version or install the ddev-nvm add-onddev service: Use ddev add-on to install/remove servicesddev config flagsIf you use these flags in scripts, update them:
\n--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-defaultIf you have custom Traefik configuration, note that:
\n.ddev/traefik/config/<projectname>.yaml is used (other files are ignored)$HOME/.ddev/traefik/custom-global-config/What to do if you have extra Traefik files:
\n.ddev/traefik/config/<projectname>.yaml and remove the #ddev-generated comment from itNote: ddev-router no longer stops automatically when the last project stops. Use ddev poweroff to stop it manually.
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.
\nThis release includes many other improvements:
\nddev add-on list and ddev add-on searchddev add-on get <TAB>$HOME/.ddev/homeadditions/.ssh/config.dSee the full release notes for complete details.
\nFrom the entire team, thanks for using, promoting, contributing, and supporting DDEV!
\nIf you have questions, reach out in any of the support channels.
\nFollow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
\nThis article was edited and refined with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/ddev-jan-2026-newsletter","url":"https://ddev.com/blog/ddev-jan-2026-newsletter","title":"DDEV January 2026: Year in Review, Looking Ahead, and Community Momentum","content_html":"This is the time of year that many of us look backward and forward to inform our future, and DDEV is no different. We took the time to review last year and put together plans for 2026.
\nMany DDEV users love the PhpStorm/IntelliJ DDEV Integration Plugin maintained by AkibaAT and the VS Code DDEV Manager by Biati Digital, but there are new experimental entries in the GUI manager space:
\nWant to help DDEV development? Consider testing with the HEAD version of DDEV. This helps us catch issues early. We expect that some advanced users with complex Dockerfiles may have hiccups with upcoming v1.25.0. It's easy, See the docs↗ for instructions.
\nJoin us for upcoming training sessions for contributors and users.
\nJanuary 22, 2026 at 10:00 US ET / 16:00 CET — Mutagen, syncing, problems, upload_dirs for direct bind mounts\nAdd to Google Calendar •\nDownload .ics
\nFebruary 26, 2026 at 10:00 US ET / 16:00 CET — Git bisect for fun and profit\nAdd to Google Calendar •\nDownload .ics
\nMarch 26, 2026 at 10:00 US ET / 15:00 CET — Using git worktree with DDEV projects and with DDEV itself\nAdd to Google Calendar •\nDownload .ics
April 23, 2026 at 10:00 US ET / 16:00 CEST — Creating, maintaining and testing add-ons\n2026-updated version of our popular add-on training. Previous session recording↗\nAdd to Google Calendar •\nDownload .ics
\nZoom Info:\nLink: Join Zoom Meeting\nPasscode: 12345
\nWhen we shared the news about Upsun lowering their sponsorship, the community responded. In just one month, sponsorship jumped from 58% to 68% of our goal—a 10% increase that makes a real difference. Thank you to everyone who stepped up and to those of you who are about to jump on board.
\nPrevious status (December 2025): ~$6,964/month (58% of goal)
\nJanuary 19, 2026: ~$8,208/month (68% of goal)
\n\nIf DDEV has helped your team, now is the time to give back. Whether you're an individual developer, an agency, or an organization — your contribution makes a difference. → Become a sponsor↗
\nContact us to discuss sponsorship options that work for your organization.
\nCompiled and edited with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/2026-plans","url":"https://ddev.com/blog/2026-plans","title":"Planning for another great DDEV year in 2026","content_html":"Every year we try to lay out a bit of a plan for the coming year.
\nOne of DDEV's primary strengths is our connection to a wonderful community, so each year turns out a bit different than expected. As we listen to people's actual experience, we try to adjust. And of course as upstream changes bring new features and bugs, we get lots of fun things to work on that we could never have anticipated. The items listed here are notes about what we think we understand at this point, but the year ahead and user experience and requests will affect what really happens.
\nWe look forward to your input as the year goes forward.
\nCommunity is core to our strength and growth. We are committed to maintaining the outstanding support that we offer for free and keeping that communication line open. And we want to continue to grow the amazing corps of contributors who offer improvements to the DDEV ecosystem.
\nIn 2025 we established Board of Directors, but now we have to learn what that means. The Board will have to establish itself, begin helping to determine priorities, and find its way to a strong oversight role. Here are a few issues to toss to the board early:
\nmkcert toolddev config, Consider offering ddev config --auto or ddev config when ddev start in a directory without config (issue).ddev/.env* files, marking DDEV-owned lines, etc.composer instead of ddev composer, etc). People can already do this with ddev ssh, but that isn't directly compatible with VS Code or PhpStorm.ddev start and similar commands.We are a very small organization, so we try to pay careful attention to the risks as we go forward. In many ways, these are the same as the 2025 noted risks.
\nPrevious plans and reviews have obviously framed this year's plans: 2025 Plans and 2024 review, 2024 plans
\nIn preparing for this, we have been discussing these things in regular advisory group meetings and a specific brainstorming meeting.
\nWe always want to hear from you about your experiences with DDEV as the year goes along!
\nWant to keep up as the month goes along? Follow us on:
\n\n"},{"id":"https://ddev.com/blog/2025-review","url":"https://ddev.com/blog/2025-review","title":"DDEV 2025 Year in Review","content_html":"2025 has been a year of significant growth and accomplishment for DDEV. With 579 commits to the main repository and releases from v1.24.0 through v1.24.10, we've made substantial progress on features, infrastructure, and community building. Here's a look back at what we all achieved together.
\nThe DDEV open-source community continues excellent engagement on several fronts.
\nddev start notifications keep users informed about sponsorship statusddev add-on get now downloads add-on dependencies automaticallyx-ddev extension allows add-ons to add important information to ddev describe outputddev start --profiles=list,of,profilesdocker binary (switched to github.com/docker/cli) and no fragile YAML map structures (switched to github.com/compose-spec/compose-go/v2)Upcoming v1.25.0:
\nddev-upsun add-on provides new integration with Upsun (formerly Platform.sh) fixed and flex projects.ddev-hostname binary, improving security, read more--user/-u flag for ddev exec and ddev sshddev describe now works on stopped projectsddev utility download-images --all forces pulling all images in useddev npx command supportddev delete and ddev delete imagesUpcoming v1.25.0:
\nddev share: More configurable, customizable, with pre-share hooks and DDEV_SHARE_URL environment variableddev utility mutagen-diagnose: Automatic study of Mutagen problems or misconfigurationddev utility xdebug-diagnose: Automatic study of possible Xdebug configuration problemsUpcoming v1.25.0:
\n2025 saw significant AI integration in our development workflow:
\nddev service command removedddev nvm functionality removed, but still supported with ddev-nvm add-onbitnami/mysql issue: Using bitnami/mysql for MySQL 8.0 and 8.4 backfired with Bitnami ceasing its traditional support of important Docker images. This raises questions about dependency management when upstream projects change direction.In 2025 Plans we laid out ambitious plans for 2025. Here are the outcomes:
\nddev-upsun now supports the older Platform.sh \"fixed\" projects.ddev utility diagnose, ddev utility mutagen-diagnose, ddev utility xdebug-diagnose.ddev share to a more configurable custom-command-based option: Done (in v1.25.0)As an open-source project we truly value the amazing contributions of the community. There are so many ways these contributions happen, including support requests and issues (we learn so much from those!) but also direct contributions.
\nI know this is \"Too Much Information\" but here is a simple and inadequate list of the amazing contributions directly to the main project by contributors other than Randy and Stas. It inspires me so much to see this consolidated list.
\nRalf Koller - rpkoller - 36 contributions
\nAkiba - AkibaAT - 7 contributions
\nddev add-on search subcommand, fixes #7491 (#7554)DDEV_PRIMARY_URL_PORT, DDEV_PRIMARY_URL_WITHOUT_PORT and DDEV_SCHEME, fixes #7214 (#7218)Ariel Barreiro - hanoii - 6 contributions
\nddev add-on get output, add warning exit code annotation (#7263)#ddev-description stanza in add-on install actions not showing if it's the first line (#7022)tyler36 - tyler36 - 4 contributions
\nmove-issue config , fixes #6899 (#6906)Travis Carden - TravisCarden - 3 contributions
\nsequelace command link to database-management.md (#7184)troubleshooting.md (#6984)Laryn - laryn - 3 contributions
\nAndrew Berry - deviantintegral - 2 contributions
\npostgres:9 snapshot, fixes #7844, fixes #3583 (#7845)Raphael Portmann - raphaelportmann - 2 contributions
\n--databases=db to postgres, for #7830 (#7847)cyppe - cyppe - 2 contributions
\n.env when there's no database (#7584)Peter Bowyer - pbowyer - 2 contributions
\nShelane French - shelane - 2 contributions
\nPierre Paul Lefebvre - PierrePaul - 2 contributions
\nSven Reichel - sreichel - 2 contributions
\nlguigo22 - lguigo22 - 1 contribution
\nJustin Vogt - JUVOJustin - 1 contribution
\ngrummbeer - grummbeer - 1 contribution
\ncrowjake - crowjake - 1 contribution
\nHostWorkingDir respect WebWorkingDir (#7907)Markus Sommer - BreathCodeFlow - 1 contribution
\nJames Sansbury - q0rban - 1 contribution
\nMoshe Weitzman - weitzman - 1 contribution
\nYan Loetzer - yanniboi - 1 contribution
\n.ddev/.env.* (#7828)Garvin Hicking - garvinhicking - 1 contribution
\nBenny Poensgen - vanWittlaer - 1 contribution
\nRob Loach - RobLoach - 1 contribution
\nJshGrn - JshGrn - 1 contribution
\nE - ara303 - 1 contribution
\nAlan Doucette - dragonwize - 1 contribution
\nddev npx command (#7599)Brooke Mahoney - brookemahoney - 1 contribution
\ngitressa - gitressa - 1 contribution
\nEduardo Rocha - hockdudu - 1 contribution
\nDezső BICZÓ - mxr576 - 1 contribution
\nTomas Norre Mikkelsen - tomasnorre - 1 contribution
\nDanny Pfeiffer - danny2p - 1 contribution
\nPopus Razvan Adrian - punkrock34 - 1 contribution
\nDaniel Huf - dhuf - 1 contribution
\nAyu Adiati - adiati98 - 1 contribution
\nwsl --update command for Windows (#7476)Peter Philipp - das-peter - 1 contribution
\n/etc/mysql/conf.d/* for db container restart, fixes #7457 (#7458)O'Briat - obriat - 1 contribution
\nAndreas Hager - andreashager - 1 contribution
\nddev exec and add quiet flag to it, fixes #3518 (#7385)Bill Seremetis - bserem - 1 contribution
\nOlivier Mengué - dolmen - 1 contribution
\nRui Chen - chenrui333 - 1 contribution
\nmain for setup-homebrew action instead of master (#7395)michaellenahan - michaellenahan - 1 contribution
\nAugust Miller - AugustMiller - 1 contribution
\nLoz Calver - lozcalver - 1 contribution
\nTim Kelty - timkelty - 1 contribution
\nPedro Antonio Fructuoso Merino - pfructuoso - 1 contribution
\nBang Dinh - bangdinhnfq - 1 contribution
\nnmangold - nmangold - 1 contribution
\nJeremy Gonyea - jgonyea - 1 contribution
\nColan Schwartz - colans - 1 contribution
\nMrtn Schndlr - barbieswimcrew - 1 contribution
\nMarvin Hinz - marvinhinz - 1 contribution
\nRubenColpaert - RubenColpaert - 1 contribution
\ncharset=utf8mb4 in DATABASE_URL for Symfony environment variables, fixes #7068 (#7076)Alexey Murz Korepov - MurzNN - 1 contribution
\nAdam - phenaproxima - 1 contribution
\nNick Hope - Nick-Hope - 1 contribution
\nDamilola Emmanuel Olowookere - damms005 - 1 contribution
\nnickchomey - nickchomey - 1 contribution
\nAndrew Gearhart - AndrewGearhart - 1 contribution
\nChristopher Kaster - atomicptr - 1 contribution
\nHervé Donner - vever001 - 1 contribution
\nBernhard Baumrock - BernhardBaumrock - 1 contribution
\nErik Peterson - eporama - 1 contribution
\nTom Yukhayev - charginghawk - 1 contribution
\n| Contributor | \nGitHub | \nCount | \n
|---|---|---|
| Ralf Koller | \nrpkoller | \n36 | \n
| Akiba | \nAkibaAT | \n7 | \n
| Ariel Barreiro | \nhanoii | \n6 | \n
| tyler36 | \ntyler36 | \n4 | \n
| Travis Carden | \nTravisCarden | \n3 | \n
| Laryn | \nlaryn | \n3 | \n
| Andrew Berry | \ndeviantintegral | \n2 | \n
| Raphael Portmann | \nraphaelportmann | \n2 | \n
| cyppe | \ncyppe | \n2 | \n
| Peter Bowyer | \npbowyer | \n2 | \n
| Shelane French | \nshelane | \n2 | \n
| Pierre Paul Lefebvre | \nPierrePaul | \n2 | \n
| Sven Reichel | \nsreichel | \n2 | \n
| lguigo22 | \nlguigo22 | \n1 | \n
| Justin Vogt | \nJUVOJustin | \n1 | \n
| grummbeer | \ngrummbeer | \n1 | \n
| crowjake | \ncrowjake | \n1 | \n
| Markus Sommer | \nBreathCodeFlow | \n1 | \n
| James Sansbury | \nq0rban | \n1 | \n
| Moshe Weitzman | \nweitzman | \n1 | \n
| Yan Loetzer | \nyanniboi | \n1 | \n
| Garvin Hicking | \ngarvinhicking | \n1 | \n
| Benny Poensgen | \nvanWittlaer | \n1 | \n
| Rob Loach | \nRobLoach | \n1 | \n
| JshGrn | \nJshGrn | \n1 | \n
| E | \nara303 | \n1 | \n
| Alan Doucette | \ndragonwize | \n1 | \n
| Brooke Mahoney | \nbrookemahoney | \n1 | \n
| gitressa | \ngitressa | \n1 | \n
| ...and 36 more contributors | \n\n | \n |
Guest contributions to the blog are always welcome and key contributors added significant posts this year:
\nAjith Thampi Joseph - atj4me
\n\nBill Seremetis - bserem
\n\nGarvin Hicking - garvinhicking
\n\nJeremy Gonyea - jgonyea
\n\nayalon - ayalon
\nAnd thanks to all of you who use DDEV, report issues, answer questions in Discord and other venues, and spread the word. Your support makes this project possible.
\nThere are so many unofficial add-ons being maintained by so many people, but here are the folks that maintained official repositories:
\nStay tuned for our 2026 plans post where we'll outline what's next for DDEV. As always, we welcome your input through all our support venues.
\nClaude Code and GitHub Copilot were used as assistants in gathering lists and material, and in reviewing this article.
\n"},{"id":"https://ddev.com/blog/ddev-december-2025-newsletter","url":"https://ddev.com/blog/ddev-december-2025-newsletter","title":"DDEV December 2025 Newsletter","content_html":"As we wrap up 2025, there's much to celebrate and some important news to share. The DDEV Foundation has reached a governance milestone, and we're looking ahead to 2026 with both gratitude and a call to action.
\nWe're preparing for the upcoming v1.25.0 major release in January. Here are some things to know:
\nWatch for announcements everywhere.
\nSeveral new official add-ons have been added to the registry:
\nddev nvm, which has been removed from upcoming v1.25.0)Want to help DDEV development? Consider testing with the HEAD version of DDEV. This helps us catch issues early. We think some advanced users with complex Dockerfiles may have hiccups with upcoming v1.25.0. It's easy, See the docs↗ for instructions.
\nJoin us for upcoming training sessions for contributors and users.
\nJanuary 22, 2026 at 10:00 US ET / 16:00 CET — Mutagen, syncing, problems, upload_dirs for direct bind mounts\nAdd to Google Calendar •\nDownload .ics
\nFebruary 26, 2026 at 10:00 US ET / 16:00 CET — Git bisect for fun and profit\nAdd to Google Calendar •\nDownload .ics
\nMarch 26, 2026 at 10:00 US ET / 15:00 CET — Using git worktree with DDEV projects and with DDEV itself\nAdd to Google Calendar •\nDownload .ics
April 23, 2026 at 10:00 US ET / 16:00 CEST — Creating, maintaining and testing add-ons\n2026-updated version of our popular add-on training. Previous session recording↗\nAdd to Google Calendar •\nDownload .ics
\nZoom Join Info:\nLink: Join Zoom Meeting\nPasscode: 12345
\nAnnual Advisory Group and Board Meeting — Join us for our annual extended advisory group and board meeting (public; all are welcome):
\nJanuary 14, 2026 at 8:00 AM US Mountain Time / 4:00 PM CET — DDEV Extended Advisory Group and Board Meeting\nAnnual 2-hour review of 2025 and plans for 2026\nDiscussion details↗ •\nAdd to Google Calendar •\nDownload .ics
\nWith Upsun lowering their sponsorship in January, we'll drop from 70% to about 58% of our sponsorship goal. That's a significant gap.
\nPrevious status: $8,376/month (70% of goal)
\nAfter January: ~$6,964/month (58% of goal)
\nIf DDEV has helped your team, now is the time to give back. Whether you're an individual developer, an agency, or an organization — your contribution makes a difference. → Become a sponsor↗
\nContact us to discuss sponsorship options that work for your organization.
\nCompiled and edited with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/upsun-thank-you-new-sponsors-needed","url":"https://ddev.com/blog/upsun-thank-you-new-sponsors-needed","title":"Thanks to Upsun, and Your Help is Needed Now!","content_html":"TL;DR Upsun has been (and remains) a great sponsor of DDEV, but is lowering their support level next month. We need you to fill the gap!
\nI'm sure you remember how much Upsun (formerly Platform.sh) has helped the DDEV project along the way. When we were about to lose the ability to use the \"DDEV\" name, they stepped in and solved the problem. Then they sponsored DDEV at a very high level for a couple of years, and in 2025 at a lower level. They have also managed the DDEV trademark and are now transferring it to the rapidly maturing DDEV Foundation. We appreciate their significant ongoing support very much, and fully recognize and appreciate their critical role in our history.
\nStarting next month, Upsun will be lowering their sponsorship level to $1000/month. They are still one of our most significant supporters, but this leaves a significant gap in our funding.
\nStarting in January, we'll be at about 53% of our sponsorship goal, down from 70% as of December 2025. The current sponsorship level is about $8300/month; with the decrease from Upsun it will drop to about $6300/month. That's a big hole to fill, and we're counting on you to help!
\nIn 2025, the DDEV Foundation (through your support) paid between $8,000-$10,000 per month to developers working on the project for you. Without additional funding, we're estimating a shortfall of about $2000 a month.
\nDDEV is free and open-source because sponsors like you make it possible. Whether you're an individual developer, an agency using DDEV for client work, or an organization that depends on DDEV, now is the time to contribute.
\nWays to sponsor:
\nContact us to discuss sponsorship options that work for your organization.
\nDDEV serves nearly 20,000 developers and teams worldwide every week. Your sponsorship ensures continued development, maintenance, security updates, and community support. When you sponsor DDEV, you're investing in a tool that saves your team countless hours and makes local development reliable and consistent.
\nLet's work together to keep DDEV strong and sustainable. Thank you for being part of this community!
\nClaude Code was used for editing and ideas helped with this post.
\n"},{"id":"https://ddev.com/blog/board-of-directors-established","url":"https://ddev.com/blog/board-of-directors-established","title":"The DDEV Foundation Now Has a Board of Directors!","content_html":"We're excited to announce that the DDEV Foundation has officially established a Board of Directors! This is a significant milestone in our journey toward enhanced governance and long-term sustainability for the DDEV project.
\nToday we filed an amended Articles of Incorporation with the Secretary of State of Colorado, which includes the Board of Directors.
\nMike Anello is a seasoned Drupal developer with over 15 years of experience. He specializes in Drupal consulting and training through his business, ensuring clients leverage Drupal's full potential. Mike is a notable community contributor and advocate, sharing his expertise and insights widely. Mike is already serving as the Treasurer of the Foundation.
\nJen Lampton has been building websites since 1997 and participating in Open Source communities since 2006. She is a co-founder of Backdrop CMS and a provisional member of the Drupal security team. Jen currently maintains dozens of Open Source projects and contributes to other projects (including DDEV!) as it applies to her work.
\nBenni Mack is a long-time TYPO3 core developer and contributor, serving as TYPO3 CMS Team Lead. He brings extensive experience in open source project governance and community building. Benni is passionate about developer experience and has been instrumental in modernizing TYPO3's development practices.
\nAndrew Berry has been a member and contributor in the Drupal community since 2006. He is also the VP of Technology at Lullabot, where teams rely on DDEV for local development. When not doing Drupal and DDEV, Andrew spends his time working on home automation and related open source projects.
\nRandy is the original maintainer of DDEV, enjoying it since 2016. He has deep roots in the Drupal community and has done loads of traveling by bike.
\nImproved governance is one of our key long-term goals for the project, and was a key goal for 2025. We know that this will be an ongoing process that we'll have to grow into, and we invite your participation. We meet every two months as a group, and the entire community is invited. Subscribe to the meeting announcements and summaries and ask for a calendar invitation if you'd like. These meetings are also announced in the monthly DDEV Newsletter.
\nOf course the key long-term goal is sustainability in general. We don't want to depend on any single maintainer, and we want to ensure that DDEV can continue to thrive and grow for years to come. Financial sustainability is a key part of that, but just one part. Read more about our path to sustainability.
\nDo you have additional ideas, suggestions, or insight into how DDEV's future could be more sustainable? We would sure love to hear from you! Or get active and join our DDEV Advisory Group.
\nDo you have questions or want to talk (about sponsoring or anything else)? Contact us! or join us in Discord.
\nHave you signed up for the monthly DDEV Newsletter? We'd love to have you.
\nClaude Code was used for editing and formatting in the blog post.
\n"},{"id":"https://ddev.com/blog/power-through-blackouts-ddev-community-support","url":"https://ddev.com/blog/power-through-blackouts-ddev-community-support","title":"Power Through Blackouts: How DDEV Community Helped Me in Ukraine","content_html":"Since Russia's full-scale invasion of Ukraine in 2022, Russian forces have been systematically targeting our civilian power infrastructure. These attacks cause blackouts that can last hours or days, making it difficult to work, live normally, or even survive the winter. In November 2025, these attacks got much worse.
\nI'm a DDEV maintainer living in Kremenchuk, Ukraine. I'm Stanislav Zhuk, but you can call me Stas. I became a DDEV maintainer in October 2023, and you can read more about my background in the introduction post. I work a typical five-day week, usually from afternoon to evening, which lets me overlap with Randy's timezone.
\nThis is my story of how your support helped me keep working through Russian attacks on our infrastructure, and why it matters so much.
\nKremenchuk is an industrial city in central Ukraine on the banks of the Dnieper River.
\nIn November 2025, Russians heavily attacked Kremenchuk's infrastructure. We had no electricity, water, or central heating for almost a whole day. Now we have blackouts every day - typically 1.5-2 hours with electricity, then 3-5 hours without it, and the cycle repeats. There's no sign of when this will get better.
\nThis is the reality we live in: you can never know when and where the next strike will happen. I read the news every day, and every day civilians die. I try to focus on other things to stay sane, but the threat is constant.
\nWorking during these conditions needs careful planning. For work, I need to keep my laptop running and have internet with acceptable speed. For home, I need to power the refrigerator during long blackouts so food doesn't spoil. Some things I cannot control: water supply and central heating. I have an electric radiator, but it uses too much power to run from battery stations during long outages.
\nWhen Russian attacks on our power infrastructure started in fall 2022, I wasn't ready for long blackouts. I had a couple of small powerbanks for mobile phones and bought several portable lanterns so I wouldn't sit in the dark. I still use them.
\n\nThe market was crazy at that time - prices went very high and it was hard to find equipment. I didn't buy anything big then, just waited for things to calm down.
\nAfter the first wave of attacks on Ukrainian infrastructure ended and prices went back to normal, I bought two more powerful powerbanks to run my laptop. They got me through 2023 and the first half of 2024. Now I use them to charge mobile phones.
\n\nThe second problem was internet during blackouts. I switched to a fiber optic provider and bought two UPS units: SKE UPS Mini POE 60W for the router and Marsriva Smart Mini UPS KP5 for the ONA (Optical Network Adapter). Together they give me stable internet for about 8-9 hours when there's no power.
\n\n\nIn 2024, Russian attacks on infrastructure came back. Thanks to all of you, an EcoFlow DELTA 2 was sponsored ($1,170), and I bought it at a local shop. This changed everything. Instead of dealing with multiple devices and cables, I just plug one socket into the EcoFlow and have power for the whole room: laptop, external display, lights, and more.
\nThis made things much easier. With one power station, I could work through blackouts without constantly worrying about my battery dying.
\nThe Russian attacks in November 2025 are much harder than in 2022. They strike more often and cause more damage to our infrastructure.
\nYou helped again. An EcoFlow DELTA 3 ($910) was sponsored. The market changed, and these units got cheaper. Now I don't worry about whether DELTA 2 can charge fully in the short windows when we have electricity. I can power the refrigerator during very long blackouts and work on DDEV at the same time.
\n\nHaving two power stations makes me feel much more confident during these hard war times. I can:
\nYour support has been really important. Without these power stations, I couldn't do my work as a DDEV maintainer during blackouts. You didn't just give me equipment - you gave me the ability to keep contributing and keep helping the project and its users, even in these hard times.
\nThank you for supporting Ukraine and understanding how important our situation is to Europe and the world. Your support means more than just equipment - it's a reminder that we're not alone.
\nThis support is more than just hardware. It shows what open source communities can be: people helping each other through hard times, so we can keep building together.
\nI don't know when things will get better. But I know I have what I need to keep working, thanks to you. Every contribution makes a real difference in keeping DDEV maintained and supported.
\nIf you want to support DDEV, visit DDEV's GitHub Sponsors page.
\nI'm grateful for everyone who supports DDEV. Your help lets me keep working, keep contributing, and keep helping this community grow, even in the darkest times.
\nThis article was edited and refined with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/fritzbox-routers-and-ddev","url":"https://ddev.com/blog/fritzbox-routers-and-ddev","title":"Fritz!Box Routers and DDEV","content_html":"DDEV is designed so that most people never have to change the configuration of their local workstation, and that includes not having to edit their hosts file. All the details are in DNS Name Resolution and Wildcards.
\nHowever, one particular brand of router, the Fritz!Box, has a different DNS configuration than most other routers, and it includes DNS Rebinding Protection that blocks local development domains.
\nTL;DR: If you use a Fritz!Box router, add ddev.site to the router's DNS Rebinding Protection exceptions.
When you first set up DDEV with a Fritz!Box router, you might encounter a failure to resolve the domain name when trying to access your *.ddev.site project, even though your site is accessible via the 127.0.0.1 direct URL given in ddev describe. This happens because Fritz!Box routers enable DNS Rebinding Protection that suppresses DNS responses pointing to your own network.
DNS Rebinding Protection is a security feature that guards against a sophisticated attack technique. In a DNS rebinding attack, a malicious website tricks your browser into accessing services on your local network (like your computer, router, printer, or other devices) by manipulating DNS responses. Here's how the attack works:
\n127.0.0.1 or 192.168.1.1Fritz!Box routers protect against this by blocking DNS lookups that resolve to local IP addresses like 127.0.0.1, 192.168.x.x, and other private network ranges. While this security feature protects against real attacks, it also blocks legitimate local development domains (like DDEV's ddev.site).
DDEV's use of 127.0.0.1 and the ddev.site domain is intentional and safe—it's not a DNS rebinding attack. Here's why:
127.0.0.1), not from external networksThe Fritz!Box can't distinguish between a legitimate local development tool like DDEV and a potential DNS rebinding attack—both use domain names that resolve to 127.0.0.1. That's why you need to explicitly allow ddev.site as an exception.
Rather than relying on DDEV's hosts file fallback, it's better to solve the underlying DNS problem by configuring your Fritz!Box router to allow the ddev.site domain.
Here's how to fix it:
\nhttp://fritz.box and http://192.168.178.1ddev.site to the exceptions listAfter making this change, DDEV's DNS resolution will work as expected, and you can access your projects using the standard .ddev.site URLs.
If you prefer not to modify your router settings, or you do not have access to them, you have two other options:
\n1.1.1.1)The router configuration approach is recommended because it preserves DDEV's design principle of not requiring system file modifications.
\nddev.site to be added to their exceptionsIf you want to request that AVM (the makers of Fritz!Box) consider adding ddev.site to their default DNS Rebinding Protection exceptions, consider contacting their support team. A friend of DDEV has already done this, but more requests may help.
Thanks to Ingo Schmitt for investigating and demonstrating the fix. Thanks to npostnik for already having documented this in a German blog post.
\nWe'd love to hear your experience. Join us in Discord or open an issue if you have success (or failure 😀). We're always trying to make DDEV better for you.
\nAssisted in compilation and editing by Claude Code.
\n"},{"id":"https://ddev.com/blog/ddev-november-2025-newsletter","url":"https://ddev.com/blog/ddev-november-2025-newsletter","title":"DDEV November 2025 Newsletter","content_html":"💕 A Love Letter to DDEV!
\nAs the year winds down, it's time to get serious about 2026 planning 📋. We'll have a meeting in the next few weeks talking about priorities for the new year. See some WIP proposals and contact us any time with your opinions↗ or to get an invitation to the meeting.
\nJoin us for upcoming training sessions for contributors and users.
\nNovember 20, 2025 at 10:00 US ET / 16:00 CET — Using DDEV on Windows with WSL2\nAdd to Google Calendar •\nDownload .ics
\nJanuary 22, 2026 at 10:00 US ET / 16:00 CET — Mutagen, syncing, problems, upload_dirs for direct bind mounts\nAdd to Google Calendar •\nDownload .ics
\nFebruary 26, 2026 at 10:00 US ET / 16:00 CET — Git bisect for fun and profit\nAdd to Google Calendar •\nDownload .ics
\nMarch 26, 2026 at 10:00 US ET / 15:00 CET — Using git worktree with DDEV projects and with DDEV itself\nAdd to Google Calendar •\nDownload .ics
April 23, 2026 at 10:00 US ET / 16:00 CEST — Creating, maintaining and testing add-ons\n2026-updated version of our popular add‑on training. Previous session recording↗\nAdd to Google Calendar •\nDownload .ics
\nZoom Join Info:\nLink: Join Zoom Meeting\nPasscode: 12345
\nThe DDEV Foundation now has a formal board. Join us for our annual extended advisory group and board meeting (public; all are welcome): Watch for a blog post about the new board members! (Or sneak peak by reading the meeting notes.)
\nAs of today, the monthly sponsorship commitment is up to 70% of our goal, at $8,376. Thank you! That's up from 69% and $8,231 last month. → Become a sponsor↗
\nCompiled and edited with assistance from Claude Code and Copilot.
\n"},{"id":"https://ddev.com/blog/ddev-october-2025-newsletter","url":"https://ddev.com/blog/ddev-october-2025-newsletter","title":"DDEV October 2025 Newsletter","content_html":"🚀 October brings new tools, community contributions, and training opportunities! 🌟\nHave ideas for DDEV in 2026? Contact us↗.
\nddev pull: Guide to using ddev pull for WordPress projects Read more↗Join us for upcoming training sessions for contributors and users. Guest blog contributions are welcome—learn more in our October 9th training session recording!
\nZoom Join Info:\nLink: Join Zoom Meeting\nPasscode: 12345
\nRandy will be presenting DDEV training at TYPO3Camp RheinRuhr in Germany November 7-9. Join us to learn about DDEV or connect if you're in the area!
\nAs of the v1.24.8 release the daily reminders of DDEV sponsorship status on ddev start have been successful, and we've had a number of new sponsors, thank you! Your contributions help us maintain and grow DDEV for the entire community. As of today, the monthly sponsorship commitment is up to 69% of our goal, at $8,231. Thank you! That's up from 66% and $7,958 last month. → Become a sponsor↗
Compiled and edited with assistance from Claude Code.
\n"},{"id":"https://ddev.com/blog/contributing-to-ddev-com","url":"https://ddev.com/blog/contributing-to-ddev-com","title":"Contributor Training: Contributing to ddev.com","content_html":"Here's our October 9, 2025 Contributor Training on contributing to ddev.com:
\nThe easiest way to fix errors or update content is to click the pencil icon on any blog post. This takes you directly to GitHub where you can make edits and create a pull request—all without checking out the repository locally.
\nCommunity blog posts are encouraged! Share your expertise, workarounds, and solutions. Start by opening an issue to discuss your blog post idea with the community. Then copy a similar blog post from src/content/blog and adapt it with your content.
Add your author profile to src/content/authors/ with your name, first name, and optional avatar URL. The avatar can be from Gravatar, the image directory, or your own site.
Run ddev start to preview your changes locally with hot module reloading at the URL shown in the startup output.
Every pull request automatically runs:
\nThe linter rules are defined in .textlintrc and enforce consistent usage of terms like \"ARM64\", \"Bash\", and \"phpMyAdmin\".
Each pull request automatically creates a preview deployment on Cloudflare Pages, allowing you and reviewers to see exactly how the changes will look on the live site.
\nYour suggestions to improve this blog are welcome. You can do a PR to this blog adding your techniques. Info and a training session on how to do a PR to anything in ddev.com is at DDEV Website For Contributors.
\nFollow the DDEV Newsletter for information about upcoming user and contributor training sessions.
\nClaude Code did almost all of the collation of the information in this blog from the YouTube video and the presentation materials.
\n"},{"id":"https://ddev.com/blog/ddev-on-linux-in-10-minutes","url":"https://ddev.com/blog/ddev-on-linux-in-10-minutes","title":"DDEV on Linux in 10 Minutes","content_html":"This screencast walks you through setting up a complete DDEV development environment on Linux, starting completely from scratch. Whether you're new to DDEV or local development environments in general, this step-by-step guide will get you up and running quickly.
\nHere's the video table of contents (opens on YouTube):
\nHere's what happens in this screencast. You can do it yourself in just a few minutes. We're using DDEV's get-started, but of course there is far more detail in the DDEV docs, explaining how to use other distros or other install techniques.
\nInstall Docker CE. Use the apt repository technique from Docker's docs.
sudo usermod -aG docker $USER\nnewgrp docker\nInstall DDEV, using the apt repository technique from get-started.
ddev --version shows us being working fine with current stable.One-time mkcert -install helps your browser trust DDEV's HTTPS certificates.
Check out a project. I used rfay/d11, a trivial demo Drupal 11 project. (DDEV's quickstarts show many different project types with quick startup.)
\nddev config the project. Most of the time you can take the defaults. But most of use use a non-interactive command like ddev config --project-type=drupal11 --docroot=web.
ddev start the project. The first time on a new system you get the downloading of the Docker images.
ddev composer install for most projects
ddev launch and install with the web UI. On another project I might have used ddev import-db to load a database dump instead of doing an install.
sudo snap install --classic phpstorm
Open the project and set a breakpoint in web/index.php.
Click the \"Listen for PHP Debug Connection\" button in PhpStorm.
\nddev xdebug on
Visit the site in the browser. PhpStorm wakes up and asks us to map the code from the host/workstation side to the mount point in the container. The default usually works.
\nDebug, step over, step in, view variables, etc.
\nUse your own IDE, including VS Code: I used PhpStorm here, but VS Code works great.
\nThis demo used Ubuntu, but people use lots of distros: The differences for major platforms are shown in the docs, but the ideas are all the same, and people use all of them, including other Debian/Ubuntu, Fedora, and Arch Linux distros.
\nCross-Platform Compatibility: DDEV works the same on macOS, Linux, Traditional Windows, and WSL2, see Getting Started. Your whole team can work on their preferred environment without friction. See DDEV on Windows in 10 Minutes and DDEV on macOS from Scratch.
\nSupport for almost any PHP-based project and many Node.js environments DDEV supports development of so many different web environments, so you're not stuck with using separate tools for different CMSs.
\nMore Extensive Docs:
\n\nSupport the DDEV Project: DDEV is fully open-source and free to use, and run by the nonprofit DDEV Foundation. We ask you to help make us a sustainable project by sponsoring yourself or getting your organization to sponsor the project. Sponsor us on GitHub.
\nQuestions? Issues? We're here to help:
\nHave you signed up for the monthly DDEV Newsletter? We'd love to have you.
\nClaude Code was used in editing this blog and in preparing video outline, etc. Canva AI helped with the banner image.
\n"},{"id":"https://ddev.com/blog/ddev-upsun-platformsh-addon","url":"https://ddev.com/blog/ddev-upsun-platformsh-addon","title":"Upsun Support for DDEV in a New Add-on","content_html":"We're proud to announce that DDEV now has an Upsun add-on with extensive support for Upsun Flex and Upsun Fixed (Platform.sh-style configuration)!
\nAlthough DDEV has had ddev pull upsun support for Upsun projects for a couple of years, the add-on provides a more complete integration. It reads your Upsun configuration and automatically configures matching services in your local DDEV project, mirroring what your upstream project uses.
Getting started is straightforward:
\nddev config\nddev add-on get ddev/ddev-upsun\nddev start\n.upsun/config.yaml or .platform.app.yaml and configure your local environment automatically.For more details, see the README.
\nddev-upsun Add-on DoesWhen you do a ddev add-on get ddev/ddev-upsun the add-on reads your .upsun/config.yaml or .platform.app.yaml file and configures your DDEV project to match the upstream environment. This requires careful translation between Upsun's cloud architecture and DDEV's local environment.
ddev-upsun MattersAlthough many Upsun-hosted sites are basic nginx-fpm-database sites that DDEV has easily supported for years, the more complex ones have required special handling, like having to explicitly set PHP version, database type, etc. Now the add-on can do much of that for you.
\nFor example, if your Upsun project uses PostgreSQL 15 with Redis and a specific PHP version, previously you'd need to manually configure each in your .ddev/config.yaml. Now, the add-on detects and configures all of this automatically.
Upsun is a great platform for developers, and so many of you use it in the new \"Flex\" style and the previous \"Fixed\" style (Platform.sh-style). The add-on makes it easy to use both with a single add-on.
\nAnd of course Upsun is the lead sponsor of DDEV, so we always delight in making it work for you.
\nddev-upsunA sophisticated platform like Upsun has many possibilities, and we want most things to work on most projects. The scope will be limited to PHP for now. However, we want to add:
\nddev/ddev-redis add-on, for example).DDEV v1.24.8 (required) adds support for add-ons written mostly in PHP. Originally, all add-ons were written in Bash, with Go templating. It worked great for so many simple add-ons, but was way too complicated for sophisticated ones. PHP is a familiar and powerful language for many add-on developers, so now provides a much more expressive way to write complex add-ons.
\nThe ddev-platformsh add-on forced the issue on this. Every time we went back to it to maintain it we had to remember how Go templates worked and sort out complex Bash logic. Bash and Go templates are a lousy combination for maintainability. PHP should be much better. The ddev-upsun add-on will replace ddev-platformsh and supports both the Flex and Fixed Upsun configurations.
If you're currently using the ddev/ddev-platformsh add-on, you can migrate to ddev-upsun by removing the old add-on with ddev add-on remove ddev-platformsh and adding the new one with ddev add-on get ddev/ddev-upsun.
Thanks as always to Upsun for their financial support and for the great products, and for access to testing accounts. Their continued support makes DDEV development possible.
\nIf you're not already an Upsun user, try an Upsun free trial.
\nReviewed with assistance from DDEV Contributors and Claude Code.
\n"},{"id":"https://ddev.com/blog/claude-code-ai-pr-for-ddev-contributor-training","url":"https://ddev.com/blog/claude-code-ai-pr-for-ddev-contributor-training","title":"Contributor Training: Using Claude Code for a DDEV PR","content_html":"Here's our August 21, 2025 Contributor Training on using Claude Code AI for a DDEV PR:
\nmake staticrequired for static analysis.)CLAUDE.md file like DDEV's CLAUDE.md. Their docs claim that directives like this will be used properly to guide Claude's behavior, and it does help, but Claude does not seem to be strictly obedient and I often have to remind it of basic DDEV precepts.gh utility to do these things; you need to have that installed and configured.)t.Run() much more effectively for clearer subtests than I had ever done before. And it seems to use a bit more modern Go in general, so that's a plus./clear) at key points to limit the amount of context you're carrying forward and limit the number of tokens you're using.CLAUDE.md file, but without success. It also is complimenting me all the time and always agreeing with what I say. I haven't been able to calm that down either.In this demonstration (see screencast) we asked Claude to work on this issue about ddev launch and we asked it to create a PR for us. It generated this PR to resolve the problem. It was a trivial issue with a trivial solution, but the path to create it was similar to the path for a more complex situation.
This isn't an adequate place to discuss responsible AI, but:
\nYes, AI can make us really lazy. And it can make us stupid. Those valid concerns were also leveled against the calculator and the computer, of course. People thought that using the C language instead of assembler was giving up control. It was. We have to learn how to use this technology, use it right, and grow with it.
Build guardrails. Pay attention. Know what your code does. Enjoy the ride!
\nYour suggestions to improve this blog are welcome. You can do a PR to this blog adding your techniques. Info and a training session on how to do a PR to anything in ddev.com is at DDEV Website For Contributors.
\nFollow the DDEV Newsletter for information about upcoming user and contributor training sessions.
\nEdited with assistance from Claude Code and Codex; banner image generated by Claude.
\n"},{"id":"https://ddev.com/blog/ddev-september-2025-newsletter","url":"https://ddev.com/blog/ddev-september-2025-newsletter","title":"DDEV September 2025 Newsletter","content_html":"🚀 Our sprint to finish out 2025 has begun! 🌟\nTell us what you need for 2025–2026. Contact us↗.
\nWe're doing training again this season, all are invited. Some sessions are more focused on contributors and maintainers, and others for all users. This month we'll talk about the key magic of hostname resolution, debugging, and DNS. This is critical for everybody in the web world, not just for DDEV users. Join us whatever your experience level is.
\nSee the full schedule below.
\nSeptember 18, 2025 at 10:00 US ET / 16:00 CEST — Hostname Resolution and Debugging for DDEV Users
Add to Google Calendar •\nDownload .ics
October 9, 2025 at 10:00 US ET / 16:00 CEST — How and Why to Contribute a Blog to ddev.com
Add to Google Calendar •\nDownload .ics
November 20, 2025 at 10:00 US ET / 16:00 CET — Using DDEV in Windows WSL
Add to Google Calendar •\nDownload .ics
Zoom Join Info:
Link: Join Zoom Meeting
Passcode: 12345
Edited with assistance from Claude Code and Codex; banner image generated by Claude.
\n"},{"id":"https://ddev.com/blog/tailscale-router-ddev-addon","url":"https://ddev.com/blog/tailscale-router-ddev-addon","title":"Tailscale for DDEV: Simple and Secure Project Sharing","content_html":"I've found that DDEV's ddev share command is a great way to quickly share my local development environment. However, since it uses ngrok, it requires ngrok to be installed on the host system and generates a new, random URL every time unless you use a stable domain. As an alternative, I've created the ddev-tailscale-router add-on.
This add-on uses Tailscale, a VPN service that creates a private and secure network between your devices. It is free for personal use and doesn't require any additional software to be installed on your host system!
\nAs a result, you get a stable, human-readable URL for each of your DDEV projects, which you can access from any device on your Tailscale network.
\nI've found this approach to be particularly useful for:
\nThe ddev-tailscale-router add-on works by installing Tailscale directly into your DDEV project's web container using userspace networking. This approach provides better macOS compatibility and improved reliability compared to running a separate container. The add-on automatically connects to your Tailscale network and securely proxies requests to your project.
\n\nUpdate: Version 3.0.0 brought significant architectural improvements! The add-on now uses YAML-based configuration, improved command structure, and better error handling. If you're upgrading from an earlier version, see the migration instructions in the release notes.
\n
Before installing the add-on, you need to set up Tailscale:
\nTo get started, follow these steps:
\nFirst, set up your auth key (recommended approach):\nAdd the auth key to your shell environment:
\necho 'export TS_AUTHKEY=tskey-auth-your-key-here' >> ~/.bashrc\nsource ~/.bashrc\nReplace ~/.bashrc with ~/.zshrc if you use Zsh, or your relevant shell configuration file.
Alternatively, you can use interactive authentication after installation by running ddev tailscale login after your project starts.
Next, install the add-on:
\nddev add-on get atj4me/ddev-tailscale-router\nFinally, restart DDEV:
\nddev restart\nOnce installation is complete, you need to start sharing your project:
\nStart sharing your project:
\nddev tailscale share\nLaunch your project's Tailscale URL in browser:
\nddev tailscale launch\nGet your project's Tailscale URL:
\nddev tailscale url\nYour project's permanent Tailscale URL will look like: https://<project-name>.<your-tailnet>.ts.net. You can also find it in your Tailscale admin console.
To see all available commands and options, run ddev tailscale help. This will show you both the DDEV-specific shortcuts and all native Tailscale CLI commands that you can use.
The add-on offers two modes for sharing your project:
\nTo switch between modes:
\nShare publicly (accessible to anyone on the internet):
\nddev tailscale share --public\nShare privately (default, only accessible to your Tailscale devices):
\nddev tailscale share\nStop sharing:
\nddev tailscale stop\n\n\nNote: For public access, you need to configure your Access Control List (ACL) to enable Funnel. See the Tailscale Funnel documentation for details on setting up the required ACL policy.
\n
If you need to remove the add-on from your project:
\nStop any active sharing:
\nddev tailscale stop\nRemove the add-on:
\nddev add-on remove tailscale-router\nRestart DDEV:
\nddev restart\nHere are some additional resources that you might find helpful:
\nI hope this add-on helps streamline your development workflow! If you run into any issues or have suggestions for improvements, feel free to open an issue on the GitHub repository.
\nThis blog post was updated with the assistance of GitHub Copilot (Claude). I used it to help update the content based on the latest add-on changes, improve accuracy, and maintain consistency. The original version was written with assistance from Amazon Q and Google Gemini.
\n"},{"id":"https://ddev.com/blog/ddev-august-2025-newsletter","url":"https://ddev.com/blog/ddev-august-2025-newsletter","title":"DDEV August 2025 Newsletter","content_html":"🚀 Dive into August 2025 with DDEV! 🌟
This month: v1.24.7 release, Contributor Training starts up again, ddev-hostname security, new Windows installer, VS Code extension, DrupalCamp Colorado, Laracon US highlights, Passbolt environment, Tailscale troubleshooting, Magento 2 setup, DrupalCon Vienna, Ollama AI, and Board nominations.
ddev-hostname — Recent improvements securing host-file updates and future plans → Read more↗We're going to do training again this season, all are invited. Some sessions are more focused on contributors and maintainers, and others at all users. First up this month will be a session on using Claude Code to implement a DDEV feature or fix a bug. This will be using DDEV as an example, but probably anybody who works with code anywhere will profit from the approach.
\nSee the full schedule below.
\nAugust 21, 2025 at 10:00 US ET / 16:00 CEST — Using Claude Code AI in DDEV Development
Add to Google Calendar •\nDownload .ics
September 18, 2025 at 10:00 US ET / 16:00 CEST — Hostname Resolution and Debugging for DDEV Users
Add to Google Calendar •\nDownload .ics
October 9, 2025 at 10:00 US ET / 16:00 CEST — How and Why to Contribute a Blog to ddev.com
Add to Google Calendar •\nDownload .ics
November 20, 2025 at 10:00 US ET / 16:00 CET — Using DDEV in Windows WSL
Add to Google Calendar •\nDownload .ics
Zoom Join Info:
Link: Join Zoom Meeting
Passcode: 12345
\n\nWant just the 10-minute version of a DDEV WSL2 Install? Check out the New GUI Installer: Get DDEV Running on Windows in Just 10 Minutes for a quicker setup using the GUI installer.
\nUsing Linux or macOS? See DDEV on Linux in 10 Minutes or DDEV on macOS from Scratch.
\n
This screencast walks you through setting up a complete DDEV development environment on Windows using WSL2, starting completely from scratch. Whether you're new to DDEV, WSL2, or local development environments in general, this step-by-step guide will get you up and running quickly.
\n\n\nWe also did a DDEV Contributor/User Training on Windows with WSL2 in November, 2025 which did a casual walkthrough of this information.
\n
DDEV Fundamentals: Understanding what DDEV is and why it's become the go-to solution for local web development. The video explains that DDEV is a Docker-based local development environment aimed at web developers, mostly PHP and Node developers. Key benefits include:
\nWSL2 Setup and Benefits: WSL2 (Windows Subsystem for Linux version 2) transforms Windows development by providing a real Linux kernel running alongside Windows. The video covers the key advantages and considerations:
\nAdvantages:
\nConsiderations:
\nComplete Installation Process: The video covers every step of the installation process, including:
\nwsl --install commandReal-World Usage: Beyond just installation, you'll see DDEV in action with:
\nddev composer create-projectddev describe, ddev snapshot, and ddev export-dbProfessional Development Features: The video demonstrates advanced workflows including:
\nThis screencast follows the official DDEV WSL2 Installation Docs, but provides additional context, troubleshooting tips, and real-world examples to ensure your success.
\nHere's the video table of contents (opens on YouTube):
\n#ddev channel\n\nTL;DR: The new binary
\nddev-hostnameshipped with DDEV now takes care ofhostsfile editing when needed.hostsediting only happens when you use a non-ddev.siteURL.
One of the core principles of secure software development is the principle of least privilege: give a program only the minimal permissions it needs to do its job. With DDEV v1.24.7, we've taken a significant step forward in applying this principle to how DDEV manages hostname resolution on your development machine.
\nIf you don't use an alternate top-level-domain (TLD) or custom FQDNs, you won't notice any changes here. Read on, but DDEV will continue to work as it always has for most users.
\nMost of the time, DDEV projects work seamlessly with URLs like https://yourproject.ddev.site without any special setup. That's because DDEV maintains DNS records for ddev.site and all its subdomains that resolve to 127.0.0.1 (your local machine). As long as you have an internet connection, your browser can look up these hostnames automatically.
However, there are situations where DDEV needs to edit your system's hosts file (/etc/hosts on Linux/macOS or C:\\Windows\\System32\\drivers\\etc\\hosts on Windows):
127.0.0.1 resolution (DNS rebinding protection)additional_fqdns that aren't under ddev.siteproject_tld other than the default ddev.site or disabled DNS with use_dns_when_possible: falseFor a deeper dive into how DDEV hostname resolution works, see our detailed guide on DDEV name resolution and wildcards.
\nWhen DDEV does need to edit the hosts file, it requires elevated permissions (root on Linux/macOS, Administrator on Windows). This is the only thing DDEV does with elevated privileges—but from a security perspective, how we handle that elevation matters a lot.
Previously, the main DDEV binary—which handles containers, databases, files, and many other tasks—also had to manage hostname editing with elevated permissions. When you elevate privileges for one specific task (editing hosts files), you want to minimize what else that elevated process can do. The old approach meant a larger binary with more dependencies running with elevated permissions, increasing the potential attack surface.
DDEV v1.24.7 introduces a new dedicated ddev-hostname (and ddev-hostname.exe for Windows and WSL2) binary that handles hostname management exclusively. This specialized tool follows the security principle of least privilege in several important ways:
The ddev-hostname binary has been stripped down to do exactly one thing: manage hostname entries in your system's hosts file. It doesn't include Docker utilities, global configuration management, or the dozens of other features that the main DDEV binary provides.
By removing unnecessary dependencies, we shrunk the ddev-hostname binary significantly. More important, though, we eliminated dependencies on several libraries that were previously included in the main DDEV binary but aren't needed for hostname management.
Each removed dependency is one less potential entry point for security vulnerabilities in the elevated binary.
\nThe new implementation provides native elevation techniques for each platform instead of relying on third-party tools like gsudo.exe on Windows. This reduces external dependencies and gives us better control over the security model.
If you're using DDEV with Windows WSL2, you'll especially appreciate another improvement that comes with these changes. The new ddev-wsl2 package provides the Windows-side binaries you need, including ddev-hostname.exe and mkcert.exe, directly within your Linux distro.
This means you no longer need to install DDEV on the Windows side when using WSL2. The ddev-wsl2 package gives you everything you need for proper WSL2 integration with Windows hostname and certificate management.
To install it:
\nsudo apt-get update && sudo apt-get install ddev-wsl2\n# or sudo dnf install --refresh ddev-wsl2\nThis streamlines the WSL2 setup process significantly and ensures you always have the correct versions of these critical utilities.
\nAs a DDEV user, these changes are largely transparent—your development workflow remains the same. But under the hood, you're now benefiting from:
\nThese improvements reflect our ongoing commitment to making DDEV not just powerful and easy to use, but also secure by design. By applying established security principles like least privilege and minimal attack surface, we're building a development tool that you can trust with your local environment.
\nDDEV v1.24.7 with these security improvements is available now. If you're using WSL2, install the new ddev-wsl2 package.
As always, we'd love to hear your feedback on these changes. Join us on Discord to share your experience or ask questions about the new hostname management approach.
\nFollow our blog, LinkedIn, Mastodon, and join us on Discord. And we'd love to have you sign up for the monthly newsletter.
\n"},{"id":"https://ddev.com/blog/watch-new-windows-installer","url":"https://ddev.com/blog/watch-new-windows-installer","title":"New GUI Installer: Get DDEV Running on Windows in Just 10 Minutes (Video)","content_html":"\n\nUsing macOS or Linux? See DDEV on macOS from Scratch or DDEV on Linux in 10 Minutes.
\n
Tired of those complex PowerShell scripts we used to provide to get DDEV running on Windows? The new GUI installer changes everything.
\nIn DDEV v1.24.7 we've eliminated the complexity of Windows setup. What used to require a privileged PowerShell script and manual WSL2 configuration now takes just a few clicks.
\n✅ Almost No Command Line Required for Setup
\n✅ Handles WSL2 Setup Automatically - No more manual configuration
\n✅ Works with Your Preferred Docker Setup - Docker Desktop, Rancher Desktop, or Docker-CE, in WSL2 or with Traditional Windows
\n✅ Beginner-Friendly - Perfect for users new to DDEV
The new installer supports:
\nWatch me transform a fresh Windows machine into a fully functional DDEV development environment in about 10 minutes:
\nWhat you'll see:
\nThis setup process is detailed in Get Started - Windows and explained further in the official docs.
\n🚀 Download the new Windows installer
\nCross-Platform Compatibility: DDEV works the same on macOS, Linux, Traditional Windows, and WSL2, see Getting Started. Your whole team can work on their preferred environment instead of fighting about it. It supports development of so many different web environments, so you're not stuck with using different tools for different CMSs.
\nSupport the Project: DDEV is fully open-source and free to use, and run by the nonprofit DDEV Foundation. We ask you to help make us a sustainable project by sponsoring yourself or getting your organization to sponsor the project. Sponsor us on GitHub.
\nQuestions? Issues? We're here to help:
\n\nHave you signed up for the monthly DDEV Newsletter? We'd love to have you.
\n"},{"id":"https://ddev.com/blog/testing-ddev-with-vmware-workstation-pro","url":"https://ddev.com/blog/testing-ddev-with-vmware-workstation-pro","title":"Testing DDEV with VMware Workstation Pro","content_html":"DDEV works in various environments, and it's often tested in virtual machines, but nested virtualization can be hard to set up and may impact performance.
\nIn 2024, VMware Workstation Pro became free for personal use.
\nThis guide shows how VMware Workstation Pro can be used to prepare environments for both Windows and Linux, where Docker and DDEV perform well even inside a VM.
\nWarning: Nested virtualization may not work on all systems:
\n\n\nVirtualized Intel VT-x/EPT is not supported on this platform. Continue without virtualized Intel VT-x/EPT? VMware Workstation does not support nested virtualization on this host. Module 'HV' power on failed. Failed to start the virtual machine.
\n
If this occurs, search for known workarounds specific to your hardware and BIOS/UEFI configuration. It worked out of the box for me on Arch-based Linux but did not work for Randy on Windows 11.
\nDownload and install VMware Workstation Pro. You must click on the link to the terms and conditions to accept them before downloading (checkbox is inactive by default). Packages are available for Windows and Linux.
\nOn Arch-based systems, install via:
\nyay -S vmware-workstation\nInitial configuration steps:
\nDownload the Windows 11 Disk Image (ISO) for x64 devices.
\nIn VMware:
\nTo apply additional low-level VM configuration, close VMware itself and use the script below:
\n#!/usr/bin/env bash\n\n# This script changes more settings than the GUI allows\n# Tested only on Arch-based Linux\n# Run it from the virtual machine directory\n\nvmx_file=\"$( (find ./*.vmx -maxdepth 1 -type f 2>/dev/null | head -1) || true)\"\n\nif [[ \"${vmx_file}\" == \"\" ]]; then\n echo >&2 \"Unable to find *.vmx file in the current directory.\"\n exit 1\nfi\n\n# from https://wiki.archlinux.org/title/VMware\ndeclare -A vmware_configs=(\n # 3D acceleration\n [\"mks.gl.allowBlacklistedDrivers\"]=\"TRUE\"\n # 5 buttons mouse for windows\n [\"mouse.vusb.enable\"]=\"TRUE\"\n [\"mouse.vusb.useBasicMouse\"]=\"TRUE\"\n # disable logging\n [\"vmx.scoreboard.enabled\"]=\"FALSE\"\n [\"logging\"]=\"FALSE\"\n [\"vmx.buildType\"]=\"release\"\n # paravirtual adapters\n [\"scsi0.virtualDev\"]=\"pvscsi\"\n [\"ethernet0.virtualDev\"]=\"vmxnet3\"\n # performance\n [\"MemTrimRate\"]=\"0\"\n [\"mainmem.backing\"]=\"swap\"\n [\"prefvmx.useRecommendedLockedMemSize\"]=\"TRUE\"\n [\"MemAllowAutoScaleDown\"]=\"FALSE\"\n [\"sched.mem.pshare.enable\"]=\"FALSE\"\n [\"prefvmx.minVmMemPct\"]=\"100\"\n [\"mainMem.partialLazySave\"]=\"FALSE\"\n [\"mainMem.partialLazyRestore\"]=\"FALSE\"\n # config\n [\"tools.syncTime\"]=\"TRUE\"\n [\"numvcpus\"]=\"4\"\n [\"cpuid.coresPerSocket\"]=\"2\"\n [\"memsize\"]=\"8192\"\n [\"vhv.enable\"]=\"TRUE\"\n [\"vpmc.enable\"]=\"TRUE\"\n)\n\nfor key in \"${!vmware_configs[@]}\"; do\n value=\"${vmware_configs[\"${key}\"]}\"\n line=\"${key} = \\\"${value}\\\"\"\n\n if grep -q \"^${key}\" \"${vmx_file}\"; then\n sed -i \"s/^${key}.*/${line}/\" \"${vmx_file}\"\n else\n echo \"${line}\" >> \"${vmx_file}\"\n fi\ndone\n\necho \"Updated ${vmx_file}\"\nPress \"Start up this guest operating system\".
\nIf Windows 10 was chosen as virtual machine type:
\ncmd, write regedit, open HKEY_LOCAL_MACHINE\\SYSTEM\\SetupLabConfigBypassSecureBootCheck, set 1BypassTPMCheck, set 1\nAfter the first reboot (installation is not done yet), don't select country in the initial setup:
\nOOBE\\BYPASSNRO (O letter, not number) directly in cmd. This is needed to force creation of a local account (I don't want to login anywhere here).After Windows boots:
\nD: drive with mounted tools, and run setup.exeWindows configuration:
\nRegistry configuration:
\n# Remove recommended applications from the Windows 11 start menu\nreg add \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\Cloud Content\" /v DisableWindowsConsumerFeatures /t REG_DWORD /d 1 /f\n# Disable automatic update for APPX applications in Microsoft Store\nreg add \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\WindowsStore\" /v AutoDownload /t REG_DWORD /d 2 /f\n# Disable Meltdown and Spectre fixes that slow down Windows\nreg add \"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management\" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f\nreg add \"HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management\" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f\n# Mouse cursor on the default button\nreg add \"HKEY_CURRENT_USER\\Control Panel\\Mouse\" /v SnapToDefaultButton /t REG_SZ /d 1 /f\n# Enable developer mode feature\nreg add \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\AppModelUnlock\" /t REG_DWORD /v \"AllowDevelopmentWithoutDevLicense\" /d 1 /f\n# Set old right click menu\nreg add \"HKEY_CURRENT_USER\\SOFTWARE\\CLASSES\\CLSID\\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\\InprocServer32\" /ve /f\n# Restart Windows Explorer\ntaskkill /f /im explorer.exe\nstart explorer.exe\n# disable reserved storage in Windows 11\ndism /Online /Get-ReservedStorageState\ndism /Online /Set-ReservedStorageState /State:Disabled\nShutdown the virtual machine, press \"Edit virtual machine settings\":
\nPress \"Start up this guest operating system\", and run inside Windows:
\nAt this point, the VM uses more disk space than needed. We can shrink guest on hosted platform:
\nAdd VMware Tools to PATH, run Terminal as admin:
\ncmd /c \"setx /M PATH \"\"C:\\Program Files\\VMware\\VMware Tools;%PATH%\"\"\"\nRestart PowerShell, and run Terminal as admin:
\nVMwareToolboxCmd.exe disk shrink c:\\\nWait until *.vmdk file at virtual machine location will be shrinked.
VMware Menu > VM > Snapshot > Take snapshot.
\nInstall Docker and DDEV. Create additional snapshots as needed.
\nFollow similar steps as for Windows, using a Linux ISO (e.g. Ubuntu).
\nInstall VMware Tools inside the guest:
\n# Debian-based:\nsudo apt-get install open-vm-tools-desktop\n# Fedora-based:\nsudo dnf install open-vm-tools-desktop\n# Arch-based:\nsudo pacman -S open-vm-tools\nIf display resolution is incorrect:
\nsudo systemctl restart vmtoolsd.service\nIf copy/paste from/to the host doesn't work:
\nvmware-user\n# or\nvmtoolsd -n vmusr\nReferences:
\nTo configure shared folders inside the guest:
\nmkdir -p ~/Shared\necho \"vmhgfs-fuse $HOME/Shared fuse defaults,allow_other 0 0\" | sudo tee -a /etc/fstab\nsudo systemctl daemon-reload\nsudo mount -a\nShrink Linux VM disk, take a snapshot, then proceed with installing Docker and DDEV. Create additional snapshots as needed.
\nIf you use a different setup that performs well, consider contributing a guest post to ddev.com or sharing your findings.
\n"},{"id":"https://ddev.com/blog/ddev-july-2025-newsletter","url":"https://ddev.com/blog/ddev-july-2025-newsletter","title":"DDEV July 2025 Newsletter","content_html":"Welcome to the July 2025 DDEV Newsletter
This month: Downgrading Terminus for old PHP, FrankenPHP, Advisory Group meeting and Governance proposal, Shopware Storefront and Admin Watchers, Writing your first Drupal 10 Functional Test, and more.
The PHP ecosystem is changing fast, with tools like FrankenPHP improving both performance and developer experience.
\nFrankenPHP is now officially supported by The PHP Foundation.
\nThis guide explains how FrankenPHP can be used with DDEV using ddev/ddev-frankenphp add-on.
\nThis blog shows an example 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.
\nThe ddev/ddev-frankenphp add-on is now officially maintained by the DDEV team! It has matured to production-ready status with full feature support.
\nddev add-on get ddev/ddev-frankenphp\nddev restart\nInstall pre-packaged extensions using the php-zts- prefix (see supported extensions):
# install mongodb and sqlsrv extensions\nddev config --webimage-extra-packages=\"php-zts-mongodb,php-zts-sqlsrv\"\nddev restart\nddev blackfire, ddev xdebug, ddev xhprof, ddev xhguiIf you want to suggest some feature or found a bug, feel free to open an issue.
\nUsing ddev-frankenphp-benchmark, I compared three setups:
\nnginx-fpm: DDEV's nginx-fpm web server with php-fpmfrankenphp: DDEV's generic web server with frankenphpapache-fpm: DDEV's apache-fpm web server with php-fpmSummary:
\nSoftware:
\nDDEV: v1.24.10
\nMutagen: disabled
\nPHP: v8.4
\nLaravel: v12.44.0
\nFrankenPHP: v1.11.1
\nDocker Engine: v29.1.3
\nOperating System: Manjaro Linux AMD64
\nKernel Version: 6.12.63-1-MANJARO
Hardware:
\nIntel i7 8750H (6 Core/12 Thread, 2.2 Ghz, Turbo 4.1 Ghz)
\n32 GB DDR4 2667 Mhz
\nSamsung 870 Evo SSD (530w/560r MB/s)
If you find DDEV (and its add-ons like FrankenPHP) useful, consider supporting its development. Thank you!
\n"},{"id":"https://ddev.com/blog/ddev-bundled-tools-using-custom-versions","url":"https://ddev.com/blog/ddev-bundled-tools-using-custom-versions","title":"How to Downgrade Terminus in DDEV's Web Container and Customize Other Bundled Tools","content_html":"This guest post is by DDEV community member and Drupal\ncontributor Bill Seremetis and sponsored by\nAnnertech.
\nDDEV comes bundled with a predefined set of tools, Pantheon's terminus being one of them.\nThe latest releases of terminus are not compatible with older PHP versions like PHP 8.1, though,\nso we needed to downgrade it inside DDEV's ddev-webserver Docker image.
This guide covers how to downgrade terminus and will also explain how to use the same technique to install\nadditional custom tools.
Please note there are many ways to install packages in a container. We will\ncover extra Dockerfiles\nhere, but also check webimage_extra_packages and dbimage_extra_packages in your\nconfig.yamlfor more details).
Terminus dropped\nsupport for PHP 8.1 in recent versions, but some of our\nprojects still use PHP 8.1. We had to downgrade the DDEV-bundled version of terminus for those\nprojects by using a custom Dockerfile:
# .ddev/web-build/Dockerfile.terminus\n# Terminus 4 drops support for PHP 8.1 which we still need\nARG TERMINUS_VERSION=\"3.6.2\"\nRUN curl -L --fail -o /usr/local/bin/terminus https://github.com/pantheon-systems/terminus/releases/download/${TERMINUS_VERSION}/terminus.phar && chmod +x /usr/local/bin/terminus\nterminus is just an example here, it could be any command you wish,\neither because you are running an older PHP version\nor the bundled version has a bug that ruins things for you.
You can obviously use the same techniques to install a variety of custom tools:
\n# .ddev/web-build/Dockerfile.fzf\n# fooscript relies on fzf\n# fooscript lists all your Pantheon projects using a fuzzy finder list\nARG FZF_VERSION=\"0.62.0\"\nRUN curl -s -L https://github.com/junegunn/fzf/releases/download/v${FZF_VERSION}/fzf-${FZF_VERSION}-linux_amd64.tar.gz | tar xvz -C /usr/local/bin/ && chmod +x /usr/local/bin/fzf\nwebimage and dbimageIf you like DDEV then you are welcome to contribute! You can join the Discord channel,\ncreate a new DDEV Add-on,\nor blog about how you use DDEV in your daily workflow.\nWe’re always happy to hear from you on any of our support channels.
\n"},{"id":"https://ddev.com/blog/ddev-june-2025-newsletter","url":"https://ddev.com/blog/ddev-june-2025-newsletter","title":"DDEV June 2025 Newsletter","content_html":"Welcome to the June 2025 DDEV Newsletter
This month: TYPO3 Community Budget Proposal (VOTE NOW), Randy is back from bikepacking, Running Old PHP versions, Vite and DDEV with WordPress, DDEV Architecture, and more.
Over the last nine years DDEV has grown from a tiny side project to a development environment and ecosystem that serves about 17,000 weekly developer-users and is critical to so many developers' workflows.
\nWe love this amazing open-source world that we're a part of. It's astonishing when communities can work together and of course the fact that we all stand on the shoulders of such giants like Linux, Debian, and hundreds of other projects.
\nWhat happens when a great project loses a key maintainer? A couple of years ago Bram Moolenaar, the maintainer of the Vim editor, passed away unexpectedly. Every project faces unexpected transitions, whether a maintainer steps back, changes focus, or, as happened with Bram, passes away. The Vim community did step up successfully, but that's not the only outcome possible for so many small projects.
\nWhat can we learn from Vim's experience, and how is DDEV positioned in comparison?
\nOne thing that the Vim community discovered was that Bram's work was truly a full-time job, even with their incredible and active community.
\nMany people may think that DDEV is just a tiny project that could carry on without its maintainers, but that might not be true. Right now support, maintenance, and improvements for DDEV use the full-time and consistent effort of two full-time maintainers. That's why you get the level of support and responsiveness you do. Both maintainers are currently paid, but perhaps not at a salary level that you would accept.
\nddev organization, and a couple of other people also have full administrative privileges. This is good; we're not dependent on one person. Both of us are fully trained and capable on all of the technologies and infrastructures used in DDEV's testing and release environments. (We would like to have more full-trained maintainers, unpaid or paid. If you love DDEV, come and join us and we'll train you.)Vim had serious challenges in all these areas, as there was only one \"owner\" of the GitHub project, and financial setups were very much ad-hoc. Bram was truly the \"owner\" of the whole project.
\nWe work hard to identify areas that are dependent on a single maintainer, and to resolve those. But it's a perpetual process!
\nAs of June, 2025, DDEV's monthly support is at the $7800 USD level. Our goal is $12,000. You can see this at any time on the top of ddev.com, and a full accounting updated daily is in the sponsorship-data repository. Our current bank balance is about $19,000 USD.
\nDo you have additional ideas, suggestions, or insight into how DDEV's future could be more sustainable? We would sure love to hear from you! Or get active and join our DDEV Advisory Group.
\nDo you have questions or want to talk (about sponsoring or anything else)? Contact us! or join us in Discord.
\nHave you signed up for the monthly DDEV Newsletter? We'd love to have you.
\n"},{"id":"https://ddev.com/blog/legacy-projects-with-unsupported-php-and-mysql-using-ddev","url":"https://ddev.com/blog/legacy-projects-with-unsupported-php-and-mysql-using-ddev","title":"Using DDEV to spin up a legacy PHP application","content_html":"This guest post is by DDEV community member and TYPO3 contributor Garvin Hicking.
\nIn my daily work, I develop TYPO3-based projects and also contribute to the TYPO3 CMS OpenSource project itself.
\nUsually this means working with actively supported and up-to-date PHP versions as well as database systems like MySQL/PostgreSQL/MariaDB.
\nJust recently I had to migrate a very outdated project: TYPO3 4.5, which utilized MySQL 5.5 and PHP 5.3. When that project was initially developed, it was done with XAMPP and later Vagrant-based VMs. This has been long superseded with using Docker and specifically DDEV for ease-of-use.
\nSo naturally I wanted to be able to use DDEV for the legacy project to get it working just as it is running on the (outdated) hosting provider's shared web servers.
\nI quickly faced three major issues:
\nThanks to the outstanding DDEV support on Discord, I was quickly able to find a way with minimal effort, just by creating very small custom, additional docker-compose YAML files.
\nOne advantage (of many) of using DDEV instead the underlying Docker Compose is that so many things are pre-configured and \"just work\". So I really did not want to migrate everything to Docker Compose on my own, do my custom routing, PHP-FPM integration and whatnot.
\nJust being able to \"bait and switch\" the PHP and DB container with a different base Docker image was all that was needed for me:
\nI created the base ~/legacyphp/.ddev/config.yaml file manually inside my ~/legacyphp project directory, setting legacyphp as the project name.
Note that I configured PHP and MySQL versions that are supported by DDEV for this first:
\nname: legacyphp\ntype: php\ndocroot: htdocs\nphp_version: \"8.3\"\nwebserver_type: apache-fpm\ndatabase:\n type: mysql\n version: \"8.0\"\nNext I created the very small file ~/legacyphp/.ddev/docker-compose.db.yaml in the same directory next to config.yaml:
services:\n db:\n platform: linux/amd64\n build:\n args:\n BASE_IMAGE: ddev/ddev-dbserver-mysql-5.5:v1.24.6\n entrypoint:\n - sh\n - -c\n - |\n cp /docker-entrypoint.sh ~/docker-entrypoint.sh\n sed -i '157s|.*|if false; then|' ~/docker-entrypoint.sh\n sed -i '175s|.*|echo mysql_8.0 >/var/lib/mysql/db_mariadb_version.txt|' ~/docker-entrypoint.sh\n exec ~/docker-entrypoint.sh\nThree things are noteworthy:
\nlinux/amd64 as the platform will require Rosetta to be available on the macOS ARM64 platformBASE_IMAGE is set to a DDEV db container of legacy Docker images that are still provided.entrypoint is a workaround to prevent DDEV complaining about a mismatching MySQL version after restarting the project. The small script \"tricks\" the DDEV inspection into believing, the version matches the one configured in .ddev/config.yaml.Using a different PHP version is just a few lines more work, because we are not replacing the whole web container of DDEV. Instead, we add an additional PHP container which is executed from the web container via port 9000.
This is done via the file ~/legacyphp/.ddev/docker-compose.php.yaml:
services:\n php:\n container_name: ddev-${DDEV_SITENAME}-php\n image: devilbox/php-fpm:5.3-work\n restart: \"no\"\n expose:\n - 9000\n labels:\n com.ddev.site-name: ${DDEV_SITENAME}\n com.ddev.approot: ${DDEV_APPROOT}\n working_dir: /var/www/html\n volumes:\n - \"../:/var/www/html\"\n - \".:/mnt/ddev_config:ro\"\n - ddev-global-cache:/mnt/ddev-global-cache\n - \"./php:/etc/php-custom.d\"\n environment:\n - NEW_UID=${DDEV_UID}\n - NEW_GID=${DDEV_GID}\n - DDEV_PHP_VERSION\n - IS_DDEV_PROJECT=true\n web:\n depends_on:\n - php\nNote here that we use devilbox/php-fpm with our needed version, and a bind-mount takes care the PHP container can access our main project root directory.
A special mount of ~/legacyphp/.ddev/php/ is included so that we can control the php.ini configuration, if needed. For example you could disable the OPCache+APC in case you're doing some legacy benchmarking that should not be falsified via caching, I created a very small file ~/legacyphp/.ddev/php/php.ini file with the contents:
# This is an example.\n# apc.enabled=Off\n# opcache.enable=Off\nTo execute PHP with our external PHP Docker image, I created the following file in ~/legacyphp/.ddev/apache/apache-site.conf:
<VirtualHost *:80>\n RewriteEngine On\n RewriteCond %{HTTP:X-Forwarded-Proto} =https\n RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d\n RewriteRule ^(.+[^/])$ https://%{HTTP_HOST}$1/ [redirect,last]\n SetEnvIf X-Forwarded-Proto \"https\" HTTPS=on\n\n Alias \"/phpstatus\" \"/var/www/phpstatus.php\"\n DocumentRoot /var/www/html/htdocs\n <Directory \"/var/www/html/htdocs\">\n AllowOverride All\n Allow from All\n </Directory>\n\n CustomLog /var/log/apache2/access.log combined\n ProxyFCGIBackendType GENERIC\n ProxyPassMatch ^/(.*\\.php(/.*)?)$ fcgi://php:9000/var/www/html/htdocs/$1\n DirectoryIndex /index.php index.php\n</VirtualHost>\nNote that if your document root is not htdocs you would need to adapt this name to your liking (like public or wwwroot or anything) in all occurrences of this file.
Now you can execute ddev start and then ddev launch to see your project up and running.
You could create a simple ~/legacyphp/htdocs/index.php file with <?php phpinfo(); ?> to verify the version.
Using ddev mysql will connect you to the MySQL 5.5 instance:
~/legacyphp> ddev mysql\nWelcome to the MySQL monitor. Commands end with ; or \\g.\nYour MySQL connection id is 5\nServer version: 5.5.62-log MySQL Community Server (GPL)\nYou can enter the PHP Docker container with a command like docker exec -it -u devilbox ddev-legacyphp-php bash if you need/want to execute PHP commands on shell-level, because the regular web container will run with the more recent PHP 8.3 version.\nSo if you need to perform composer CLI calls, be sure to do this within the matching PHP container.
Another thing to pay attention to is that if you for example want to utilize Mailpit with TYPO3's mail configuration, you can not use localhost:1025 as an SMTP server. localhost in PHP's case will be that devilbox PHP container, and not the DDEV web container. Instead you need to setup web:1025 as the hostname.
The devilbox PHP config has pretty much all available PHP extensions set up to use, but if you need specific imagemagick or other tools, you will have to either ensure these are executed on the web container, or make them available with customization of a different base Docker container that you can build yourself.
If you want to use Xdebug with this setup, you'll need to do more internal port forwarding in the docker-compose setup, which is beyond the scope of this article.
\nHaving shown you what is possible, I hope you will never need to use it, and you will always use well-supported and current software. :-)
\nThanks so much to the DDEV project for getting me across the finish line with just very little effort!
\n"},{"id":"https://ddev.com/blog/ddev-may-2025-newsletter","url":"https://ddev.com/blog/ddev-may-2025-newsletter","title":"DDEV May 2025 Newsletter","content_html":"Welcome to the May 2025 DDEV Newsletter
This month: special-networking guides, add-on maintenance tips, community tool highlights, and Randy’s bikepacking plans.
\n\nHeads-Up: Randy will be out bikepacking May 23–June 23, so updates may be limited; Stas will keep things moving!
\n
Maintaining a DDEV add-on is more than a one-time task. As DDEV evolves, so should your add-ons. This guide will help you stay in sync with recent changes and keep your add-ons up-to-date, reliable, and aligned with current standards.
\nAs part of preparing this guide, I also updated all official DDEV add-ons to reflect the latest recommendations and improvements.
\nRun the update checker script periodically in your add-on to verify it is up to date:
\ncurl -fsSL https://ddev.com/s/addon-update-checker.sh | bash\nHere are some high-level practices to follow:
\nddev-get topic to your GitHub repository if it should be discoverable by the wider community. (If your add-on is currently just an experiment or a fork, wait until it matures to add the topic.)#!/usr/bin/env bash instead of #!/bin/bash at the top of your command scripts, it's more portable and works better across different environments.ddev add-on get and ddev add-on remove should be idempotent. All files added via project_files and global_files must include a #ddev-generated stanza to support proper removalREADME.md change)DDEV development is moving fast, and new features are introduced regularly. Here are some recent updates you should be aware of:
\nYour add-on should encourage users to keep DDEV updated. The current recommendation is to add this stanza to install.yaml:
ddev_version_constraint: \">= v1.24.10\"\nThis ensures compatibility and resolves known issues, such as those related to the Mutagen Problem Report.
\nddev describe OutputWith DDEV v1.24.10, add-ons can now customize the output of the ddev describe with x-ddev.describe-* extension.
This feature is useful for showing credentials, URLs, or usage notes for custom services.
\nExample:
\n\nddev ssh ShellDDEV v1.24.10 also introduced the ability for add-ons to specify a custom shell for the ddev ssh -s my-service command using the x-ddev.ssh-shell extension.
services:\n my-service:\n x-ddev:\n ssh-shell: bash\nExample:
\n\nTo ensure your add-on works reliably, include a shell availability check in your Bats health checks (tests/test.bats):
health_checks() {\n # Verify that bash is available in the \"my-service\" container\n run ddev exec -s my-service command -v bash\n assert_success\n assert_output --partial \"bash\"\n # ... additional checks ...\n}\nWith DDEV v1.24.4, custom commands can now use the MutagenSync annotation.
You should use this annotation if your host or web commands modify, add, or remove files in the project directory. It ensures that file sync is handled correctly when Mutagen is enabled, preventing unexpected behavior or sync delays. (It does no harm and causes no performance issues if Mutagen is not in use.)
Example:
\n\nThe same DDEV v1.24.4 release introduced support for optional docker-compose profiles, which can be used by add-ons to offer more flexible configuration.
\nExample:
\nddev get DeprecationThe classic ddev get command is deprecated in DDEV v1.23.5 and replaced by ddev add-on get.
Huge thanks to @GuySartorelli for implementing this feature, and also for proactively updating many add-on README.md files. You've likely already seen a pull request for your add-on!
While all add-ons use the Bats framework for testing, many are still missing Bats libraries that simplify assertions and test writing.
\nConsider adopting these libraries to enhance test clarity and maintainability.
\nExample:
\n\nMake sure your add-on includes:
\n\nThese improve the quality of contributions and bug reports.
\nThe old maintained badge required yearly updates, which became a maintenance burden, especially for contributors with many add-ons. It's now replaced by a last commit badge.
To improve visibility and engagement on the DDEV Add-on Registry, add the registry badge to your README.md.
\nExample:
\n\nStarting with DDEV v1.23.5, you can now use ddev dotenv set to manage environment variables more cleanly. This allows your add-on to read custom environment variables defined in .ddev/.env.* files, and use them inside your docker-compose.*.yaml configuration.
This feature is especially useful for advanced setups where flexibility and dynamic configuration are needed.
\nExample:
\nIf your add-on needs a customized Docker image, the typical approach is to create a separate Dockerfile and configure your add-on to use it. However, for minor tweaks, you can take advantage of the dockerfile_inline option in your docker-compose.*.yaml file.
This approach lets you define a small Dockerfile directly in the YAML, avoiding the overhead of maintaining a separate file.
Examples:
\nTo keep your add-on repository tidy, safe, and aligned with community standards, consider adjusting the following GitHub settings:
\nGo to Settings → General in your repository:
\nGo to Settings → Rules → Rulesets:
\nmainKeeping your add-on current means less work for users and fewer issues for you to manage. Use this guide as your checklist and stay in sync with the DDEV ecosystem.
\nHave questions, suggestions, or something cool to share? Join the conversation in our Discord, open an issue, or reach out via email. Your feedback helps improve the tools we all rely on.
\nIf DDEV is helping you or your organization, please consider supporting its ongoing financial sustainability. Every bit helps keep the ecosystem growing and maintained.
\nHappy maintaining!
\n"},{"id":"https://ddev.com/blog/amd64-with-rosetta-on-macos","url":"https://ddev.com/blog/amd64-with-rosetta-on-macos","title":"Solving Intel-only AMD64/X64 problems on macOS with Apple Silicon","content_html":"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?)
\nAlmost 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.
\nApple 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).
\nBut 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.
\nIn 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.
\nplatform: 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.
\nWith 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\nAnd 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.
\nI 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\nimage: ${MSSQL_DOCKER_IMAGE:-mcr.microsoft.com/mssql/server:2022-CU18-ubuntu-22.04}\nplatform: linux/amd64\nSometimes 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, and the gifsicle npm package still does.
On an Apple Silicon machine you might get an ugly error like this when doing ddev npm install gifsicle:
npm error OrbStack ERROR: Dynamic loader not found: /lib64/ld-linux-x86-64.so.2\nnpm error\nnpm error This usually means that you're running an x86 program on an arm64 OS without multi-arch libraries.\nnpm error To fix this, you can:\nnpm error 1. Use an Intel (amd64) container to run this program; or\nnpm error 2. Install multi-arch libraries in this container.\nIn this situation, if you have Rosetta enabled and a Docker provider configured to support it, you can add a .ddev/docker-compose.amd64.yaml like this:
services:\n web:\n # Force the DDEV web image to run as `linux/amd64` on Apple Silicon with Rosetta\n platform: linux/amd64\nNow on ddev restart you'll be running an AMD64 web container and ddev npm install gifsicle will work just fine. And your colleagues who are on Intel processors will have no trouble with this configuration.
Test it with ddev exec arch, you'll now get x86_64.
(If you run into issues, try ddev debug rebuild to clear the old Dockerfile build cache.)
Since those techniques work so well, it seems unlikely that you'd want to run everything as AMD64, but DDEV on Intel... on Apple Silicon tells you how if you want to!
\nI 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!
\nDo 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.
\nI'd love to hear your experience. Join us in Discord or open an issue or send an email if you have success (or failure 😀).
\nThanks for your support and engagement with DDEV!
\n"},{"id":"https://ddev.com/blog/building-offramp-from-wordpress-with-ddev","url":"https://ddev.com/blog/building-offramp-from-wordpress-with-ddev","title":"Building an Off-Ramp from WordPress with DDEV","content_html":"TL;DR: DDEV was a huge force multiplier, enabling me to focus on writing a WordPress plugin to export WordPress content for use in Grav CMS. More information on the plugin can be found at the GitHub repository wp2grav_exporter.
\nPopular content managment systems like WordPress and Drupal store content in databases (MySQL/ PostgreSQL/ etc.). Grav CMS stores content and configuration in local files (Markdown and YAML respectively). Grav's simpler flat-file storage mechanism is one of the things that drew me to start dabbling with it.
\nWhile the recent shenanigans from Automattic's CEO accelerated my work, it wasn't the primary reason I developed this content exporter. I fell in love with Grav development back in 2018 when I first started writing a Drupal 7 exporter, and I wanted to port something similar over to WordPress. I value data portability, empowering the end user to control where their content is used! In the end, it's about giving options.
\nDDEV is a fantastic tool, and it is perfect for my PHP development workflow. It made spinning up two local developlment sites a breeze. I normally relish building and configuring my own automated environments, but DDEV makes it so simple to configure local environments. Additionally, DDEV comes with many \"quickstart\" configurations, meaning that popular CMS's like Drupal and WordPress work out of the box with nearly all settings ready to go.
\nI made two different directories, one for WordPress and the other for Grav. After running ddev config on each respective directory, ddev start on each starts serving the content.
I installed DemoPress in the WordPress environment to help generate random test content and users to export.
\nStep debugging is imperative while trying to inspect content in-flight. Xdebug needed to listen on two different ports to avoid collisions between the two sites, and the DDEV docs are informative on how to configure this. I personally use VS Code, but other IDE's should work just as well, too. Step debugging was crucial to finding appropriate data structures and information I needed my converter plugin to use in a Grav site.
\nThe wp2grav_exporter plugin is the resultant labor of love. It automatically exports:
\nAdditional screenshots of example content exports can be found at the plugin's GitHub page.
\nAfter running the export, content was drag-dropped between my two DDEV directories, and I could immediately test how content looked. The exported post configurations are encompassed in a Grav plugin, so the end user is free to use whatever theme they want!
\nDDEV has saved me countless hours with its easy setup and dependability. If you haven't yet taken it for a test spin, I can't recommend it enough!
\nFind an issue with my exporter? Submissions are welcome at the project's issue queue!
\n"},{"id":"https://ddev.com/blog/ddev-expose-node-app-on-subdomain","url":"https://ddev.com/blog/ddev-expose-node-app-on-subdomain","title":"Exposing a Node.js App Over HTTP / HTTPS on a Subdomain in DDEV","content_html":"Have you ever needed to run a separate Node.js application alongside your main site in DDEV, and serve it securely\nover ports 80 and 443 on a custom subdomain? While DDEV has built-in mechanisms for exposing additional ports,\nsometimes you need more control, especially if you want to expos it through a domain like\nfrontend.example.ddev.site instead of a port-specific URL. This is where Traefik, bundled with DDEV,\nbecomes incredibly powerful.
In this post, we’ll walk through how to configure DDEV and Traefik to proxy requests from a subdomain directly\nto your Node.js app on port 3000 within the DDEV web container.
\n![](\"/img/blog/2025/04/sample-wordpress-grav-page-render.png\"){kind=link}
web_extra_exposed_ports?DDEV's' web_extra_exposed_ports feature is great for making your service accessible via a specific port\n(e.g., (3000)). However, it doesn’t magically set up a subdomain for you to use on standard web ports (80/443).\nIf you want frontend.example.ddev.site to map to your Node.js app over HTTPS, you need a reverse proxy rule.\nThat’s where Traefik comes in.
.ddev/config.yamlIn your project’s .ddev/config.yaml, define the project name and the additional hostname you want to use. For example:
name: example\n\nadditional_hostnames:\n - frontend.example\n(Optional) You can still use web_extra_exposed_ports to expose the Node.js port if you want:
\nweb_extra_exposed_ports:\n - name: node-app\n container_port: 3000\n http_port: 3000\n https_port: 3001\nHowever, for a subdomain over standard web ports, the critical part is the next step with Traefik.
\n:::warning\nThis technique does not work in DDEV v1.25.0. That release included a major Traefik refactoring that did not yet cover project-level configuration. Upgrade to v1.25.1 or later, which includes a fix for this and other issues introduced in v1.25.0.\n:::
\nIn your project's .ddev/traefik/config folder add a file named frontend.yaml. In frontend.yaml, you’ll define two routers—one for HTTP (port 80) and one for HTTPS (port 443)—and\na service that points to the Node.js app on port 3000.
http:\n routers:\n # Router for HTTP (port 80)\n example-web-80-http-frontend:\n entrypoints:\n - http-80\n rule: Host(`frontend.example.ddev.site`)\n service: \"example-web-3000\"\n ruleSyntax: v3\n tls: false\n priority: 100\n\n # Router for HTTPS (port 443)\n example-web-80-https-frontend:\n entrypoints:\n - http-443\n rule: Host(`frontend.example.ddev.site`)\n service: \"example-web-3000\"\n ruleSyntax: v3\n tls: true\n priority: 100\n\n services:\n # The custom service that routes to your Node app\n example-web-3000:\n loadbalancer:\n servers:\n - url: http://ddev-example-web:3000\nHere’s what’s happening:
\nfrontend.example.ddev.site, it passes the request to the example-web-3000 service.http://ddev-example-web:3000 is the internal address of the web container running on port 3000.Run:
\nddev restart\nDDEV will pick up your new Traefik configuration, and you should now be able to access your Node.js application at:
\nddev launch https://frontend.example.ddev.site\nNo more messing with non-standard port numbers in your URLs!
\nBy leveraging Traefik's routing capabilities, you can expose any service running in the web container on standard HTTP/HTTPS ports and map it to a dedicated subdomain. This approach keeps your development environment clean, user-friendly, and closer to production-like URLs.
\nIf you’ve followed these steps, your Node.js application will be served seamlessly over frontend.example.ddev.site.
Further Reading
\n\nDo You Have a Favorite DDEV Recipe? Contribute It!
\nWe welcome community contributions to the DDEV blog and would love to have yours. The ddev.com repository has full details, and there's even a training session on how to do it. It's all just Markdown and we'll help!
\n"},{"id":"https://ddev.com/blog/ddev-april-2025-newsletter","url":"https://ddev.com/blog/ddev-april-2025-newsletter","title":"DDEV April 2025 Newsletter","content_html":"Spring has Sprung in Palisade, Colorado!
\nDDEV v1.24.4 was released with the new XHGui profiling feature (funded by TYPO3 Community Ideas Budget!).
\nDDEV Notes and News
\nddev.site DNS resolution. It’s especially helpful for users who experience issues with DNS, and it could also eliminate the need for DDEV to modify the /etc/hosts file in those cases. We still hope to explore this in 2025!We welcome your contributions to the blog! A number of community members have contributed blog articles demonstrating their use of DDEV to solve problems, and we welcome your contributions. It's easy, it's just Markdown, and full instructions are at the ddev.com repository.
\nThanks for subscribing to the newsletter! We love to have this way to keep in touch. If you're not getting it yet by email, please sign up at ddev.com/newsletter.
\nGreat News: Sponsorship Level is Increasing! According to our open sponsorship feed our total monthly average income went up from $7099 to $7639 since March 1, a $540 bump in one month. Wow, you're awesome, thank you! If your organization or you aren't on the bandwagon yet, join us to help make DDEV sustainable. GitHub Sponsors is great, but we also do support contracts, invoicing, PayPal — anything that works for you! Our goal is $12,000/month, so we're more than halfway there. Special thanks to new $100/month sponsors @fullfatthings, @liip, @andreas-anwesoft, @wearrudder!
\nTHANKS to all of you who are supporting DDEV’s path to sustainability and who have gotten your organizations to do so.
\nWant to keep up as the month goes along? Follow on
\n\nHappy April from Randy Fay, DDEV Project Lead. It's a delight to collaborate with you!
\n"},{"id":"https://ddev.com/blog/drupalcon-atlanta-2025","url":"https://ddev.com/blog/drupalcon-atlanta-2025","title":"DDEV at DrupalCon Atlanta 2025","content_html":"While I didn’t speak at any formal sessions this year, I had the chance to lead several Birds-of-a-Feather (BoF) discussions:
\nphp or phpstan or phpunit properly inside a Docker container (like the DDEV web container), so it's hard to use the nice VS Code integration with those tools. DDEV Community member Mike Anello was present and talked about his favorite usage, which involves the Remote Explorer extension. In his long-form Drupal trainings at DrupalEasy he teaches folks to use Remote Explorer with DDEV and work inside the web container all the time, and that solves the problem, but it is different from what DDEV users normally do. (PhpStorm knows how to use tools and interpreters inside the container, so doesn't have this problem.) Mike has presented his technique many times as Maximizing Visual Studio Code with DDEV.git bisect technique went well and we all had a good time. It was based on the Florida Drupal Camp presentation \"Divide and conquer: A systematic approach to troubleshooting issues\". Here's the git-bisect-example repository for hands-on practice.The highlight of every DrupalCon is helping new contributors on Contribution Day, a whole day where folks get help contributing for the first time to code, documentation, or marketing. I was able to help a few people, and of course, was the resident DDEV and DrupalPod expert.
\nI published an invitation to meet one-on-one and a few people took advantage of meeting in person to look at their DDEV issues. It was great to meet them!
\nBernardo Martinez shared a room and a DrupalCon ticket, making this whole thing possible.
\nPlatform.sh was kind enough to fund the airline ticket to Atlanta.
\nThanks to both of you! I wouldn't have made it without both those things.
\n"},{"id":"https://ddev.com/blog/xhgui-feature","url":"https://ddev.com/blog/xhgui-feature","title":"XHGui Feature Makes Profiling Even Easier","content_html":"Thanks to sponsorship from the TYPO3 Community Budget Ideas, DDEV now includes XHGui support for its XHProf profiling. This brings a much-improved experience with a consistent, browser-based interface.
\nDDEV has had XHProf profiling for some time, and many in the community have loved it, but it had a few flaws; the list of profiling runs was ugly and uncoordinated, and the list was lost on ddev restart.
However, the longstanding XHGui project was out there for years, and it made much more sense.
\nWith XHGui, you can now track performance bottlenecks with a clean interface, persistent data, and detailed breakdowns of CPU and memory usage.
\nIn DDEV v1.24.4+ you can switch to the XHGui profiling mode (permanently) with
\nddev config global --xhprof-mode=xhgui && ddev restart\nStart profiling with
\nddev xhgui on\nVisit a few pages in your app to collect profiling data, then
\nddev xhgui launch\nIn general, click one of the GET or POST links and follow it in to explore detailed CPU and memory usage breakdowns.
If you have questions, join us in one of the DDEV support venues, especially Discord and we'll work it through with you.
\nThe DDEV Docs on XHProf have some good starters, but your suggestions are welcome!
\nHere's a quick demonstration of using XHGui with a TYPO3 site in DDEV.
\nSerious thanks are due to:
\nTry it out today and let us know how it goes — your feedback helps shape the future of DDEV! Join us in the DDEV support venues if you want to talk about XHGui and profiling.
\n"},{"id":"https://ddev.com/blog/sponsor-thanks","url":"https://ddev.com/blog/sponsor-thanks","title":"Thanks to our Amazing Sponsors!","content_html":"We just want to take a moment to thank all of the amazing sponsors of the DDEV open source project. All of you reading this know that we've been working for years now to make DDEV a financially sustainable project, so it can serve you into the future. So many have responded to that call. Thank you!
\nEven though we're going to mention the biggest sponsors first, we want all of you to know that your sponsorship matters too, and with care we can expand to many, many small sponsors to ensure DDEV's resilience and sustainability.
\nHere are some of many sponsors who help out via GitHub Sponsors.
\n\nThe open-source community has lots of folks helping out multiple collaborators. In our case, MacStadium provides us testing resources, and JetBrains provides a subscription to their IDE products, thanks!
\nBut we never forget Docker. Docker has adopted us in the Docker-Sponsored-Open-Source (DSOS) program for a few years now, and this means that all of your image pulls are sponsored in that project. You may know that normal image pulls will be strictly limited starting April 1, 2025, but because of the DSOS, users of DDEV won't hit that restriction.
\nAnd please don't forget that the open-source Docker project underlies every single Docker provider. It doesn't matter if you're using OrbStack or Lima or Docker Desktop or whatever, they're all built on top of the amazing Docker open-source project.
\nWe recently set up a full updated JSON feed that can be used to see exactly where DDEV's sponsorship comes from and how we're doing. You can see the latest data any day in the all sponsorships feed. And Mark Conroy has built a web component that can be used to show where we're at on any website. Thank you!
\nWe have almost too many ways that you can sponsor, but we want to make it easy for you and your organization.
\nIs your name or your organization's name missing here? It's easy to get it here. How much does DDEV's support and ongoing maintenance mean to your organization?
\n(If I made a mistake and left you out, let me know and I'll edit this.)
\nDo you have questions or want to talk (about sponsoring or anything else)? Contact us! or join us in Discord.
\n"},{"id":"https://ddev.com/blog/ddev-march-2025-newsletter","url":"https://ddev.com/blog/ddev-march-2025-newsletter","title":"DDEV March 2025 Newsletter","content_html":"Happy March!
\nDDEV v1.24.3 was released earlier than planned for two major reasons: the new generic web server type allows Node.js and other interesting possibilities, and an upcoming Docker engine release was going to be incompatible with current Mutagen version. We encourage you all to upgrade because of this upcoming incompatibility, thanks!
Open-Source For The Win: See the details about how a future incompatibility with the Docker engine was pre-emptively caught and fixed, Open Source for the Win!
\nWeb-based DDEV Add-on Registry is now live! Try it out at https://addons.ddev.com and check out the introduction blog.
\nTYPO3 Community Budget Ideas: Please vote!: We applied for the Q2 approval process to fund a great feature for DDEV, supporting mDNS as a domain-name resolution technique. If you're a member of the TYPO3 Association, you should have received an email to vote on this. We'd appreciate your vote!
\nPlatform.sh has transferred domain names to DDEV: Thanks again to Platform.sh for their ongoing support. As a part of the process in change of their support, they have transferred control of the ddev.com and ddev.site domain names to the DDEV Foundation.
DDEV Notes and News
\nFunding DDEV to allow both maintainers to work full-time on DDEV: We need your help and your organization's help! Let me know if you need help getting this into your budget! Our key financial goal is to fully fund @stasadev so he can work exclusively on DDEV. We've slipped back in recent months. We need about $3700/month in increased pledges from organizations and individuals. See Full information about supporting DDEV. We’re happy to invoice you, happy to do a call discussing this, and would love it if you’d include DDEV in your budgeting process for this year or next. (Our current status: We receive about $6000/month, have been spending about $7000/month. Bank balance is about $9,000, up from $6,000 last month (progress!).)
\nTHANKS to all of you who are supporting DDEV’s path to sustainability and who have gotten your organizations to do so.
\nWant to keep up as the month goes along? Follow on
\n\nHappy March from Randy Fay, DDEV Project Lead. It's a delight to collaborate with you!
\n"},{"id":"https://ddev.com/blog/ddev-addon-registry-introduction","url":"https://ddev.com/blog/ddev-addon-registry-introduction","title":"DDEV Add-on Registry Introduction","content_html":"We're excited to introduce https://addons.ddev.com, a central hub where the community can explore, contribute to, and enhance the collection of DDEV add-ons.
\nThe source code is available and your contributions are encouraged at https://github.com/ddev/addon-registry.
\nNeed to find a specific add-on? Use the search field, and watch results update in real-time as you type.
\n\nClick on a column title to organize the entries based on that field. A second click will reverse the sort order, and a third click resets it back.
\n\nAdd-ons fall into two categories: Official add-ons, which are supported by the DDEV team, and Contrib add-ons, which are supported by the community.
\n\nWant to share your thoughts or feedback on an add-on? Scroll to the bottom of an add-on's page and click \"Sign in with GitHub\". We use giscus to manage comments, making it easy to join the conversation by authorizing your GitHub account. You can also react to other comments or add your own insights.
\n\nThe DDEV Add-on Registry is a living project, and we're eager to involve the community in its future. If you have suggestions or want to contribute, head over to https://github.com/ddev/addon-registry. We look forward to your feedback and collaboration!
\nWant to keep up as the month goes along? Follow us on
\n\n"},{"id":"https://ddev.com/blog/open-source-for-the-win","url":"https://ddev.com/blog/open-source-for-the-win","title":"Open Source for the Win!","content_html":"Today we released DDEV v1.24.3 ahead of schedule because of a wonderful set of open-source interactions. (There's other important stuff in the release, but I'll cover that later.)
\nWe would appreciate it if you could upgrade soon, especially if you're on macOS or traditional Windows, so that we don't have to answer questions about this when it starts to hit users.
\nOn Monday, two days ago, @LoganHornbuckle reported a problem (apparently with Mutagen or Docker) we had never seen before. They helped extensively with followup, and it turned out that they had done a colima update and as a result gotten the new Docker/Moby Engine version 28.0.0.
The update exposed an incompatibility between Mutagen and Docker 28, which showed up as a fatal error, completely breaking DDEV's Mutagen support for Docker 28.
\nOnce we understood the situation, we were able to reproduce the problem, and assumed it was a problem with Docker 28.
\nWe contacted @xenoscopic (Jacob Howard), the maintainer of Mutagen (now with Docker), and he was able to reproduce it immediately. By the end of the day, he had diagnosed it and provided a new release! (It turned out to be a place where Mutagen had worked around a Docker Engine quirk, and the Docker quirk got fixed, breaking Mutagen.)
\nSo here we are just two days later with a pre-emptive DDEV release v1.24.3 that should prevent most people from ever seeing the Mutagen problem.
\nThanks to @LoganHornbuckle and the community for keeping in touch, reporting, and helping to sort out problems. Amazing thanks to @xenoscopic for the quick diagnosis and fix. And thanks to Docker, Inc. for the wonderful open-source Docker project that underlies all of the available Docker providers, not just Docker Desktop. And of course thanks for supporting @xenoscopic's ongoing maintenance of Mutagen.
\nOpen source software is amazing!
\nWant to keep up as the month goes along? Follow on
\n\n"},{"id":"https://ddev.com/blog/ddev-feb-2025-newsletter","url":"https://ddev.com/blog/ddev-feb-2025-newsletter","title":"DDEV February 2025 Newsletter","content_html":"Happy February!
\nDDEV v1.24.2 was released with MySQL 8.4 support and improved ddev composer create making it nearly compatible with composer create-project.
DDEV Notes and News
\nddev composer create, making it nearly compatible with composer create-project. Additionally, the ddev composer create-project alias has been added for improved usability.Ongoing DDEV Work
\nThe next DDEV Advisory Group Meeting is Wednesday, March 5, 2025. We'll be doing a review of DDEV's 2024 and a discussion of proposed plans for 2025. This is open to all and we'd love to have you!
\nFunding DDEV to allow both maintainers to work full-time on DDEV: We need your help and your organization's help! Let me know if you need help getting this into your budget! Our key financial goal is to fully fund @stasadev so he can work exclusively on DDEV. We've slipped back in recent months. We need about $3700/month in increased pledges from organizations and individuals. See Full information about supporting DDEV. We’re happy to invoice you, happy to do a call discussing this, and would love it if you’d include DDEV in your 2025 budgeting process. (Our current status: We receive about $3000/month, have been spending about $3000-$4000/month. Bank balance is about $6,000, down from $8,600 last month.)
\nTHANKS to all of you who are supporting DDEV’s path to sustainability and who have gotten your organizations to do so.
\nWant to keep up as the month goes along? Follow on
\n\nHappy February from Randy Fay, DDEV Project Lead. It's a delight to collaborate with you!
\n"},{"id":"https://ddev.com/blog/2025-plans","url":"https://ddev.com/blog/2025-plans","title":"DDEV 2025 Plans and 2024 Review","content_html":"Every year we try to clarify goals early, and here we go for 2025! We'd love to have your thoughts and opinions! Some of the things we planned in 2024 aren't quite done yet, but we're working and planning and responding to your needs.
\nAt the DDEV Advisory Group's 2-hour annual review/planning meeting on March 5, 2025, we'll talk about plans and priorities for 2025. You are invited! The meeting link is in the meeting page.
\nWe'd love to have your input as regular users as we work through these priorities.
\nddev share to a more configurable custom-command-based option. Instead of always using ngrok there should be multiple ways to share.(We applied to the Google Summer of Code, hoping to mentor contributors via that program. We did not get accepted, but will try in future years.)
\nDo you see other important things in the issue queue or elsewhere that are important to you? Are there frictions that impact your work that DDEV could fix? Please let us know.
\nWe would dearly love to have your input on these as the planning process goes forward. You can respond so very many ways in all the support venues.
\nWe are a very small organization, so we try to pay careful attention to the risks as we go forward.
\nThis section is updated for our annual review of the past year at the DDEV Advisory Group.
\nOur full year financial reports, including balance sheet and profit-and-loss, were posted in the 2025-01-08 Advisory Group Meeting. You'll see we ended the year with about $8,500 in the bank.
\nWant to keep up as the month goes along? Follow us on
\n\n"}]}}