Supabase CLI 403 Forbidden z public.ecr.aws - Docker Hub lub własny rejestr

Festus Obi 03 czerwca 2026 7 min czytania
Contents
Jeśli supabase start zwraca błąd 403 Forbidden z public.ecr.aws, rozwiązanie jest proste. Możesz nadpisać domyślny rejestr obrazów, żeby pobierać je z Docker Hub.

Dlaczego public.ecr.aws zwraca 403

Supabase CLI domyślnie pobiera obrazy kontenerów z public.ecr.aws. To publiczny Elastic Container Registry od Amazona, który w wielu środowiskach po prostu nie działa.

Typowe przyczyny błędu 403:

  • Firewalle korporacyjne i VPN, które blokują dostęp do publicznych endpointów AWS.
  • Ograniczenia regionalne. Niektóre sieci w określonych regionach ograniczają lub całkowicie blokują dostęp do publicznego ECR.
  • Środowiska CI, w których ruch wychodzący jest ograniczony do znanych rejestrów (Docker Hub, GHCR), ale nie ECR.
  • Ograniczenia częstotliwości pobierania (rate limiting). AWS stosuje limity dla publicznego ECR, a współdzielone adresy IP w środowiskach deweloperskich w chmurze mogą je szybko wyczerpać.

Efekt jest ten sam: supabase start zawiesza się lub zwraca 403 Forbidden, a lokalne środowisko deweloperskie nie uruchamia się.

 

Rozwiązanie: zmiana rejestru obrazów

Ustaw zmienną środowiskową SUPABASE_INTERNAL_IMAGE_REGISTRY, żeby wskazać CLI pobieranie z Docker Hub zamiast public.ecr.aws.

Jednorazowe użycie:

SUPABASE_INTERNAL_IMAGE_REGISTRY=docker.io supabase start

To polecenie pobiera wszystkie obrazy Supabase z Docker Hub dla tego jednego wywołania. Obrazy są identyczne, zmienia się tylko rejestr.

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

export SUPABASE_INTERNAL_IMAGE_REGISTRY=docker.io

Następnie przeładuj powłokę lub uruchom source ~/.zshrc. Każde kolejne wywołanie supabase start będzie automatycznie korzystać z Docker Hub.

 

Trwałe rozwiązanie: własne obrazy w prywatnym rejestrze

Zmiana rejestru na Docker Hub rozwiązuje problem natychmiast. Ale w środowisku produkcyjnym poleganie na jakimkolwiek publicznym rejestrze (Docker Hub, GHCR, czy public.ecr.aws) to ryzyko. Trwałe rozwiązanie to posiadanie własnych obrazów.

Podejście jest proste. Stwórz minimalny Dockerfile dla każdego serwisu Supabase:

FROM supabase/postgrest:v12.2.3
# To wystarczy do podstawowego przebudowania

Następnie wypchnij do własnego prywatnego rejestru (ECR, GHCR, lub dowolny rejestr pod Twoją kontrolą). Zyskujesz:

  • Brak zależności od publicznych rejestrów. Środowisko produkcyjne nigdy nie sięga do Docker Hub, GHCR, ani public.ecr.aws. Jeśli którykolwiek z nich padnie lub Cię zablokuje, nic się nie psuje.
  • Skanowanie podatności. Amazon Inspector, Trivy, lub Snyk mogą skanować obrazy przy każdym buildzie. Wiesz dokładnie, co uruchamiasz.
  • Łatanie bezpieczeństwa. Dodawanie certyfikatów, stosowanie poprawek na poziomie OS, utwardzanie bazowego obrazu. Wiele ram compliance tego wymaga.
  • Podpisywanie obrazów. AWS Signer integruje się z ECR, żeby weryfikować pochodzenie obrazów. Możesz wymusić, że tylko podpisane obrazy z Twojego pipeline uruchamiają się na produkcji.
  • Widoczność łańcucha dostaw. Kontrolujesz, co wchodzi do Twojego środowiska. Żadnych niespodziewanych zmian upstream, żadnych niezweryfikowanych warstw z Docker Hub. Zobacz nasze usługi bezpieczeństwa i compliance, żeby poznać, jak wdrażamy to dla środowisk regulowanych.

