Cannot start Nakama with config from postgres guideline

I have been trying to setup Nakama with the sample configuration from github. I successfully started a previous server using that configuration but couldn’t add custom config so I tried to start from scratch. Then I started receiving errors. The configuration is as follows:

version: '3'
services:
  postgres:
    container_name: postgres
    image: postgres:12.2-alpine
    environment:
      - POSTGRES_DB=nakama
      - POSTGRES_PASSWORD=localdb
    volumes:
      - data:/var/lib/postgresql/data
    expose:
      - "8080"
      - "5432"
    ports:
      - "5432:5432"
      - "8080:8080"
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres", "-d", "nakama"]
      interval: 3s
      timeout: 3s
      retries: 5
  nakama:
    container_name: nakama
    image: registry.heroiclabs.com/heroiclabs/nakama:3.25.0
    entrypoint:
      - "/bin/sh"
      - "-ecx"
      - >
          /nakama/nakama migrate up --database.address postgres:localdb@postgres:5432/nakama &&
          exec /nakama/nakama --name nakama1 --database.address postgres:localdb@postgres:5432/nakama --logger.level DEBUG --session.token_expiry_sec 7200
    restart: always
    links:
      - "postgres:db"
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - ./:/nakama/data
    expose:
      - "7349"
      - "7350"
      - "7351"
    ports:
      - "7349:7349"
      - "7350:7350"
      - "7351:7351"
    healthcheck:
      test: ["CMD", "/nakama/nakama", "healthcheck"]
      interval: 10s
      timeout: 5s
      retries: 5
volumes:
  data:

When I run docker compose, I get this error:

nakama    | + /nakama/nakama migrate up --database.address postgres:localdb@postgres:5432/nakama
postgres  | 2025-01-22 06:32:24.589 UTC [1137] FATAL:  password authentication failed for user "postgres"
postgres  | 2025-01-22 06:32:24.589 UTC [1137] DETAIL:  Password does not match for user "postgres".
postgres  |     Connection matched pg_hba.conf line 95: "host all all all md5"
nakama    | {"level":"fatal","ts":"2025-01-22T06:32:24.590Z","caller":"server/db.go:88","msg":"Failed to check if db exists","db":"nakama","error":"failed to connect to `user=postgres database=nakama`:\n\t172.18.0.2:5432 (postgres): tls error: server refused TLS connection\n\t172.18.0.2:5432 (postgres): server error: FATAL: password authentication failed for user \"postgres\" (SQLSTATE 28P01)"}
nakama exited with code 1

I also receive a warning when postgres is being setup

 ! nakama The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested                                          0.0s 
Attaching to nakama, postgres
postgres  | 
postgres  | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres  | 
postgres  | 2025-01-22 06:37:00.187 UTC [1] LOG:  starting PostgreSQL 12.2 on aarch64-unknown-linux-musl, compiled by gcc (Alpine 9.2.0) 9.2.0, 64-bit
postgres  | 2025-01-22 06:37:00.187 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
postgres  | 2025-01-22 06:37:00.187 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postgres  | 2025-01-22 06:37:00.189 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres  | 2025-01-22 06:37:00.194 UTC [21] LOG:  database system was shut down at 2025-01-22 06:36:27 UTC
postgres  | 2025-01-22 06:37:00.196 UTC [1] LOG:  database system is ready to accept connections

I am on MacOS which runs on an Apple Silicon machine.

Versions:

  • Nakama: 3.5
  • Postgres: 12.2-alpine
  • MacOS: Sequoia 15.0
  • Chip: M1 Max

Okay, so solved the password issue. Apparently the volume still existed for the db after I deleted the previous container. Since the name of the volume was the same, it tried to use the same db.

Since I am using the same configuration, the one from the guide, I would expect the new container could connect as well but it wasn’t the case. Now it is working.

So, if anyone encounters a similar issue, check the volumes in the docker desktop and delete volumes created by previous containers as they might cause problems if your new container is trying to use those.