We have released CLI v1.5.1 which uses postgres 14.1.0.71 and I have verified supabase start is working on GHA.

We will update 14.1.0.66 image later to fix older CLI versions.

We found the root cause: the supabase/postgres image that the CLI depends on was updated 10h ago with an arm64 build. Unfortunately the multi-arch manifest was not updated correctly, resulting in arm64 images being pulled on x86 machines. This broke GHA and anyone trying to supabase start on a fresh x86 computer without any locally cached docker images.

We are still looking into fixing the issue and will post an update once that’s resolved.

Error: Error response from daemon: No such image: public.ecr.aws/t3w2s2c9/postgres-meta:v0.45.0

This appears to be a new ephemeral error rather than a regression.

• Out of 131 supabase start commands we ran from CI on 1 Oct, 41 failed with a missing image error.
• After releasing v1.5.4, we ran 97 tests on 2 Oct and all of them succeeded.

I believe our fix is working well for the rate limit error when pulling from ECR. If you encounter further issues, please don’t hesitate to contact us.

Might I suggest that rather than relying on users to test that supabase start works on GitHub Actions, you have your own CI somewhere that verifies this and alerts you when it breaks?

Thanks for the feedback. We have since added a few automated tests to prevent regression.

1. CI workflow in cli repo now tests supabase start on each PR and merge to main
2. CLI Start workflow in setup-cli repo runs supabase start twice a day on version 1.5.4 and 1.0.0

And maybe automate the parts of your release process that is prone to human error?

We have also refactored the image pulling code to make it less prone human error. We now define an array of docker images and call the same function to pull each image.

It’s still broken. My GitHub Action:

- name: Install Supabase
  uses: supabase/setup-cli@v1.0.2
  with:
    version: 1.5.3

- name: Start Supabase
  run: supabase start

The error:

Applying supabase/seed.sql...
Starting containers...
Error: Error response from daemon: No such image: public.ecr.aws/t3w2s2c9/postgres-meta:v0.45.0
Error: Process completed with exit code 1.

Might I suggest that rather than relying on users to test that supabase start works on GitHub Actions, you have your own CI somewhere that verifies this and alerts you when it breaks? And maybe automate the parts of your release process that is prone to human error?

I’ve managed to make it start with a new workaround (my previous workaround spuriously fails with toomanyrequests: Rate exceeded - as mentioned in https://github.com/supabase/cli/issues/419#issuecomment-1232025865)

- name: Start Supabase
  run: |
    docker pull supabase/postgres:14.1.0.71 &&
    docker pull supabase/storage-api:v0.20.1 &&
    docker pull supabase/postgres-meta:v0.45.0 &&
    docker pull supabase/gotrue:v2.15.3 &&
    docker pull supabase/studio:v0.1.0 &&
    docker pull supabase/pgadmin-schema-diff:cli-0.0.5 &&
    docker pull kong:2.8.1 &&
    docker pull inbucket/inbucket:3.0.3 &&
    docker pull postgrest/postgrest:v9.0.1.20220717 &&
    docker pull supabase/realtime:v0.22.7 &&
    supabase start
  env:
    # https://github.com/supabase/cli/issues/419#issuecomment-1232025865
    SUPABASE_INTERNAL_IMAGE_REGISTRY: docker.io

I’m seeing the same thing as of this morning

I was able to fix this by deleting all containers and volumes then restarting supabase.