Pipeline CI buduje, skanuje, podpisuje i dostarcza obrazy zgodnie z harmonogramem (lub na podstawie nowych wydań upstream). Twój docker-compose.yml lub definicje tasków ECS wskazują na prywatny rejestr. Gotowe.

Dla zespołów uruchamiających Supabase na AWS, ECR z pull-through cache to rozwiązanie pośrednie: buforuje obrazy upstream lokalnie na Twoim koncie, daje skanowanie Inspector i trzyma wszystko wewnątrz VPC. Żadnych błędów 403, żadnych limitów. Zobacz nasz przewodnik po self-hostingu Supabase na AWS po pełną architekturę.

To więcej pracy niż jednoliniowa zmienna środowiskowa, ale to podejście, które skaluje się i zadowala audytorów.

 

Alternatywa: GHCR

GitHub Container Registry to kolejna opcja, szczególnie jeśli Twoja sieć już pozwala na dostęp do ghcr.io:

SUPABASE_INTERNAL_IMAGE_REGISTRY=ghcr.io supabase start

GHCR nie ma ograniczeń częstotliwości pobierania dla publicznych obrazów, co czyni go solidnym wyborem dla pipeline CI, które już uwierzytelniają się w GitHub.

 

Podejście z config.toml

Jeśli korzystasz z Supabase CLI w wersji 2 lub nowszej, możesz ustawić zmianę rejestru w pliku supabase/config.toml projektu. Dzięki temu każdy członek zespołu otrzymuje tę samą konfigurację bez potrzeby ustawiania zmiennych środowiskowych:

[api]
# ... existing config

[experimental]
image_registry = "docker.io"

To podejście pozwala trzymać konfigurację w kontroli wersji i zachować spójność między maszynami. Sprawdź dokumentację konfiguracji Supabase CLI, żeby poznać dokładną składnię dla Twojej wersji CLI, ponieważ struktura konfiguracji ewoluowała między wydaniami.

 

Obejście przez Docker Compose (self-hosting)

W przypadku wdrożeń self-hosted Supabase, które korzystają bezpośrednio z Docker Compose (nie z CLI), referencje do obrazów znajdują się w pliku docker-compose.yml. Zamień prefiksy ECR na odpowiedniki z Docker Hub lub GHCR.

Przed zmianą:

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

Po zmianie (Docker Hub):

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

Lub z użyciem GHCR:

services:
  auth:
    image: ghcr.io/supabase/gotrue:v2.158.1
  rest:
    image: ghcr.io/supabase/postgrest:v12.2.3
  realtime:
    image: ghcr.io/supabase/realtime:v2.30.34

Tagi wersji pozostają takie same. Zmienia się wyłącznie prefiks rejestru. Pełny przewodnik po self-hostingu bez ECR znajdziesz w naszym artykule o self-hostingu Supabase na AWS bez ECR.

 

Weryfikacja poprawki

Po uruchomieniu supabase start ze zmianą rejestru sprawdź, czy obrazy zostały pobrane z właściwego źródła:

docker images | grep supabase

Powinieneś zobaczyć wpisy takie jak:

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), oznacza to, że użyto Docker Hub. Dla GHCR wpisy będą miały prefiks ghcr.io/supabase/.

 

Pomoc z produkcyjnym hostingiem Supabase

Niezależnie od tego, czy potrzebujesz szybkiej zmiany rejestru na Docker Hub dla środowiska deweloperskiego, czy pełnego produkcyjnego setupu z prywatnym rejestrem, skanowaniem obrazów i podpisywaniem, nasz zespół migracji do chmury może pomóc. Budujemy pipeline CI, który przebudowuje, skanuje i dostarcza obrazy Supabase do Twojego własnego rejestru przy każdym nowym wydaniu upstream.

Supabase Docker ECR self-hosting CLI
festus.webp
Festus Obi
DevOps Engineer

Ma kilkuletnie doświadczenie w pracy w obszarze DevOps. Lubi tworzyć zarówno treści pisemne, jak i wideo dotyczące DevOps oraz wszelkich tematów wspierających rozwój oprogramowania.

Spis treści

Przeczytaj również:

Poprzedni post