Installation

See the installation instructions for details, but it's easy:

• macOS：brew install ddev/ddev/ddev or just brew upgrade ddev. • Linux：Use sudo apt-get update && sudo apt-get install ddev, see apt/yum installation ⚠️ Linux apt/yum users：packages are now served from Cloudsmith (packages.ddev.com). Your existing Gemfury (pkg.ddev.com) setup keeps working, but please re-run the Linux installation steps to switch over. • Windows and WSL2：Download the Windows Installer; you can run it for install or upgrade. ⚠️ Traditional Windows users (not WSL2)：If needed, the installer will prompt you to uninstall the previous system-wide installation to avoid conflicts with the new per-user installation. • Consider ddev delete images or ddev delete images --all after upgrading to free up disk space used by previous Docker image versions. This does no harm. • Consider ddev config --auto to update your projects to current configuration.

Highlights

• Database seeding and reset: ddev start --seed-snapshot=<name-or-path> fills a new database from any snapshot, and ddev start --reset-database deletes the current database and starts fresh, see Snapshots and Database Seeding below • MySQL 9.7 LTS support, and MySQL 8.0/8.4 now build from Docker Hardened Images (dhi.io/mysql) instead of bitnamilegacy/mysql, which gets no updates • Env files: .env.local for values you don't want in Git, several files per service separated by a label, and global files that apply to every project, see Environment Variables • Set things once for every project: global Dockerfiles in ~/.ddev/web-build/ and ~/.ddev/db-build/, and global env files in ~/.ddev/.env*, see Global Configuration below • apt/rpm packages are now published to Cloudsmith (packages.ddev.com) as well as Gemfury, and the yum repo now verifies package signatures, which the Gemfury one never did. Gemfury (pkg.ddev.com) is still supported but will be retired eventually; see the Linux note above to switch over

Snapshots and Database Seeding

• A snapshot named seed is automatically loaded when you start a project with an empty database. So if you delete your db or project and then ddev start, you'll have the database from the seed snapshot. • ddev start --seed-snapshot fills a new database from a snapshot in .ddev/db_snapshots, or from a path to one anywhere else on your machine. A snapshot outside the project is read where it is instead of being copied, so a multi-GB file is not duplicated. A snapshot named seed is used automatically, with no flag. Works for MariaDB, MySQL, and PostgreSQL • ddev start --reset-database deletes the database and starts fresh. It takes a snapshot first, using the database version that created the data, so this also works when you already changed database: in your config. ddev config --database= now warns instead of failing, and ddev delete no longer refuses to work on a project whose data came from a different database server • ddev snapshot restore --force restores a snapshot made by a different version of the same database server • ddev snapshot --list shows each snapshot's size and database version • ddev snapshot restore and ddev snapshot --list also see snapshots from other Git worktrees of the same repository, so a database doesn't have to be copied between worktrees by hand • Snapshots and the database seed can skip compression with --uncompressed：more disk space, faster restore. The base_db seed also reads zstd now, not only gzip, which is much faster for a custom dbimage with a large database built into it, thanks to @weitzman

Global Configuration

These apply to every project on your machine, so you set them once instead of in each project.

• New global Dockerfiles in ~/.ddev/web-build/ and ~/.ddev/db-build/ add the same image changes to every project - CA certificates, system tools, extra apt packages. If a project has a file with the same name in its own .ddev/web-build/, the project file is used, thanks to @rmott-littler • New global env files ~/.ddev/.env and ~/.ddev/.env.<service> set variables for every project. This is the only way to set a variable globally for a container other than web, since web_environment only reaches web. If a project sets the same variable, the project value is used. Write these files with ddev dotenv global set • Add-on install actions now see .ddev/.env and the global ~/.ddev/.env* files, not only .ddev/.env.<addon>. If you set a DDEV_* variable in .ddev/.env, that value is used there. A .ddev/.env.<service>.<label> file is also passed into that service's container now; before, it was only used to fill in variables in your docker-compose files

Features

• Two new project types: MODX Revolution 2.x/3.x, thanks to @casparml, and Maho, thanks to @fballiano • Shopware 6 projects get shopware-cli in the web image, plus ddev admin-watch and ddev storefront-watch with the ports they need, so the ddev-shopware-cli add-on isn't needed, thanks to @vanWittlaer • New ddev add-on update checks installed add-ons against their latest GitHub release and updates the outdated ones, with --dry-run to see what would change • New ddev utility download-ddev fetches the ddev and ddev-hostname binaries for a PR, branch, commit, release tag, latest stable, or main HEAD, without touching your installed DDEV • New ddev utility delete-volume removes one of the project's Docker volumes by name or from an interactive list, for add-ons like ddev-solr that create their own • ddev launch --print-url and DDEV_LAUNCH_PRINT_URL=true ddev launch print the URL instead of opening a browser, for SSH, containers, and CI, thanks to @steffenmaechtel • New ddev tablepro host command for the TablePro database client on macOS, thanks to @datlechin • New nodejs_root lets nodejs_version：auto/engine read the version file from a subdirectory such as web/themes/custom/mytheme. Both now require that file to exist; before, if it was missing, DDEV installed its default version without telling you, thanks to @dpacassi • The dbimage config option works again after a long absence, mirroring webimage, along with ddev config --db-image/--db-image-default • If you pin a custom webimage or dbimage, ddev start warns you when that image was built from an older DDEV image than this version expects, instead of failing later in a way that gives no hint why. Official images now record the DDEV version they were built for, so the warning starts working after you rebuild your own image, thanks to @weitzman • ddev ssh and ddev exec pass your TERM and COLORTERM into interactive sessions, so you get more than 16 colors, thanks to @wazum • ddev start warns when DDEV itself is an unreleased build from a PR or a local branch, and ddev version shows where it came from • Drupal settings.ddev.php configures symfony_mailer_lite the way it already configured symfony_mailer, thanks to @mxr576 • The FAQ explains how to move from Homebrew to a specific DDEV version, thanks to @joachim-n

Bug Fixes for Regressions from v1.25.3

• Project image builds are fast again. Permissions on the Node.js directory were being changed recursively on every build, and now they are set once when the image is built • Add-ons and apps that write log files straight into /var/log can do that again, after the directory was locked down to root only • A site that generates /robots.txt itself works again, including Drupal's RobotsTxt module. An nginx rule was answering /robots.txt before your site could, and it is now removed • Projects that pin the web service to a specific platform, like platform：linux/amd64 on an Apple Silicon Mac, start again • Orphan containers get removed again, so Docker Compose stops warning about them

Bug Fixes

• ddev wp uses the path from your project's own wp-cli.yml again, and only falls back to the docroot when that file doesn't set one, which is what the docs always said. Since v1.24.5 it always added --path=$DDEV_DOCROOT, which broke Bedrock and any layout where WordPress isn't in the docroot • Running ddev in a subdirectory that has its own .ddev/config.yaml, like a