fix(compose): BUZZ_S3_ENDPOINT is hardcoded, so .env cannot point media at external S3

Open Beginner friendly
#3,794 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
docker-compose
Domain
devops

Research direction

Start with deploy/compose/compose.yml:14 and compare its relay S3 environment with the settings documented in .env.example. Run the documented Docker Compose reproduction, checking the relay environment and upload destination with and without BUZZ_S3_ENDPOINT. Done means the .env value reaches the relay while an unset value still uses bundled MinIO.

Written by the indexing model from the issue text.

Description

Describe the bug

deploy/compose/compose.yml:14 hardcodes the S3 endpoint on the relay service:

BUZZ_S3_ENDPOINT: http://minio:9000

Every other S3 setting is env-driven and documented in .env.exampleBUZZ_S3_ACCESS_KEY, BUZZ_S3_SECRET_KEY, BUZZ_S3_BUCKET, BUZZ_S3_ADDRESSING_STYLE — so setting BUZZ_S3_ENDPOINT there looks like it should work. It is silently ignored, and the relay keeps using the bundled MinIO.

The failure is quiet: the stack comes up, Media storage connected is logged, and uploads succeed — into MinIO on local disk rather than the configured bucket. Nothing indicates the endpoint was overridden.

This matters because the Helm chart directs production deployments the other way (deploy/charts/buzz/values.yaml):

Production: point endpoint/bucket at an external S3-compatible service and supply credentials. Quickstart (minio.enabled: true): the chart runs an in-cluster, eval-only MinIO.

So compose users following the same guidance get local MinIO regardless of what they configure.

Steps to reproduce

  1. Set BUZZ_S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com in deploy/compose/.env.
  2. docker compose up -d.
  3. docker exec <relay> printenv BUZZ_S3_ENDPOINThttp://minio:9000.
  4. Uploads land in the bundled MinIO volume, not the configured bucket.

Expected behavior

BUZZ_S3_ENDPOINT honours .env like the other BUZZ_S3_* values, defaulting to the bundled MinIO when unset:

BUZZ_S3_ENDPOINT: ${BUZZ_S3_ENDPOINT:-http://minio:9000}

Ideally with the variable added to .env.example alongside the other S3 settings.

Version and platform

  • Buzz version: relay ghcr.io/block/buzz:sha-63496cc; also present on main as of 2026-07-30
  • OS: Ubuntu 24.04, Docker Compose

Logs / additional context

Workaround is a compose override that also has to reset the MinIO health dependency, since the relay depends_on it:

services:
  relay:
    environment:
      BUZZ_S3_ENDPOINT: ${BUZZ_S3_ENDPOINT:?}
    depends_on: !reset
      postgres: {condition: service_healthy}
      redis: {condition: service_healthy}
  minio: {profiles: ["disabled"]}
  minio-init: {profiles: ["disabled"]}

Possibly related to #3273 (hardcoded path-style S3 addressing), which is the same class of compose-level S3 config being fixed rather than configurable.

Dominant language
Rust
Stars
33.7k
Forks
4.4k
Avg merge
1d 21h
Merged PRs (30d)
239

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from block/buzz

All issues in block/buzz

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.