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"
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.