Supabase Docker AWS

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"
Jerzy Kopaczewski

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.