ddev | Docker-based local PHP+Node.js web development environments | Continuous Deployment library

This is a problem that you and your IT department will have to solve. I imagine you have not just a proxy but also the VPN you're using is likely doing deep packet inspection and has a replacement CA for the trusted CA that the rest of the internet uses.

If you don't have a VPN, but only a proxy, then you need to properly configure docker for the proxy, see https://github.com/drud/ddev-contrib/tree/master/recipes/proxy - but since you're getting untrusted certs, it looks to me like there's more going on than just a proxy.

If your IT department can provide you with a replacement CA crt you can put it into .ddev/web-build and add a .ddev/web-build/Dockerfile like this:

You don't mention your environment but I imagine you're on macOS with Docker and have enabled experimental settings. Please turn them off... they don't really work right yet. See macOS DDEV drush command Permission denied (Experimental docker settings)

Please use the instructions in the DDEV FAQ "How can I change the name of a project?"

Use this process:

1. Export the database of the project: ddev export-db --file=/path/to/db.sql.gz
2. ddev delete . By default this will make a snapshot, which is a nice safety valve.
3. Rename the project, ddev config --project-name=
4. ddev start
5. ddev import-db --src=/path/to/db.sql.gz

You don't say much about your environment, but I imagine you're on macOS and you installed Docker Desktop 4.6.0+ and you enabled the experimental virtualization and VirtioFS features. Please uncheck them, they're not ready for prime time. For performance, I recommend enabling mutagen, people love it, https://ddev.readthedocs.io/en/latest/users/performance/#using-mutagen

The reason for the website becoming unreachable is that WSL2 only binds ports to the localhost and not to every interface.
Docker desktop itself binds to every interface and forwards everything to WSL2 that is why it worked. For docker-ce a manual solution is required.
The problem is documented in the wsl documentation and a solution is described.
A script for discovering and setting the port forwarding automatically is found in an older WSL2 issue on github.

With the localhostForwarding option set (documentation) for WSL2 the following commands work too:

netsh interface portproxy add v4tov4 listenport=80 connectport=80 connectaddress=127.0.0.1
netsh interface portproxy add v4tov4 listenport=443 connectport=443 connectaddress=127.0.0.1

In some future version Microsoft may bring the bridged networking option back for WSL2 see issue discussion.

Update for DDEV v1.19+

1. Postgres is now available of the box with DDEV, so there is no need for an additional service/container.
2. You no longer have to use an explicit name for the container, since the networking in DDEV is now more sophisticated.

--------- Original Answer Below ----------

You're using $host = "postgres";, please use the explicit name of the postgres container, ddev--postgres

The hostname postgres is ambiguous inside the docker network when you're running more than one project that has a service named "postgres". So you're getting the behavior you see.

A PR to the ddev-contrib recipe would be appreciated; this has been updated in lots of the ddev-contrib recipes since the problem was discovered a year or so ago, but apparently not this one.

This is worked around in DDEV v1.18.2+ (and v1.19+), please upgrade. It was a bug in docker-compose 2.2.0+ - please see https://github.com/drud/ddev/issues/3404 for context.

Docker itself does not use ports 80 or 443, so you have something else running there (the most common offender is going to be apache). The docs at https://ddev.readthedocs.io/en/latest/users/troubleshooting/#webserver-ports-are-already-occupied-by-another-webserver explain how to debug this. Since it says docker-proxy is running there, it probably means that you have a docker container already running and bound to port 80.

Try these things:

• ddev poweroff (to make sure all ddev things are stopped)
• docker ps -a will show you other containers that may be running
• docker rm -f $(docker ps -aq) will stop all running containers.

I think when you do these things you'll find docker not listening any more; now you just have to find out why it was listening.

As you already know, the docs for various kinds of sharing are at https://ddev.readthedocs.io/en/latest/users/topics/sharing/ and you may also be interested in the general on-server approaches in https://ddev.readthedocs.io/en/latest/users/alternate-uses/#casual-project-webhosting-on-the-internet-including-lets-encrypt

With composer version 2.2 the phpunit executable in vendor/bin is not a symlink anymore. It‘s a PHP file which includes the original executable with help of stream-wrapper, but including phpunit is not allowed: https://github.com/sebastianbergmann/phpunit/issues/4096#issuecomment-585900398

The bug is solved in composer: https://github.com/composer/composer/issues/10387#issuecomment-1000246631

Use the following to get the latest dev version until this fix was official released: