## Configuration Files The [`ddev config`]() and `ddev start` commands attempt to create a CMS-specific settings file pre-populated with DDEV credentials. If you don’t want DDEV to do this, set the [`disable_settings_management`]() config option to `true`. For **Craft CMS** DDEV settings are added to the `.env` file. For **Drupal** and **Backdrop**, DDEV settings are written to a DDEV-managed file, `settings.ddev.php`. The `ddev config` command will ensure these settings are included in your `settings.php` through the following steps: - Write DDEV settings to `settings.ddev.php`. - If no `settings.php` file exists, create one that includes `settings.ddev.php`. - If a `settings.php` file already exists, ensure that it includes `settings.ddev.php`, modifying `settings.php` to write the include if necessary. For **Magento 1**, DDEV settings go into `app/etc/local.xml`. In **Magento 2**, DDEV settings go into `app/etc/env.php`. For **Maho**, DDEV settings go into `app/etc/local.xml`. For **TYPO3**, DDEV settings are written to `config/system/additional.php`. If `additional.php` exists and is not managed by DDEV, it will not be modified. For **WordPress**, DDEV settings are written to a DDEV-managed file, `wp-config-ddev.php`. The `ddev config` command will attempt to write settings through the following steps: - Write DDEV settings to `wp-config-ddev.php`. - If no `wp-config.php` exists, create one that include `wp-config-ddev.php`. - If a DDEV-managed `wp-config.php` exists, create one that includes `wp-config.php`. - If a user-managed `wp-config.php` exists, instruct the user on how to modify it to include DDEV settings. You’ll know DDEV is managing a settings file when you see a comment containing `#ddev-generated` like the one below. Remove the comment and DDEV will not attempt to overwrite it. If you’re letting DDEV create its settings file, we recommended leaving this comment so DDEV can continue to manage it, and make any needed changes in another settings file. ``` /** #ddev-generated: Automatically generated Drupal settings.php file. ddev manages this file and may delete or overwrite the file unless this comment is removed. */ ``` If you’re providing the `settings.php` or `wp-config.php` and DDEV is creating `settings.ddev.php` (or `wp-config-local.php`, `AdditionalConfig.php`, or similar), the main settings file must explicitly include the appropriate DDEV-generated settings file. Any changes you need should be included somewhere that loads after DDEV’s settings file, for example in Drupal’s `settings.php` *after* `settings.ddev.php` is included. (See [Adding Configuration](<#adding-configuration>) below). ### Adding Configuration **Drupal and Backdrop**: In `settings.php`, enable loading `settings.local.php` after `settings.ddev.php` is included—creating a new one if it doesn’t already exist—and make changes there. Wrap with `if (getenv('IS_DDEV_PROJECT') == 'true')` as needed. **WordPress**: Load a `wp-config-local.php` after `wp-config-ddev.php`, and make changes there. Wrap with `if (getenv('IS_DDEV_PROJECT') == 'true')` as needed. ## Listing Project Information > [!TIP] > > **TUI (Terminal UI) Alternative** > > You can also view and manage all your projects from the [interactive dashboard]() by running `ddev` with no arguments. Run [`ddev list`]() or `ddev list --active-only` current projects. ``` ➜ ddev list NAME STATUS LOCATION URL TYPE d10 stopped ~/workspace/d10 drupal10 drup running (ok) ~/workspace/drup https://drup.ddev.site drupal my-cakephp-app stopped ~/workspace/my-cakephp-app cakephp Router healthy ~/.ddev http://127.0.0.1:10999 traefik ``` ``` ➜ ddev list --active-only NAME STATUS LOCATION URL TYPE drup running (ok) ~/workspace/drup https://drup.ddev.site drupal Router healthy ~/.ddev http://127.0.0.1:10999 traefik ``` You can also see more detailed information about a project by running [`ddev describe`]() from its working directory. You can also run `ddev describe [project-name]` from any location to see the detailed information for a running project. ``` $ ddev describe drup ┌──────────────────────────────────────────────────────────────────────────────────┐ │ Project: drup ~/workspace/drup https://drup.ddev.site │ │ Docker platform: orbstack │ │ Router: traefik │ ├──────────┬──────┬───────────────────────────────────────────┬────────────────────┤ │ SERVICE │ STAT │ URL/PORT │ INFO │ ├──────────┼──────┼───────────────────────────────────────────┼────────────────────┤ │ web │ OK │ https://drup.ddev.site │ drupal PHP8.4 │ │ │ │ InDocker: web:8025,443,80 │ nginx-fpm │ │ │ │ Host: 127.0.0.1:33016,33017 │ docroot:'web' │ │ │ │ │ Perf mode: mutagen │ │ │ │ │ NodeJS:20 │ ├──────────┼──────┼───────────────────────────────────────────┼────────────────────┤ │ db │ OK │ InDocker: db:3306 │ mariadb:11.8 │ │ │ │ Host: 127.0.0.1:33018 │ User/Pass: 'db/db' │ │ │ │ │ or 'root/root' │ ├──────────┼──────┼───────────────────────────────────────────┼────────────────────┤ │ Mailpit │ │ Mailpit: https://drup.ddev.site:8026 │ │ │ │ │ `ddev mailpit` │ │ ├──────────┼──────┼───────────────────────────────────────────┼────────────────────┤ │ All URLs │ │ https://drup.ddev.site, │ │ │ │ │ https://127.0.0.1:33016, │ │ │ │ │ http://drup.ddev.site, │ │ │ │ │ http://127.0.0.1:33017 │ │ └──────────┴──────┴───────────────────────────────────────────┴────────────────────┘ ``` ## Removing Projects There are two ways to remove a project from DDEV’s listing. The first, the [`ddev delete`]() command, is destructive. It removes the project from DDEV’s list, deletes its database, and removes the hostname entry from the hosts file: `ddev delete ` or `ddev delete --omit-snapshot ` If you don’t want the project to show up in [`ddev list`]() anymore, use [`ddev stop`]()—which is nondestructive—to unlist the project until the next time you run [`ddev start`]() or [`ddev config`](): ``` ddev stop --unlist ``` ## Importing Assets for An Existing Project An important aspect of local web development is the ability to have a precise local recreation of the project you’re working on, including up-to-date database contents and static assets like uploaded images and files. DDEV provides two commands to help with importing assets to your local environment. ### Importing a Database The [`ddev import-db`]() command imports the database for a project. Running this command will prompt you to specify the location of your database import. By default `ddev import-db` empties the default `db` database, then loads the provided dump file. Most people use it with command flags, like `ddev import-db --file=.tarballs/db.sql.gz`, but it can also prompt for the location of the dump if you only use `ddev import-db`: ``` ddev import-db Provide the path to the database you wish to import. Import path: ~/Downloads/db.sql Importing database... Successfully imported database for drupal8 ``` #### Supported Database Import File Types Database imports can be any of the following file types: - Raw SQL Dump (`.sql`) - Gzipped SQL Dump (`.sql.gz`) - `bzip2` SQL Dump (`.sql.bz2`) - Xz’d SQL Dump (`.sql.xz`) - Zstandard SQL Dump (`.sql.zst`) - Tarball Archive (`.tar`, `.tar.gz`, `.tgz`, `.tar.bz2`, `.tar.xz`, `.tar.zst`) - ZIP Archive (`.zip`) - stdin If a Tarball Archive or ZIP Archive is provided for the import, you’ll be prompted to specify a path within the archive to use for the import asset. The specified path should provide a raw SQL dump (`.sql`). In the following example, the database we want to import is named `data.sql` and resides at the top level of the archive: ``` ddev import-db Provide the path to the database you wish to import. Import path: ~/Downloads/site-backup.tar.gz You provided an archive. Do you want to extract from a specific path in your archive? You may leave this blank if you wish to use the full archive contents Archive extraction path: data.sql Importing database... A settings file already exists for your application, so ddev did not generate one. Run 'ddev describe' to find the database credentials for this application. Successfully imported database for drupal8 ``` #### Non-Interactive Usage If you want to use the [`import-db`]() command without answering prompts, you can use the `--file` flag to provide the path to the import asset. If you’re importing an archive and wish to specify the path within the archive to extract, you can use the `--extract-path` flag in conjunction with the `--file` flag. Examples: ``` ddev import-db --file=/tmp/mydb.sql.gz gzip -dc /tmp/mydb.sql.gz | ddev import-db ddev import-db ` to import to a non-default database (other than the default `db` database). This will create the database if it doesn’t already exist. - Use `ddev import-db --no-drop` to import without first emptying the database. - If a database already exists and the import does not specify dropping tables, the contents of the imported dumpfile will be *added* to the database. Most full database dumps do a table drop and create before loading, but if yours does not, you can drop all tables with `ddev stop --remove-data` before importing. - If imports are stalling or failing, make sure you have plenty of unused space (see [\#3360]()). DDEV has no problems importing large (2G+) databases, but importing requires lots of space. DDEV will show a warning on startup if unused space is getting low. ## Inter-Project Communication ### Access another project’s database To connect the `web` container to the `db` container of a different project, use `ddev--db` as the hostname. Example: two projects, `backend` and `frontend`. In the `frontend` project: ``` ddev exec mysql -h ddev-backend-db ``` > [!NOTE] > > **Database host reset after restart** > > DDEV manages certain [CMS settings](). If you change the database host in `.env`, it may reset to `db` after `ddev restart`. > > Disable this behavior by setting [`disable_settings_management`]() to `true` or running [`ddev config --disable-settings-management`](). ### Access another project via HTTP/S Example: two projects, `backend` and `frontend`. From v1.24.10+, DDEV supports direct HTTP/S calls between projects: ``` # From frontend web container to backend web container ddev exec curl https://backend.ddev.site # Or using internal Docker hostname ddev exec curl https://ddev-backend-web ``` > [!NOTE] > > **Using HTTPS from a non-web container** > > HTTP works without extra setup. For HTTPS, the calling container must trust the `ddev-webserver` certificate authority (CA). > > ``` > $ ddev exec -s some-service curl https://backend.ddev.site > curl: (60) SSL certificate problem: unable to get local issuer certificate > More details: https://curl.se/docs/sslcerts.html > ``` > > See [Third-party services may need to trust `ddev-webserver`](). ### Access another service in the same or different project - **Same project**: containers reach each other by service name. No project name prefix is required. - **Different project**: containers reach each other with `ddev--`. Example in a single project with `web` and `opensearch` services: ``` # From web container to opensearch ddev exec curl http://opensearch:9200 # From opensearch container to web ddev exec -s opensearch curl http://web ``` Example with two projects, `frontend` and `backend` (`backend` has `opensearch` service): ``` # From frontend web container to backend opensearch ddev exec curl http://ddev-backend-opensearch:9200 ``` ### Access services on the host machine To connect from a container to a service on the host, use `host.docker.internal` as the hostname. ``` # Test connection to host service on port 8000 ddev exec telnet host.docker.internal 8000 # Call API on host ddev exec curl http://host.docker.internal:8000/some/api/endpoint ``` > [!NOTE] > > **Host service binding** > > Services on the host must listen on all interfaces (`0.0.0.0`), not only `127.0.0.1` (`localhost`).