[bug]: USE_MINIO and AWS_S3_CUSTOM_DOMAIN do not align semantically when using external Minio / S3

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

When setting USE_MINIO to 1 while using an external instance at another domain, omitting the route through the Plane web proxy, asset URLs are malformed. This stops them from being loaded.

This is due to assuming an external S3 endpoint would always be served behind the Plane web proxy. For decoupling the two services in a distributed system, it would be preferred being able to differentiate between these cases:

• USE_MINIO / USE_INTERNAL_MINIO
• USE_EXTERNAL_S3

It appears USE_MINIO actually means USE_INTERNAL_MINIO. It's naming is further complicated, since setting the variable is required to use other S3 providers as well.

https://github.com/makeplane/plane/blob/9ee1d8cb03dc3ee061534e7a0acb18c6e1ae31d3/apiserver/plane/settings/common.py#L230-L233

The common settings always assumes we deploy a non-AWS S3 behind the Plane web proxy

This works when AWS_S3_ENDPOINT_URL points to the internal http://plane-minio:9000. It fails when setting it to https://s3.example.com.

https://github.com/makeplane/plane/blob/9ee1d8cb03dc3ee061534e7a0acb18c6e1ae31d3/apiserver/plane/app/views/project/base.py#L603-L609

The cover image endpoint only recognises the AWS_S3_ENDPOINT_URL when USE_MINIO is set.

This leaves out the case where we want to set a custom AWS_S3_ENDPOINT_URL, but do not want to serve the bucket behind the same load balancer, e.g. via another host. This is useful for independently scaling out application and backing services.

There is a PR which only partially resolves this situation, by allowing to configure the Minio URL in the web proxy:

• https://github.com/makeplane/plane/pull/3278

In the cover image example below, we receive this URL:

• https://plane.example.org/org.example.plane/d41f7590-e557-407c-b171-f58d24030874/c51d301a972b430db7afbebdb41bc54a-ac7183d975acc2e9.png?response-content-disposition=inline&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=org.example.plane/20250310/eu-central-1/s3/aws4_request&X-Amz-Date=20250310T202619Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=ac7f088b1991817246f5ae339e970ec67c9cf973a0fb1ea903354d426d32c9dc

While we would like to see this:

• https://s3.example.com/org.example.plane/d41f7590-e557-407c-b171-f58d24030874/c51d301a972b430db7afbebdb41bc54a-ac7183d975acc2e9.png?response-content-disposition=inline&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=org.example.plane/20250310/eu-central-1/s3/aws4_request&X-Amz-Date=20250310T202619Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=ac7f088b1991817246f5ae339e970ec67c9cf973a0fb1ea903354d426d32c9dc

The URLs are generated in:

https://github.com/makeplane/plane/blob/9ee1d8cb03dc3ee061534e7a0acb18c6e1ae31d3/apiserver/plane/bgtasks/export_task.py#L92-L99

The wrong assumption in common.py about AWS_S3_CUSTOM_DOMAIN is, that we always want to serve Minio/other S3 providers that are not AWS behind the Plane load balancer. This assumption is also present in the proposed partial fix https://github.com/makeplane/plane/pull/3278.

There should be cases possible in which we do not replace the AWS_S3_CUSTOM_DOMAIN, even when USE_MINIO is set.

Related issues:

• https://github.com/makeplane/plane/issues/1318
• https://github.com/makeplane/plane/issues/2345
• https://github.com/makeplane/plane/issues/3490
• https://github.com/makeplane/plane/issues/4248
• https://github.com/makeplane/plane/issues/5680

Steps to reproduce

1. Upload a cover image to a new project
2. Save the project
3. Find a 404 GET request in the browser console.

Environment

Production

Browser

Mozilla Firefox

Variant

Self-hosted

Version

v0.25.1