Why cloud provider plugins stop working after deployment to Strapi Cloud

Last updated: November 17, 2025

If your cloud provider plugins (such as AWS S3, Cloudinary, or SendGrid) work correctly in local development but fail after deployment to Strapi Cloud, this is likely due to a known limitation with environment variable access during the build process.

The Problem

Strapi Cloud has a limitation where custom environment variables defined in your project settings are not accessible during the build step when used in configuration files like config/plugins.ts. This causes third-party provider configurations to return undefined during the build process, resulting in deployment failures.

Additionally, STRAPI_ADMIN_ prefixed environment variables have a separate limitation in Strapi Cloud - they cannot be accessed in the admin panel even when defined in custom environment variables. Unlike self-hosted Strapi installations where these variables are automatically exposed to the frontend, Strapi Cloud requires a custom route/controller to access backend environment variables from the admin panel.

This limitation particularly affects:

  • Cloud storage providers (Google Cloud Storage, AWS S3, Cloudinary)

  • Email service providers (SendGrid, Mailgun)

  • Any plugin that requires custom environment variables during initialization

  • Third-party service integrations that need API keys or configuration values

  • Admin panel customizations that need to access STRAPI_ADMIN_ prefixed variables

The Solution

To resolve this issue, move your environment-dependent provider configurations from config/plugins.ts to environment-specific configuration files.

Step 1: Create Environment-Specific Config

Instead of configuring your plugins in config/plugins.ts, create an environment-specific configuration file:

./config/env/production/plugins.ts

Step 2: Move Your Configuration

Move your cloud provider plugin configuration from the main plugins file to the production-specific file. For example, if you have an S3 configuration:

Instead of this in config/plugins.ts:

export default {
upload: {
config: {
provider: 'aws-s3',
providerOptions: {
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
region: process.env.AWS_REGION,
params: {
Bucket: process.env.AWS_BUCKET_NAME,
},
},
},
},
};

Use this in config/env/production/plugins.ts:

export default {
upload: {
config: {
provider: 'aws-s3',
providerOptions: {
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
region: process.env.AWS_REGION,
params: {
Bucket: process.env.AWS_BUCKET_NAME,
},
},
},
},
};

Step 3: Verify Environment Variables

Ensure your custom environment variables are properly set in your Strapi Cloud project settings. The environment-specific configuration files can access these variables after the build step.

Alternative Solution for Admin Panel Variables

If you need to access environment variables in the admin panel (such as STRAPI_ADMIN_ prefixed variables), the environment-specific configuration approach won't work. Instead, you'll need to create a custom route and controller to fetch the environment variable from the backend and make it available to your admin panel components.

Why This Works

Environment-specific configuration files like ./config/env/production/plugins.ts are loaded after the build step, when custom environment variables become accessible. This allows your third-party providers to receive the proper configuration values and function correctly in production.

This workaround has been confirmed to work for various cloud providers including Google Cloud Storage, AWS S3, Cloudinary, and email services like SendGrid.