supabase start fails after CLI upgrade - missing /etc/postgresql-custom/conf.d directory

[actraiser]

Describe the bug

After upgrading supabase-cli to v2.65.2 (which uses postgres image supabase/postgres:17.6.1.058), supabase start fails because the PostgreSQL container cannot start. The database container enters a restart loop.

To Reproduce

1. Have an existing local supabase project with data (previously working with older CLI version)
2. Upgrade supabase-cli to v2.65.2
3. Run supabase start
4. Database container fails to start and keeps restarting

Expected behavior

Supabase should start normally, preserving existing data.

System information

• OS: macOS (Darwin 25.1.0)
• supabase-cli version: v2.65.2
• postgres image: supabase/postgres:17.6.1.058
• Docker: Docker Desktop

Container logs

PostgreSQL Database directory appears to contain a database; Skipping initialization

  2025-12-03 09:01:10.096 GMT [10] LOG:  could not open configuration directory "/etc/postgresql-custom/conf.d": No such file or directory
  2025-12-03 09:01:10.096 GMT [10] FATAL:  configuration file "/etc/postgresql/postgresql.conf" contains errors

Root cause

The new postgres image supabase/postgres:17.6.1.058 has this in /etc/postgresql/postgresql.conf:

include_dir = '/etc/postgresql-custom/conf.d'

However, the existing supabase_config_* volume from previous versions does not contain the conf.d subdirectory. When the volume is mounted to
/etc/postgresql-custom/, it overwrites the image's directory structure, and the conf.d directory is missing.

Workaround

Manually create the missing directory in the config volume:

docker run --rm -v supabase_config_default:/mnt/config alpine mkdir -p /mnt/config/conf.d

Then restart supabase:

supabase stop && supabase start

Suggested fix

The CLI or the postgres image should ensure the conf.d directory exists during startup, either by:

1. Creating it in an entrypoint script if it doesn't exist
2. Including it in the volume initialization
3. Using include_dir_if_exists instead of include_dir in postgresql.con

[7ttp]

@actraiser Thanks for Reporting! 💚
I do confirm it was reproducible on my end too!
have also created a pr to solve this up

[kallebysantos]

Hi all 💚
Sometimes the cli upgrade results in new container versions, and while doing local development it can get some corrupted files inside the docker volume.

The easiest way to solve this issue is by removing the old volumes and let the cli start command create new ones based on the latest docker images.

You guys can clean up the local volumes by running this following command:

npx supabase stop
docker volume rm $(docker volume ls --format '{{.Name}}' | grep "^supabase_")
npx supabase start

You can change the grep filter to specific match your current project

If you don't want to clean up your entire volume, I do suggest to try remove the specific /etc/postgresql/postgresql.conf file, or run the container using the previous image, dump the data in a backup file instead.
Then you can safely clean up your volume, using the steps above, and restore your data from backup.

[frankbe]

@kallebysantos: Thanks. I had the same problem (after upgrading to 2.65.3) and your advice worked for me!