Skip to content
Latchkey

MariaDB/MySQL "Access denied for user (using password: YES)" in CI

MariaDB or MySQL authenticated the host but the username/password pair is wrong: "using password: YES" means a password was sent but rejected. In CI this is usually a mismatch between the container env and the connection string.

What this error means

Login fails with "ERROR 1045 (28000): Access denied for user \"app\"@\"172.18.0.1\" (using password: YES)" while the server is reachable.

Terminal
ERROR 1045 (28000): Access denied for user 'app'@'172.18.0.1' (using password: YES)

Common causes

The password does not match what the container created

The image sets passwords from MYSQL_ROOT_PASSWORD/MYSQL_PASSWORD only on first init. A different value in the connection string is rejected.

A reused data volume kept the old credentials

If the data directory already existed, the image skips initialization, so a changed MYSQL_PASSWORD never took effect and the old one is still required.

How to fix it

Make env and connection string agree

Use the same user and password for the container and the client.

.github/workflows/ci.yml
services:
  mariadb:
    image: mariadb:11
    env:
      MARIADB_ROOT_PASSWORD: root
      MARIADB_DATABASE: app_test
      MARIADB_USER: app
      MARIADB_PASSWORD: app_pw
    ports: ['3306:3306']
env:
  DATABASE_URL: mysql://app:app_pw@127.0.0.1:3306/app_test

Recreate the volume after a password change

Passwords apply only to a fresh data dir. Drop the volume so initialization re-runs with the new value.

Terminal
docker compose down -v && docker compose up -d mariadb

How to prevent it

  • Keep the MySQL/MariaDB password in one place and reuse it client-side.
  • Do not persist the test DB data volume across credential changes.
  • Use root only for setup; connect tests as the scoped MYSQL_USER.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →