Skip to content

feat(supabase): make storage S3 backend configurable via env - #85

Open
Carlos-Vera wants to merge 1 commit into
easypanel-io:24-07-2026from
Carlos-Vera:feat/storage-s3-env
Open

feat(supabase): make storage S3 backend configurable via env#85
Carlos-Vera wants to merge 1 commit into
easypanel-io:24-07-2026from
Carlos-Vera:feat/storage-s3-env

Conversation

@Carlos-Vera

@Carlos-Vera Carlos-Vera commented Sep 7, 2026

Copy link
Copy Markdown

Problem

The Supabase template ships the S3 backend settings as commented-out literals:

      STORAGE_BACKEND: file
      #GLOBAL_S3_ENDPOINT: https://your-s3-endpoint
      #GLOBAL_S3_PROTOCOL: https
      #GLOBAL_S3_FORCE_PATH_STYLE: "true"
      #AWS_ACCESS_KEY_ID: your-access-key-id
      #AWS_SECRET_ACCESS_KEY: your-secret-access-key

So pointing storage at an external S3-compatible service means editing the compose file
by hand. On platforms like EasyPanel the service is sourced from git and the file is
rewritten on every deploy, so the edit is lost. And since no service in this template
uses env_file, only what the YAML declares under environment: ever reaches the
container — setting these in the platform's env UI has no effect.

docker-compose.s3.yml does not cover this case: it wires up a local MinIO with a fixed
GLOBAL_S3_ENDPOINT: http://minio:9000.

Change

Expose the five settings as environment variables, keeping file as the default so
existing deployments are unaffected, and document them in .env.example.

Also adds TUS_ALLOW_S3_TAGS (default true, unchanged behaviour): Cloudflare R2 does
not implement x-amz-tagging, and resumable (TUS) uploads fail with HTTP 500 unless it
is set to "false".

Verification

$ docker compose --env-file .env.example config | grep -E '^ +STORAGE_BACKEND:'
      STORAGE_BACKEND: file

$ STORAGE_BACKEND=s3 GLOBAL_S3_ENDPOINT=https://acct.r2.cloudflarestorage.com \
  TUS_ALLOW_S3_TAGS=false AWS_ACCESS_KEY_ID=k AWS_SECRET_ACCESS_KEY=s \
  docker compose --env-file .env.example config | grep -E 'STORAGE_BACKEND|GLOBAL_S3_ENDPOINT|TUS_ALLOW_S3_TAGS'
      GLOBAL_S3_ENDPOINT: https://acct.r2.cloudflarestorage.com
      STORAGE_BACKEND: s3
      TUS_ALLOW_S3_TAGS: "false"

Default deployments resolve exactly as before; only an explicit STORAGE_BACKEND=s3
changes anything.

Running in production on a Supabase self-host serving ~29k images from Cloudflare R2.


By Carlos Vera of BravesLab
con el favor de nuestro señor JesusCristo.

The template ships the S3 backend settings as commented-out literals, so
switching storage to S3 means editing the compose file by hand. That does not
survive on platforms like EasyPanel, where the service is sourced from git and
the file is rewritten on every deploy.

Expose them as environment variables instead, keeping 'file' as the default so
existing deployments are unaffected. docker-compose.s3.yml stays as-is: it wires
up a local MinIO with a fixed endpoint, which does not cover an external
S3-compatible service.

Also adds TUS_ALLOW_S3_TAGS: Cloudflare R2 does not implement x-amz-tagging, and
resumable (TUS) uploads fail with HTTP 500 unless it is set to "false".

Autor: Carlos Vera <carlos@braveslab.com>
---
“Todo lo puedo en Cristo que me fortalece.” fil 4:13
@Carlos-Vera
Carlos-Vera marked this pull request as ready for review September 7, 2026 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant