Warden
Strapi version:
v5
---
What I'm asking for
Two related improvements to how upload providers work:
  1. Multiple simultaneous providers
    — configure more than one storage backend and route uploads to the appropriate one based on content type, folder, or an explicit choice at upload time.
  2. Provider configuration in admin settings
    — store provider credentials and options in the Strapi config store (editable in the Settings UI) instead of requiring them to be hardcoded in
    config/plugins.js
    or environment variables.
Current behaviour
Strapi supports exactly one upload provider at a time. It is configured statically via
config/plugins.js
or environment variables, which means:
  • Changing provider or rotating credentials requires a code change and redeployment
  • There is no way to route different uploads to different storage backends
  • Non-developer admins cannot change storage settings without touching code
Expected behaviour
Multiple providers:
  • Register N providers, each with a unique key (e.g.
    s3-private
    ,
    cloudinary-public
    ,
    local
    )
  • A default provider is used when none is specified
  • The active provider can be specified per-folder in the media library, per media field in a content type, or passed explicitly in the Upload API call
Admin-managed configuration:
  • A dedicated
    Upload
    section appears under Settings in the admin panel
  • Each registered provider displays its configurable options (bucket, region, API key, etc.) as editable fields
  • Values are stored encrypted in the Strapi config store; no restart required for credential changes
  • Environment variables remain supported and take precedence over admin-stored values (for CI/CD pipelines and secrets managers)
Why this matters
Applications that handle both private documents (contracts, invoices, guest IDs) and public media (listing photos, logos) need different storage destinations with different access rules. Today this requires a custom middleware. Admin-managed config also makes Strapi viable for self-hosted setups where the operator deploying the instance is not the developer who built it — they can rotate an S3 key themselves without opening a code repository.