[Bug]: strapi import silently deletes cloud provider assets without warning

[axelabtion]

Link to the documentation page or resource

https://docs.strapi.io/cms/data-management/import

Describe the bug

Summary

The strapi import command, when run against a Strapi instance using a cloud
storage provider, permanently deletes files from the cloud provider for any
media records that exist in the destination database but are not present in the
import archive. This behavior is not documented and results in irreversible
data loss on the cloud provider.

Current documentation warning

The import page states:

"strapi import deletes all existing data, including the database and uploads
directory, before importing the backup file."

This warning only references the local "uploads directory" and gives no
indication that cloud-hosted assets will be deleted via the provider's API.

Impact

• If two environments (e.g. staging and production) share the same cloud
  storage account, running strapi import on one environment with an export
  from the other will delete any files that were uploaded after the export was
  created — permanently removing them from the shared storage and breaking
  assets in all connected environments.
• There is no dry-run option, no confirmation prompt specific to cloud assets,
  and no way to recover deleted files unless the cloud provider offers its own
  backup or versioning feature.

Steps to reproduce

1. Set up two Strapi instances (e.g. production and staging) pointing to the
   same cloud storage account.
2. Upload some files on the staging instance (these will not exist in a
   production export).
3. Run strapi export on production to create an archive.
4. Run strapi import -f export.tar.gz.enc on staging.
5. Observe that the files uploaded in step 2 are permanently deleted from the
   cloud storage provider, even though both environments shared the same
   account.

Environment

• Strapi version: v5
• Storage provider: third-party cloud upload provider
• Deployment: cloud-hosted

Additional context

No response

Suggested improvements or fixes

Expected behavior

The ideal fix would be a behavioral change: strapi import should not
delete remote assets for cloud storage providers unless explicitly
instructed to do so via a flag such as --delete-remote-files. Deleting
records from the local database and deleting files from a remote cloud provider
are two fundamentally different operations — the latter should always require explicit opt-in.

At a minimum, the warning box on the documentation for the import page should be updated to include:

If you are using a cloud storage provider (e.g. Cloudinary, AWS S3, Azure
Blob Storage, Google Cloud Storage), any media files whose database records
are removed during import will be permanently deleted from the cloud provider
via its delete API. This affects all environments sharing the same cloud
storage account. To avoid unintended deletion of remote assets, use
--exclude files or ensure each environment uses an isolated storage
bucket/account.

Related issue(s)/PR(s)

No response

[github-actions]

🤖 I've analyzed your question and here's what I found:

Thanks a lot for taking the time to document this so clearly and for highlighting the potential for data loss — this is exactly the kind of detailed report that helps us improve both Strapi and the docs.

From the documentation side, here’s what we can confirm and how it relates to what you’re seeing:

• The strapi import command is documented as destructive: it “deletes all existing data, including the database and uploads directory, before importing the backup file.” [Data import]
• It also supports excluding or including specific data types (content, files, config) via --exclude and --only. For example, --exclude files will skip importing assets, but the docs already warn that excluded types are deleted in the target instance. [Exclude during import; Include only specified]
• For cloud environments, the Upload plugin is typically configured with a third‑party provider (Cloudinary, S3, etc.) via config/plugins.(js|ts), and Strapi will call that provider’s upload/delete APIs as part of normal asset lifecycle. [Cloudinary provider; Cloud upload config]

However, the current strapi import documentation:

• Explicitly mentions deletion of the local uploads directory, but
• Does not explicitly warn that, when a third‑party upload provider is configured, asset deletions will be propagated to that provider (and therefore can affect all environments sharing the same bucket/account). [Data import]

So your point about this being surprising and potentially causing irreversible data loss on shared cloud storage is absolutely valid, and the docs do not currently spell this out.

---

Short‑term workarounds

Based on the current documented behavior and options, here are some concrete mitigations you can use today:

