Supabase Docker AWS

Supabase CLI public.ecr.aws 403 Forbidden: przełącz na Docker Hub lub własny rejestr

Naprawa błędu 403 Forbidden z public.ecr.aws w supabase start przez zmianę rejestru obrazów na Docker Hub, GHCR lub własny prywatny rejestr.

·
supabase start zwraca 403 Forbidden z public.ecr.aws? Rozwiązanie to jedna linia: zmiana rejestru obrazów na Docker Hub.

Objaw

supabase start zawiesza się lub zwraca błąd 403 Forbidden. CLI nie może pobrać obrazów kontenerów z public.ecr.aws:

supabase start
# Error: pulling image public.ecr.aws/supabase/postgres:15.6.1.143
# 403 Forbidden

Lokalne środowisko deweloperskie nie uruchamia się. Wszystkie serwisy Supabase nie startują, bo ich obrazy nie mogą zostać pobrane.

Przyczyna

Supabase CLI domyślnie pobiera obrazy kontenerów z public.ecr.aws (publiczny Elastic Container Registry od Amazona). W wielu środowiskach to nie działa:

  • Firewalle korporacyjne i VPN, które blokują dostęp do publicznych endpointów AWS.
  • Ograniczenia regionalne. Niektóre sieci ograniczają lub blokują dostęp do publicznego ECR.
  • Środowiska CI, w których ruch wychodzący jest ograniczony do Docker Hub i GHCR, ale nie ECR.
  • Rate limiting. AWS stosuje limity pobierania dla publicznego ECR, a współdzielone IP w środowiskach chmurowych szybko je wyczerpują.

Rozwiązanie

Szybki fix: zmiana rejestru zmienną środowiskową

SUPABASE_INTERNAL_IMAGE_REGISTRY=docker.io supabase start

Pobiera wszystkie obrazy Supabase z Docker Hub. Obrazy są identyczne, zmienia się tylko rejestr.

Żeby zmiana była trwała, dodaj do profilu powłoki (~/.bashrc, ~/.zshrc):

export SUPABASE_INTERNAL_IMAGE_REGISTRY=docker.io

Alternatywa: GHCR

Jeśli Twoja sieć pozwala na dostęp do ghcr.io:

SUPABASE_INTERNAL_IMAGE_REGISTRY=ghcr.io supabase start

GHCR nie ma limitów pobierania dla publicznych obrazów, co sprawdza się w pipeline CI.

Podejście z config.toml (CLI v2+)

Ustaw zmianę rejestru w supabase/config.toml projektu dla spójności w zespole:

[experimental]
image_registry = "docker.io"

Obejście przez Docker Compose (self-hosting)

Dla wdrożeń self-hosted korzystających bezpośrednio z Docker Compose zamień prefiksy ECR:

Przed:

services:
  auth:
    image: public.ecr.aws/supabase/gotrue:v2.158.1
  rest:
    image: public.ecr.aws/supabase/postgrest:v12.2.3

Po (Docker Hub):

services:
  auth:
    image: supabase/gotrue:v2.158.1
  rest:
    image: supabase/postgrest:v12.2.3

Produkcyjne rozwiązanie: własne obrazy w prywatnym rejestrze

Na produkcji posiadaj własne obrazy. Stwórz minimalny Dockerfile per serwis:

FROM supabase/postgrest:v12.2.3

Wypchnij do prywatnego rejestru (ECR, GHCR). Zyskujesz skanowanie podatności, podpisywanie obrazów, brak zależności od publicznych rejestrów i widoczność łańcucha dostaw. Pełną architekturę znajdziesz w naszym przewodniku po self-hostingu Supabase na AWS bez ECR.

Walidacja

Po uruchomieniu supabase start ze zmianą rejestru sprawdź źródło pobranych obrazów:

docker images | grep supabase

Oczekiwany wynik:

supabase/postgres       15.6.1.143   abc123def456   2 days ago   1.2GB
supabase/gotrue         v2.158.1     789ghi012jkl   3 days ago   45MB
supabase/postgrest      v12.2.3      345mno678pqr   5 days ago   22MB

Jeśli kolumna REPOSITORY pokazuje supabase/ (bez prefiksu public.ecr.aws), użyto Docker Hub. Dla GHCR wpisy mają prefiks ghcr.io/supabase/.

Sprawdź też, że wszystkie serwisy działają:

supabase status
# Wszystkie serwisy powinny mieć status "running"
Jerzy Kopaczewski

Potrzebujesz pomocy z produkcyjnym hostingiem Supabase?

Umów bezpłatną 30-minutową rozmowę. Budujemy pipeline CI, który przebudowuje, skanuje i dostarcza obrazy Supabase do Twojego rejestru.