Self-hosting compose files fail to deploy: `minio/minio` and `minio/mc` are gone from Docker Hub (+ Coolify generates a too-short `DATABASE_ENCRYPTION_KEY`)

Start with docker-compose.yml, docker-compose.coolify.yml, and docker-compose.template.yml, then inspect packages/database/crypto.ts and the listed encryption call sites. Run the compose deployment and health checks on the supported Coolify version, including the template-specific setup. Done means the images pull, services become healthy, and encryption-dependent features no longer reject the generated key.

Summary

Following the self-hosting guide on 2026-09-29 with docker-compose.coolify.yml (Coolify v4.3.23), I hit two problems. The first one is not Coolify-specific: docker-compose.yml uses the same images.

1. The deployment fails at image pull because the MinIO images no longer exist on Docker Hub.
2. After working around that, the Coolify template generates a DATABASE_ENCRYPTION_KEY that Cap rejects as the wrong length.

1. MinIO images no longer exist on Docker Hub

Pull log from Coolify:

Image minio/mc:latest Error pull access denied for minio/mc, repository does not exist or may require 'docker login'
Image minio/minio:latest Interrupted

The Docker Hub API returns object not found for both minio/minio and minio/mc. bitnami/minio, which docker-compose.template.yml uses, has 0 tags left.

Affected files:

• docker-compose.yml (minio/minio:latest, minio/mc:latest)
• docker-compose.coolify.yml (minio/minio:latest, minio/mc:latest)
• docker-compose.template.yml (bitnami/minio:latest)

Related: #1770 (MinIO repository archival). That issue raises the long-term concern; this one is the concrete breakage it led to.

2. SERVICE_HEX_32_* now yields a 16-byte key on Coolify

packages/database/crypto.ts requires DATABASE_ENCRYPTION_KEY to decode to exactly 32 bytes (KEY_LENGTH = 32, Buffer.from(key, "hex")), which is 64 hex characters.

Since Coolify 4.3.1 (coollabsio/coolify#9820), SERVICE_HEX_32_* generates 32 hex characters (16 bytes) instead of 64. On Coolify v4.3.23 the generated SERVICE_HEX_32_DATABASEENCRYPTIONKEY is 32 characters long, so ENCRYPTION_KEY() throws Invalid encryption key format: Encryption key must be 32 bytes (64 hex characters).

Every feature that encrypts data then fails, including password-protected videos (lib/password-cookie.ts), custom S3 storage (actions/organization/storage.ts, Storage/StorageRepo.ts), developer apps and API keys (actions/developers/*), integrations (lib/integrations/installations.ts) and the Google Drive storage quota.

NEXTAUTH_SECRET and MEDIA_SERVER_WEBHOOK_SECRET have no length requirement, so they are fine as they are.

Proposed fix

• Replace the MinIO images with pgsty/minio and pgsty/mc. Silo is the community-maintained MinIO fork published by Pigsty (AGPLv3, about 1M pulls, updated in 2026). It is a drop-in replacement:
  • The image ships the minio binary with the same docker-entrypoint.sh, so command: server /data ... is unchanged.
  • It bundles mcli, symlinked as mc, so the mc ready local healthcheck keeps working.
  • It uses the same MINIO_ROOT_USER / MINIO_ROOT_PASSWORD variables and the same on-disk format.
• In docker-compose.coolify.yml, use SERVICE_HEX_64_DATABASEENCRYPTIONKEY so that current Coolify generates 64 hex characters.

I tested this on Coolify v4.3.23: all services report healthy, Let's Encrypt certificates are issued for the web app and the S3 domain, and Google sign-in works.

diff --git a/docker-compose.coolify.yml b/docker-compose.coolify.yml
--- a/docker-compose.coolify.yml
+++ b/docker-compose.coolify.yml
@@ -13,7 +13,7 @@ services:
       DATABASE_URL: 'mysql://cap:${SERVICE_PASSWORD_MYSQL}@mysql:3306/cap'
       WEB_URL: '${SERVICE_URL_CAP_WEB}'
       NEXTAUTH_URL: '${SERVICE_URL_CAP_WEB}'
-      DATABASE_ENCRYPTION_KEY: '${SERVICE_HEX_32_DATABASEENCRYPTIONKEY}'
+      DATABASE_ENCRYPTION_KEY: '${SERVICE_HEX_64_DATABASEENCRYPTIONKEY}'
       NEXTAUTH_SECRET: '${SERVICE_HEX_32_NEXTAUTHSECRET}'
       CAP_AWS_ACCESS_KEY: capadmin
       CAP_AWS_SECRET_KEY: '${SERVICE_PASSWORD_MINIO}'
@@ -88,7 +88,7 @@ services:
       retries: 10
       start_period: 30s
   minio:
-    image: 'minio/minio:latest'
+    image: 'pgsty/minio:latest'
     restart: unless-stopped
     command: 'server /data --console-address ":9001"'
     environment:
@@ -109,7 +109,7 @@ services:
       start_period: 10s
   minio-setup:
     container_name: cap-minio-setup
-    image: 'minio/mc:latest'
+    image: 'pgsty/mc:latest'
     exclude_from_hc: true
     depends_on:
       minio:
diff --git a/docker-compose.yml b/docker-compose.yml
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -88,7 +88,7 @@ services:
 
   minio:
     container_name: cap-minio
-    image: minio/minio:latest
+    image: pgsty/minio:latest
     restart: unless-stopped
     command: server /data --console-address ":9001"
     environment:
@@ -110,7 +110,7 @@ services:
 
   minio-setup:
     container_name: cap-minio-setup
-    image: minio/mc:latest
+    image: pgsty/mc:latest
     depends_on:
       minio:
         condition: service_healthy

Caveats for maintainers

• Coolify < 4.3.1: on these versions SERVICE_HEX_64_* produces 128 characters, which would also be rejected. Two options:

  • document Coolify ≥ 4.3.1 as the minimum version;
  • or make crypto.ts tolerant: when the key is not 64 hex characters, derive 32 bytes from it with SHA-256. Valid existing keys keep their current behaviour, so this change is backward compatible.

• Existing Coolify deployments: changing the variable name generates a new key. Installs on Coolify ≥ 4.3.1 never had a valid key, so nothing was encrypted and nothing is lost. Installs on older Coolify had a valid 64-character key, and should keep their current value.

• docker-compose.template.yml: moving from bitnami/minio to pgsty/minio needs more than an image swap:

  • replace the Bitnami-specific MINIO_API_PORT_NUMBER / MINIO_CONSOLE_PORT_NUMBER with command: server /data --address ":3902" --console-address ":3903" --certs-dir /certs;
  • mount the data volume at /data instead of /bitnami/minio/data.

  I left this file out of the diff above.