Significant-Gravitas
Unable to setup locally : docker compose up -d fails at autogpt_platform-market-migrations-1
⚠️ Search for existing issues first ⚠️
- [X] I have searched the existing issues, and there is no existing issue for my problem
Which Operating System are you using?
MacOS
Which version of AutoGPT are you using?
Master (branch)
What LLM Provider do you use?
Azure
Which area covers your issue best?
Installation and setup
What commit or version are you using?
2121ffd06b26a438706bf642372cc46d81c94ddc
Describe your issue.
I am trying to set AutoGPT locally. I am following the steps in the video tutorial on main README.md file.
The docker setup fails when i run this command.
docker compose up -d
It fails with the following status :
✘ Container autogpt_platform-market-migrations-1 service "market-migrations" didn't complete successfully: exit 1
and then gets stuck at
Container autogpt_platform-migrate-1 Waiting
What did I miss ?
Upload Activity Log Content
No response
Upload Error Log Content
No response
Hey @mali-tintash I was talking to @aarushik93 about your issue above and it seems like we need more detail on what's happening here. If you can post your logs, that may be helpful or to get quicker help on this post in our help-channel in our main discord (other users may have had a similar problem to you before)
Same issue here, same version. Seems to happen when a non-default POSTGRES_PASSWORD environment variable is used.
Default setup process:
git clone https://github.com/Significant-Gravitas/AutoGPT.git
git checkout 2121ffd06b26a438706bf642372cc46d81c94ddc # v0.3.4
git submodule update --init --recursive
cd autogpt_platform
cp supabase/docker/.env.example .env
nano .env # <- Changing the POSTGRES_PASSWORD to "non-default-super-secret-and-long-postgres-password"
docker compose up -d --build
Result:
✘ Container autogpt_platform-market-migrations-1 service "market-migrations" didn't complete successfully: exit 1
Log:
docker compose logs market-migrations
# market-migrations-1 | Creating virtualenv market-CQaCOyxI-py3.11 in /root/.cache/pypoetry/virtualenvs
# market-migrations-1 | * Install prebuilt node (23.4.0) ..... done.
# market-migrations-1 | Prisma schema loaded from schema.prisma
# market-migrations-1 | Datasource "db": PostgreSQL database "postgres", schema "market" at "db:5432"
# market-migrations-1 |
# market-migrations-1 | Error: P1000: Authentication failed against database server at `db`, the provided database c redentials for `postgres` are not valid.
# market-migrations-1 |
# market-migrations-1 | Please make sure to provide valid database credentials for the database server at `db`.
@sticeIO thanks for sharing your logs and giving us more info - we'll look into this and someone on the team will get back to you!
@itsababseh any updates, I am also getting the same issue - PG fails to auth and the migrations fail
@mccormjt Thanks for bumping this, I'm circling back with the team to see if we have an update to share or need more info!
I get stopped at the same point in set up locally.
I am running this on WSL and get this when running the docker command. ~/coding-playpen/AutoGPT/autogpt_platform$ docker compose up -d unknown shorthand flag: 'd' in -d See 'docker --help'.
VERSION /coding-playpen/AutoGPT/autogpt_platform$ docker --version Docker version 20.10.12, build 20.10.12-0ubuntu2~20.04.1
Hey all, we're deploying an updated version to master soon and this should be resolved then, sorry for the inconvinience!!
Just wanted to confirm I have the same issue! I've tried a combination of different default Postgres credentials, as well as leaving the credentials out entirely. Glad theres a fix on the way 😁
@astroyouth That appears to be a different issue, you likely don't have docker-compose installed. It's a separate package from docker. Verify it's installed with docker compose version, if you don't have it installed you can follow the instructions here, then give it another try.
"Seems to happen when a non-default POSTGRES_PASSWORD environment variable is used."
I saw this and copied the example .env back into autogpt_platform folder and issue persists.
I think even though supabase-db comes up healthy, there is some sort of password and schema creation issue.
I followed the logs of db service as soon as it came up as healthy and saw this as supabase-analytics and autogpt_platform-migrate-1 were starting:
supabase-db |
supabase-db | PostgreSQL Database directory appears to contain a database; Skipping initialization
supabase-db |
supabase-db | 172.20.0.6 2025-01-15 01:19:21.418 UTC [51] supabase_admin@postgres FATAL: password authentication failed for user "supabase_admin"
supabase-db | 172.20.0.6 2025-01-15 01:19:21.418 UTC [51] supabase_admin@postgres DETAIL: Connection matched pg_hba.conf line 89: "host all all 172.16.0.0/12 scram-sha-256"
supabase-db | 172.20.0.6 2025-01-15 01:19:21.418 UTC [52] supabase_admin@postgres FATAL: password authentication failed for user "supabase_admin"
supabase-db | 172.20.0.6 2025-01-15 01:19:21.418 UTC [52] supabase_admin@postgres DETAIL: Connection matched pg_hba.conf line 89: "host all all 172.16.0.0/12 scram-sha-256"
supabase-db | 172.20.0.6 2025-01-15 01:19:22.916 UTC [53] supabase_admin@postgres FATAL: password authentication failed for user "supabase_admin"
supabase-db | 172.20.0.6 2025-01-15 01:19:22.916 UTC [53] supabase_admin@postgres DETAIL: Connection matched pg_hba.conf line 89: "host all all 172.16.0.0/12 scram-sha-256"
supabase-db | 172.20.0.6 2025-01-15 01:19:22.982 UTC [54] supabase_admin@postgres FATAL: password authentication failed for user "supabase_admin"
supabase-db | 172.20.0.6 2025-01-15 01:19:22.982 UTC [54] supabase_admin@postgres DETAIL: Connection matched pg_hba.conf line 89: "host all all 172.16.0.0/12 scram-sha-256"
supabase-db | 172.20.0.7 2025-01-15 01:19:25.301 UTC [63] postgres@postgres FATAL: password authentication failed for user "postgres"
supabase-db | 172.20.0.7 2025-01-15 01:19:25.301 UTC [63] postgres@postgres DETAIL: Connection matched pg_hba.conf line 89: "host all all 172.16.0.0/12 scram-sha-256
In my case, supabase-analytics eventually ended up in ERROR state along with autogpt_platform-migrate-1 in WAITING
last entries in the logs for supabase-analytics service:
supabase-analytics | 01:06:55.082 [error] Postgrex.Protocol (#PID<0.163.0>) failed to connect: ** (Postgrex.Error) FATAL 28P01 (invalid_password) password authentication failed for user "supabase_admin"
supabase-analytics |
supabase-analytics | 01:06:57.804 [error] Could not create schema migrations table. This error usually happens due to the following:
supabase-analytics |
supabase-analytics | * The database does not exist
supabase-analytics | * The "schema_migrations" table, which Ecto uses for managing
supabase-analytics | migrations, was defined by another library
supabase-analytics | * There is a deadlock while migrating (such as using concurrent
supabase-analytics | indexes with a migration_lock)
supabase-analytics |
supabase-analytics | To fix the first issue, run "mix ecto.create" for the desired MIX_ENV.
supabase-analytics |
supabase-analytics | To address the second, you can run "mix ecto.drop" followed by
supabase-analytics | "mix ecto.create", both for the desired MIX_ENV. Alternatively you may
supabase-analytics | configure Ecto to use another table and/or repository for managing
supabase-analytics | migrations:
supabase-analytics |
supabase-analytics | config :logflare, Logflare.Repo,
supabase-analytics | migration_source: "some_other_table_for_schema_migrations",
supabase-analytics | migration_repo: AnotherRepoForSchemaMigrations
supabase-analytics |
supabase-analytics | The full error report is shown below.
supabase-analytics |
supabase-analytics | ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 10983ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:
supabase-analytics |
supabase-analytics | 1. Ensuring your database is available and that you can connect to it
supabase-analytics | 2. Tracking down slow queries and making sure they are running fast enough
supabase-analytics | 3. Increasing the pool_size (although this increases resource consumption)
supabase-analytics | 4. Allowing requests to wait longer by increasing :queue_target and :queue_interval
supabase-analytics |
supabase-analytics | See DBConnection.start_link/2 for more information
supabase-analytics |
supabase-analytics | (ecto_sql 3.10.1) lib/ecto/adapters/sql.ex:913: Ecto.Adapters.SQL.raise_sql_call_error/1
supabase-analytics | (elixir 1.14.4) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
supabase-analytics | (ecto_sql 3.10.1) lib/ecto/adapters/sql.ex:1005: Ecto.Adapters.SQL.execute_ddl/4
supabase-analytics | (ecto_sql 3.10.1) lib/ecto/migrator.ex:738: Ecto.Migrator.verbose_schema_migration/3
supabase-analytics | (ecto_sql 3.10.1) lib/ecto/migrator.ex:552: Ecto.Migrator.lock_for_migrations/4
supabase-analytics | (ecto_sql 3.10.1) lib/ecto/migrator.ex:428: Ecto.Migrator.run/4
supabase-analytics | (ecto_sql 3.10.1) lib/ecto/migrator.ex:170: Ecto.Migrator.with_repo/3
supabase-analytics | nofile:1: (file)
@aarushik93 I forgot to get latest from master. So I did that and same issue. Did the fix for this get released?
I'm using ubuntu on WSL2, btw.
The docker-compose.platform.yml file is not using the .env variables. You will need to change the hardcoded values to ${.ENV VARNAME}
@elabbarw is there a reason the PR was closed? was looking to review it after cla
@elabbarw is there a reason the PR was closed? was looking to review it after cla
Hey, I need to get legal advice on the CLA, so couldn't sign it. Happy to talk in private about it.
I encountered the same issue, and I found that some values like POSTGRES_PASSWORD and SERVICE_ROLE_KEY in the 'docker-compose.platform.yml' file were not set the same as in the '.env' file.
After updating them to match, the issue was resolved. : )
I had the same problem. After setting the password to "postgres" (default password of Postgres) everything works.
Looks like there is a problem with the initial database creation.
I had the same problem. After setting the password to "postgres" (default password of Postgres) everything works.
Looks like there is a problem with the initial database creation.
This didn't work for me (updated .env with postgres, deleted docker container and reran --build) I have Docker Compose installed.
Any update on this? For me the follwoing steps run in a loop
supabase-imgproxy | INFO [2025-04-28T07:04:07Z] Started /health request_id=-d95exGq4W8f-6n_Mc7Ag method=GET client_ip=127.0.0.1
supabase-imgproxy | INFO [2025-04-28T07:04:07Z] Completed in 63.754µs /health request_id=-d95exGq4W8f-6n_Mc7Ag method=GET status=200 client_ip=127.0.0.1
supabase-analytics |
supabase-analytics | 07:04:08.418 [notice] TLS :client: In state :hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:08.418 [warning] Failed to connect to https://http-intake.logs.datadoghq.eu:443: TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:08.421 [info] All logs logged!
supabase-analytics |
supabase-analytics | 07:04:08.421 [info] Logs last second!
supabase-analytics |
supabase-analytics | 07:04:08.453 [notice] TLS :client: In state :certify at ssl_handshake.erl:2177 generated CLIENT ALERT: Fatal - Unknown CA
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:08.453 [warning] Failed to connect to https://http-intake.logs.datadoghq.com:443: TLS client: In state certify at ssl_handshake.erl:2177 generated CLIENT ALERT: Fatal - Unknown CA
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:08.654 [notice] TLS :client: In state :hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:08.654 [warning] Failed to connect to https://http-intake.logs.us3.datadoghq.com:443: TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:08.701 [notice] TLS :client: In state :hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:08.701 [warning] Failed to connect to https://http-intake.logs.us3.datadoghq.com:443: TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:09.422 [info] All logs logged!
supabase-analytics |
supabase-analytics | 07:04:09.422 [info] Logs last second!
realtime-dev.supabase-realtime | 07:04:09.729 request_id=GDppiqOENMDk5DEAAAPC [info] HEAD /api/tenants/realtime-dev/health
realtime-dev.supabase-realtime | 07:04:09.729 request_id=GDppiqOENMDk5DEAAAPC [info] Sent 403 in 554µs
supabase-analytics |
supabase-analytics | 07:04:10.176 [notice] TLS :client: In state :hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:10.176 [warning] Failed to connect to https://http-intake.logs.ap1.datadoghq.com:443: TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:10.281 [notice] TLS :client: In state :hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:10.281 [warning] Failed to connect to https://http-intake.logs.us5.datadoghq.com:443: TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure
supabase-analytics |
supabase-analytics |
supabase-analytics | 07:04:10.423 [info] All logs logged!
supabase-analytics |
supabase-analytics | 07:04:10.423 [info] Logs last second!
supabase-analytics |
Same issue here, using:
- Windows 11 Home
- docker 28.0.4
Following the official documentation and running the docker-compose.yml file with:
docker compose up -d --build
Output:
[+] Running 24/25
✔ executor Built 0.0s
✔ migrate Built 0.0s
✔ rest_server Built 0.0s
✔ websocket_server Built 0.0s
✔ Network app-network Created 0.0s
✔ Network shared-network Created 0.0s
✔ Volume "autogpt_platform_supabase-config" Created 0.0s
✔ Container autogpt_platform-redis-1 Healthy 19.7s
✔ Container supabase-vector Healthy 12.3s
✔ Container rabbitmq Healthy 19.7s
✔ Container supabase-imgproxy Started 6.4s
✔ Container supabase-db Healthy 14.8s
- Container autogpt_platform-migrate-1 Waiting 917.1s
✘ Container supabase-analytics Error 96.7s
✔ Container supabase-auth Created 0.3s
✔ Container supabase-meta Created 0.4s
✔ Container supabase-rest Created 0.3s
✔ Container supabase-edge-functions Created 0.4s
✔ Container supabase-kong Created 0.3s
✔ Container supabase-studio Created 0.4s
✔ Container realtime-dev.supabase-realtime Created 0.4s
✔ Container autogpt_platform-websocket_server-1 Created 0.5s
✔ Container autogpt_platform-executor-1 Created 0.4s
✔ Container autogpt_platform-rest_server-1 Created 0.4s
✔ Container supabase-storage Created
Logs from autogpt_platform-migrate-1:
Skipping virtualenv creation, as specified in config file.
* Install prebuilt node (23.11.0) ..... done.
Prisma schema loaded from schema.prisma
Datasource "db": PostgreSQL database "postgres", schema "platform" at "db:5432"
Error: P1000: Authentication failed against database server at `db`, the provided database credentials for `postgres` are not valid.
Please make sure to provide valid database credentials for the database server at `db`.
Skipping virtualenv creation, as specified in config file.
Prisma schema loaded from schema.prisma
Datasource "db": PostgreSQL database "postgres", schema "platform" at "db:5432"
With the P1000 error looping.
Using the default .env / .env.example file:
############
# Secrets
# YOU MUST CHANGE THESE BEFORE GOING INTO PRODUCTION
############
POSTGRES_PASSWORD=your-super-secret-and-long-postgres-password
JWT_SECRET=your-super-secret-jwt-token-with-at-least-32-characters-long
ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyAgCiAgICAicm9sZSI6ICJhbm9uIiwKICAgICJpc3MiOiAic3VwYWJhc2UtZGVtbyIsCiAgICAiaWF0IjogMTY0MTc2OTIwMCwKICAgICJleHAiOiAxNzk5NTM1NjAwCn0.dc_X5iR_VP_qT0zsiyj_I_OZ2T9FtRU2BBNWN8Bu4GE
SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyAgCiAgICAicm9sZSI6ICJzZXJ2aWNlX3JvbGUiLAogICAgImlzcyI6ICJzdXBhYmFzZS1kZW1vIiwKICAgICJpYXQiOiAxNjQxNzY5MjAwLAogICAgImV4cCI6IDE3OTk1MzU2MDAKfQ.DaYlNEoUrrEn2Ig7tqibS-PHK5vgusbcbo7X36XVt4Q
DASHBOARD_USERNAME=supabase
DASHBOARD_PASSWORD=this_password_is_insecure_and_should_be_updated
SECRET_KEY_BASE=UpNVntn3cDxHJpq99YMc1T1AQgQpc8kfYTuRgBiYa15BLrx8etQoXz3gZv1/u2oq
VAULT_ENC_KEY=your-encryption-key-32-chars-min
############
# Database - You can change these to any PostgreSQL database that has logical replication enabled.
############
POSTGRES_HOST=db
POSTGRES_DB=postgres
POSTGRES_PORT=5432
# default user is postgres
############
# Supavisor -- Database pooler
############
POOLER_PROXY_PORT_TRANSACTION=6543
POOLER_DEFAULT_POOL_SIZE=20
POOLER_MAX_CLIENT_CONN=100
POOLER_TENANT_ID=your-tenant-id
############
# API Proxy - Configuration for the Kong Reverse proxy.
############
KONG_HTTP_PORT=8000
KONG_HTTPS_PORT=8443
############
# API - Configuration for PostgREST.
############
PGRST_DB_SCHEMAS=public,storage,graphql_public
############
# Auth - Configuration for the GoTrue authentication server.
############
## General
SITE_URL=http://localhost:3000
ADDITIONAL_REDIRECT_URLS=
JWT_EXPIRY=3600
DISABLE_SIGNUP=false
API_EXTERNAL_URL=http://localhost:8000
## Mailer Config
MAILER_URLPATHS_CONFIRMATION="/auth/v1/verify"
MAILER_URLPATHS_INVITE="/auth/v1/verify"
MAILER_URLPATHS_RECOVERY="/auth/v1/verify"
MAILER_URLPATHS_EMAIL_CHANGE="/auth/v1/verify"
## Email auth
ENABLE_EMAIL_SIGNUP=true
ENABLE_EMAIL_AUTOCONFIRM=false
[email protected]
SMTP_HOST=supabase-mail
SMTP_PORT=2500
SMTP_USER=fake_mail_user
SMTP_PASS=fake_mail_password
SMTP_SENDER_NAME=fake_sender
ENABLE_ANONYMOUS_USERS=false
## Phone auth
ENABLE_PHONE_SIGNUP=true
ENABLE_PHONE_AUTOCONFIRM=true
############
# Studio - Configuration for the Dashboard
############
STUDIO_DEFAULT_ORGANIZATION=Default Organization
STUDIO_DEFAULT_PROJECT=Default Project
STUDIO_PORT=3000
# replace if you intend to use Studio outside of localhost
SUPABASE_PUBLIC_URL=http://localhost:8000
# Enable webp support
IMGPROXY_ENABLE_WEBP_DETECTION=true
# Add your OpenAI API key to enable SQL Editor Assistant
OPENAI_API_KEY=
############
# Functions - Configuration for Functions
############
# NOTE: VERIFY_JWT applies to all functions. Per-function VERIFY_JWT is not supported yet.
FUNCTIONS_VERIFY_JWT=false
############
# Logs - Configuration for Logflare
# Please refer to https://supabase.com/docs/reference/self-hosting-analytics/introduction
############
LOGFLARE_LOGGER_BACKEND_API_KEY=your-super-secret-and-long-logflare-key
# Change vector.toml sinks to reflect this change
LOGFLARE_API_KEY=your-super-secret-and-long-logflare-key
# Docker socket location - this value will differ depending on your OS
DOCKER_SOCKET_LOCATION=/var/run/docker.sock
# Google Cloud Project details
GOOGLE_PROJECT_ID=GOOGLE_PROJECT_ID
GOOGLE_PROJECT_NUMBER=GOOGLE_PROJECT_NUMBER
agentgpt_platform is not working for me too. It has a migration-1 error and I configured everything I could in the .env and it still fails to migrate. It looks like a problem with Supabase database. How can I fix this?
"
Error: P1000: Authentication failed against database server at db, the provided database credentials for postgres are not valid.
Please make sure to provide valid database credentials for the database server at db.
Skipping virtualenv creation, as specified in config file.
Prisma schema loaded from schema.prisma
Datasource "db": PostgreSQL database "postgres", schema "platform" at "db:5432"
"
I encountered the same issue, and I found that some values like POSTGRES_PASSWORD and SERVICE_ROLE_KEY in the 'docker-compose.platform.yml' file were not set the same as in the '.env' file.
After updating them to match, the issue was resolved. : )
Thanks to this guy I managed to to overcome the issue. It is the docker-compose.platform.yml causing the db conflict.
I encountered the same issue, and I found that some values like POSTGRES_PASSWORD and SERVICE_ROLE_KEY in the 'docker-compose.platform.yml' file were not set the same as in the '.env' file. After updating them to match, the issue was resolved. : )
Thanks to this guy I managed to to overcome the issue. It is the docker-compose.platform.yml causing the db conflict.
I'll give it a try and check if it works for me.
I have the same issue, changed the database password, and it worked ONCE, can't remember why, but now I have to use the default "your-super-secret-and-long-postgres-password" password.
I've nuked the entire folder, volumes even images but can't get past that problem aswell.
Can't choose any password but the default one.