1. Avoid deleting remote assets by excluding files

   If you want to preserve existing assets in the target environment (and its shared bucket), you can run import with:

   yarn strapi import -f /path/to/export.tar.gz.enc --exclude files
   # or
   npm run strapi import -- -f /path/to/export.tar.gz.enc --exclude files

   This prevents the import from handling files at all, though note the warning that excluded types are deleted in the target instance, so you should test this carefully in a non‑critical environment first. [Exclude during import]

2. Use isolated storage per environment

   As you suggested, configuring each environment (prod, staging, etc.) with its own bucket/account in config/env/<env>/plugins.(js|ts) avoids cross‑environment impact when assets are deleted via the provider. [Cloud upload config]

3. Use strapi transfer for full environment copies

   When moving data between Strapi instances, the strapi transfer feature is designed to move content, files, and config between environments and also supports excluding files (--exclude files). [Transfer setup; Transfer exclude]

   Example:

   yarn strapi transfer --to https://example.com/admin --exclude files

---

About the behavioral change you’re proposing

The knowledge sources don’t describe a flag like --delete-remote-files or any special handling for third‑party providers during strapi import, so I can’t confirm that such a behavior exists today. [Data import]

What you’re asking for is essentially:

• A safer default when a remote provider is configured, and/or
• An explicit opt‑in flag before deleting remote assets.

That goes beyond documentation and into core behavior, so this looks like a product bug / core‑functionality concern rather than just a docs tweak. Tagging for visibility: @pwizla.

---

Documentation improvement

Based on the current docs, there’s room to:

• Expand the existing warning on the strapi import page to explicitly mention:
  • Third‑party upload providers (Cloudinary, S3, etc.),
  • That asset deletions will call the provider’s delete API,
  • The risk when multiple environments share the same bucket/account,
  • The --exclude files option and the recommendation to use isolated buckets per environment. [Data import; Exclude during import; Cloud upload config]

Your suggested wording is very clear and would be a strong basis for such an update.

---

Next steps

• From a feature/behavior standpoint, this deserves core team review. I’d recommend also submitting this as a feature/behavior request on our public board so it can be tracked and upvoted: https://feedback.strapi.io
• From a docs standpoint, we can use this issue as input to strengthen the warnings on the strapi import page and related data‑management docs.

Thank you again for surfacing this and for providing such a thorough reproduction and suggested text. It’s very helpful, and we really appreciate your care in protecting other users from unexpected data loss.

📚 Relevant documentation:

• Backups in Strapi Cloud - Downloading a backup
• Cloudinary provider
• Command Line Interface (CLI) - strapi import
• Data export
• Data export - Exclude items from export
• Data import
• Data import - Bypass all command line prompts
• Data import - Exclude data types during import
• Data import - Include only specified data types during import
• Data transfer - Bypass all transfer command line prompts
• Data transfer - Exclude data types during transfer
• Data transfer - Setup and run the data transfer
• Documentation release notes - Chore, fixes, typos, and other improvements
• Project settings - Transferring data between environments
• Upload Provider Configuration for Strapi Cloud - Configure the Provider

---

ℹ️ This response was generated automatically. If this doesn't fully answer your question or if you need further assistance, please mention @pwizla in a comment and a human maintainer will help you.

You can also try our interactive AI chat for more detailed assistance.

💡 For feature requests or product feedback, visit feedback.strapi.io.

[pwizla]

Hi @axelabtion, I'm Pierre, Documentation Architect at Strapi. I'm sorry you had to deal with this issue 😔
I've just updated the documentation page.

The Strapi Support Team also told me that the assets should still be safe in a folder on 3rd party provider bucket, though.

I will now close this issue as it's fixed from a documentation point of view. Feel free to create an issue in the strapi/strapi codebase with your request for the new parameter, and to re-open this issue or create a new one if you need further help with the Strapi documentation.

[axelabtion]

What we are seeing, is that it is not safe in a 3rd party provider bucket.