Supabase CLI public.ecr.aws 403 Forbidden: switch to Docker Hub or your own registry
Fix supabase start failing with 403 Forbidden from public.ecr.aws by overriding the image registry to Docker Hub, GHCR, or your own private registry.
supabase start failing with a 403 Forbidden from public.ecr.aws? The fix is a one-liner: override the image registry to pull from Docker Hub instead.
Symptoms
supabase start hangs or fails with a 403 Forbidden error. The CLI can’t pull container images from public.ecr.aws:
supabase start
# Error: pulling image public.ecr.aws/supabase/postgres:15.6.1.143
# 403 Forbidden
Your local development environment won’t come up. All Supabase services fail to start because their images can’t be fetched.
Cause
The Supabase CLI defaults to pulling container images from public.ecr.aws (Amazon’s public Elastic Container Registry). This fails in many environments:
- Corporate firewalls and VPNs that block access to AWS public endpoints.
- Regional restrictions. Some networks throttle or block ECR public access entirely.
- CI environments where outbound access is limited to Docker Hub and GHCR but not ECR.
- Rate limiting. AWS applies pull rate limits to public ECR, and shared IPs in cloud-hosted dev environments exhaust these quickly.
Fix
Quick fix: override the registry with an environment variable
SUPABASE_INTERNAL_IMAGE_REGISTRY=docker.io supabase start
This pulls all Supabase images from Docker Hub. The images are identical, just hosted on a different registry.
To make the override permanent, add to your shell profile (~/.bashrc, ~/.zshrc):
export SUPABASE_INTERNAL_IMAGE_REGISTRY=docker.io
Alternative: use GHCR
If your network already allows ghcr.io:
SUPABASE_INTERNAL_IMAGE_REGISTRY=ghcr.io supabase start
GHCR has no pull rate limits for public images, making it solid for CI pipelines.
config.toml approach (CLI v2+)
Set the override in your project’s supabase/config.toml for team-wide consistency:
[experimental]
image_registry = "docker.io"
Docker Compose workaround (self-hosting)
For self-hosted deployments using Docker Compose directly, replace ECR prefixes:
Before:
services:
auth:
image: public.ecr.aws/supabase/gotrue:v2.158.1
rest:
image: public.ecr.aws/supabase/postgrest:v12.2.3
After (Docker Hub):
services:
auth:
image: supabase/gotrue:v2.158.1
rest:
image: supabase/postgrest:v12.2.3
Production-grade: build and host your own images
For production workloads, own your images. Create a minimal Dockerfile per service:
FROM supabase/postgrest:v12.2.3
Push to your private registry (ECR, GHCR). This gives you vulnerability scanning, image signing, no public registry dependency, and supply chain visibility. For the full architecture, see our self-hosting Supabase on AWS without ECR guide.
Validation
After running supabase start with the registry override, confirm images pulled from the correct source:
docker images | grep supabase
Expected output:
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
If the REPOSITORY column shows supabase/ (no public.ecr.aws prefix), Docker Hub was used. For GHCR, entries show ghcr.io/supabase/.
Also verify all services are running:
supabase status
# All services should show "running"
Need help with production Supabase hosting?
Book a free 30-minute call. We build the CI pipeline that rebuilds, scans, and delivers Supabase images to your own registry.