Something bad happened: in create new site

DevKinsta Bug Reports
23

Confirming this is still occurring in DevKinsta 2.13.6 and matches the behaviour described earlier in this thread.

On a completely clean install (all containers, volumes, and AppData removed), creating a new site fails with “Something bad happened”.

Observed behaviour:

  • DevKinsta creates the devkinsta_db container

  • MYSQL_ROOT_PASSWORD=<random> is visible via docker inspect

  • DevKinsta attempts DB authentication

  • Authentication fails with ERROR 1045

  • Provisioning aborts before wp-config.php is written

As @StormChild described, manually setting the root password inside the container can resolve it in some cases:

mysql -u root
ALTER USER 'root'@'localhost' IDENTIFIED BY '<password from docker inspect>';
FLUSH PRIVILEGES;

However, this is not a failsafe workaround. In some cases (including mine), root cannot be accessed without a password and the DB ends up in a partially initialised state where authentication still fails.

Failsafe workaround (reproducible):

  1. Stop and remove the DB container:
    docker rm -f devkinsta_db

  2. Remove the DB volume:
    docker volume rm devkinsta_db_data

  3. Recreate the DB container using the password shown in docker inspect:

docker run -d --name devkinsta_db \
  --network devkinsta_network \
  -e MARIADB_ROOT_PASSWORD=<password from inspect> \
  -v devkinsta_db_data:/var/lib/mysql \
  kinsta/devkinsta_db:1.3.6
  1. Verify authentication works:
    docker exec -it devkinsta_db mysql -uroot -p<password> -e "SELECT 1;"

After this clean initialisation, DevKinsta can complete site creation normally.

This strongly suggests a first-run MariaDB initialisation / authentication sequencing issue (race condition) where DevKinsta attempts DB access before the root password is properly applied, leaving the volume in a broken state.

Since this issue has been reported multiple times (2023–2025) and is still reproducible on a clean install, could the DevKinsta team please investigate:

  • Adding a proper DB readiness / authentication check before proceeding with provisioning

  • Automatically recovering from failed first-run DB initialisation instead of leaving a broken volume

At the moment, manual DB volume removal is the only fully reliable recovery method.

1 Like
Can't install or import a site: "Something bad happened"