Strapi media storage with S3 and upload providers guide

Why Strapi media storage with S3 needs planning before launch

If your self-hosted Strapi project still keeps uploads on the application server's disk, moving them to shared, durable storage is usually an upload provider configuration plus a migration of the files that already exist. That summary hides the work that decides whether the change holds up in production. Media is the part of a Strapi project where stored state lives in three places at once: the database records that describe each file, the binary objects in the bucket, and the URLs that front ends and editors use to reach them. Changing one without the others is how broken images and orphaned records appear after launch.

Stored URLs are the first trap. Existing records may hold absolute or relative paths that point at the old host, and content editors, saved front-end code and cached pages may depend on them. Decide before cutover whether the new provider returns public bucket or CDN URLs, whether old URLs need a redirect or rewrite, and how you will test that every media field in every content type resolves. Multiple instances add a second risk: once several Strapi processes share one database and one bucket, any instance still writing to local disk will create files the others cannot see. Confirm that every instance uses the same provider settings before the first deployment.

Permissions are the next decision. The bucket policy, the credentials Strapi uses and any public read path need to be scoped separately so that the application can write and delete objects without gaining broad administrative rights. Review who can reach the bucket directly, how credentials are stored in the environment, and whether deletes in Strapi should remove the object or only the record. CDN caching adds a further layer: a replaced file under the same name can be served stale for as long as the cache holds it, so agree on a naming and invalidation approach before editors start replacing assets.

Image variants and formats need the same care. Strapi generates resized formats for uploaded images, which multiply the number of objects per file and affect storage volume and migration time. Confirm which variants the project actually uses, whether generation happens on upload or on demand, and whether your front end expects specific formats. Strapi 5 minor releases have shipped roughly weekly, for example v5.57.0 on October 7, 2026 and v5.58.0 on October 14, 2026, so the provider package and its compatibility with your Strapi version must be rechecked on every upgrade, not only at launch. Put that check into your upgrade routine and record which provider version was tested with which Strapi version.

Which Strapi upload components and settings are involved

Moving Strapi media off the application server touches several layers at once: the upload plugin, a provider configuration, database records and the URLs that browsers receive. Each layer has its own settings and failure modes, so they should be reviewed together before any existing files are moved.

Upload plugin and provider setting

Strapi's upload plugin handles file intake, validation and storage calls, and the provider setting decides where the bytes go. Changing the provider changes how every new upload is written, but it does not move files already stored locally. Confirm the provider package name and its option names in the Strapi documentation for the exact Strapi 5 version in use, because these names are version-specific and should not be copied from older examples.

Provider configuration block

The provider block holds bucket names, regions, endpoints, credentials and optional settings such as ACL or path prefixes. It normally lives in the config files and reads values from environment variables, so secrets stay out of source control. Ask who owns these values in each environment and how they are rotated, since a wrong endpoint or region usually shows up as broken uploads rather than a clear startup error.

Media library records in the database

Strapi stores file metadata such as names, MIME types, sizes, dimensions and the provider location in the database, while the binary content sits in the storage provider. This split means a backup of the database alone does not capture the media, and a bucket copy alone does not restore the links between files and content entries. Plan backups for both and confirm how the metadata references the provider path before migrating.

Public and signed URL behavior

Delivered media URLs depend on whether the bucket or storage service serves objects publicly or requires signed, time-limited links. Public buckets are simpler but expose any object whose address is known, while signed URLs add expiry handling in the front end and caching behavior to test. Confirm with the provider and the Strapi documentation how URLs are generated for private content, and check that previews and API responses return links that still work after expiry.

CDN and image transformation settings

A CDN in front of the bucket changes the public hostname, cache lifetimes and purge workflow, and any image transformation layer adds its own formats and sizes. Each option has to be reflected in the URL base that Strapi returns, or front ends will request files from the wrong host. Confirm which transformations the chosen provider and CDN support, and decide whether generated formats are stored or created on request, because that choice drives storage cost and cache behavior.

Migration and rollback checks

Existing uploads need a tested path that copies objects, updates stored locations and verifies that every entry still resolves to a working file. The order of operations matters: switching the provider before copying leaves old records pointing at empty paths. Agree on a rollback point and keep local files until the new URLs have been checked from every front end and environment.

Choosing an S3-compatible provider or other upload service

This table compares the main storage paths for Strapi uploads: AWS S3, an S3-compatible object store in your own infrastructure, a vendor media service with its own API, and local disk. Read each row for the conditions that favor it and the recurring operating work it adds. Pricing, egress terms and feature support change, so confirm them directly with each provider before you choose.

Option	When it fits	Operational cost to plan for
AWS S3	Existing AWS accounts, approved regions, and teams already operating IAM and CloudFront.	Request and egress billing, IAM credential rotation, and lock-in to AWS APIs. Confirm pricing with AWS.
Self-hosted S3-compatible store	Data residency or air-gapped networks where media must stay in your own data center or cloud account.	You run storage, backups, capacity, TLS and access keys. Confirm S3 API coverage and signed URL support with the software vendor.
Vendor media service	A managed media pipeline with its own API, where the contract, region and exit terms meet your policy.	Usage-based fees, API keys to rotate, and lock-in to vendor URLs and transforms. Possible separate CDN charges. Confirm all terms in writing.
Local disk on application server	Single-instance test sites or small internal sites where uploads can stay on one host.	Uploads are tied to one server, so backups must cover the media directory. Multiple instances will not share it without a shared volume.
Signed URLs and CDN delivery	Private documents or paid content need expiring links. Public images benefit from caching in front of storage.	Check each option's signed URL support, origin access rules and cache invalidation. Confirm these features with the vendor during design.

Configuring Strapi media storage with S3 step by step

This sequence moves Strapi media from the application server to an S3-compatible bucket, with a check at each stage so the team knows the configuration works before any existing files are moved. Each step names who does the work and the output that closes it.

Create a bucket with least-privilege access
The cloud or platform engineer creates a dedicated bucket for Strapi uploads and a service identity used only by the Strapi server. Grant that identity only the object actions the upload provider needs on this bucket, with no access to other buckets or account-wide administration. Keep public access blocked at the bucket level until step four decides which content types are public. The step is done when a test object written with the service identity succeeds and the same identity is denied access to an unrelated bucket. Confirm the exact actions required with your provider package documentation, since they vary by package and version.
Store credentials outside the code
The platform engineer places the access key and secret in environment variables or a secret manager that the hosting platform injects at runtime. Keep them out of configuration files committed to the repository, out of container images and out of anything editable in the admin panel. Confirm that a scan of the repository and the image build finds no key material, and that a rotation can be completed by updating the secret and restarting the service. The check is a running instance that reads the bucket using the injected credentials, combined with a clean search of the codebase.
Install and configure the provider package
The Strapi developer installs the upload provider package for the target service and registers it in the upload plugin configuration of the project. Set the bucket name, region or endpoint, and credentials through environment references, along with any path or prefix settings the team wants. Endpoint and path style settings differ between S3-compatible services, so use the provider's documentation for the options your service requires. Verify by starting the Strapi server locally and confirming that it starts without configuration errors.
Set public or signed URL behavior
The Strapi developer and the content owner decide which media is public, such as marketing images, and which needs signed URLs, such as documents behind a login. Apply public read access only to the bucket or prefix that holds public media, and use the provider's signed URL option for the rest if the chosen package supports it. Confirm each setting by requesting one public file and one private file from a browser without credentials. The public file should load, and the private file should be denied or should stop working after its expiry time.
Set bucket CORS rules for admin uploads
The cloud engineer adds CORS rules to the bucket so the Strapi admin panel origin can send upload requests and read the responses from the browser. Allow only the admin panel origin and the HTTP methods the upload needs, and avoid a wildcard origin on any bucket that holds private files. Verify in the browser developer tools that the upload request returns the expected headers and raises no CORS error. Complete this step before testing uploads from the admin panel.
Configure the CDN origin if used
If the team serves media through a CDN, the platform engineer points the CDN origin at the bucket or its public endpoint and sets caching rules that match the public and signed URL decisions from step four. Confirm the origin type and access method with the CDN provider, because bucket access for a CDN can differ from direct public access. Check that the CDN returns a public file, that cached copies are not served for private files, and that a changed file is reflected after the cache expires or is purged. If no CDN is used, record that decision and skip this step.
Upload test files from admin and API
The Strapi developer uploads one image, one document and one video, each at a size the team expects, from the admin panel. Then the developer uploads a file through the Strapi REST API using a token with upload permission. Attach each file to a test entry so the media library and relation handling are both exercised. Confirm that both paths succeed and that the API response includes a URL pointing to the storage location rather than a local server path. Run these tests in a non-production environment.
Confirm stored URLs and keep local copies
The QA lead opens each stored URL from the test uploads in a browser and checks that it resolves. In the bucket console, the lead confirms that the objects appear under the expected prefix with the expected names and content types. Do not delete the local upload directory during cutover. Keep it as the only complete copy until the migration of existing uploads has been verified in the bucket, and treat it as the rollback source until the team signs off. The step is complete when every test file resolves, every object is in the bucket, and the rollback source is documented.

What drives Strapi media storage effort and cost

This table lists the factors that change how much work and spend a Strapi media storage project carries, and how to keep each one contained. Read the first column as the driver, then compare the effort it adds and the way to limit it. The main takeaway is that a single provider, a single CDN and one tested configuration reused across environments do most of the work of keeping effort down.

Driver	Why it changes effort or cost	How to keep it down
Existing files and total size	Migrating uploads means copying every file, rewriting stored URLs and verifying each copy. Volume sets the copy window and the one-time transfer charges.	Ask for an inventory of files by size and content type first. Migrate only media still referenced by published or draft entries.
Number of environments	Each environment needs its own bucket or prefix, credentials, CORS rules and testing. Drift between environments is a common source of broken images.	Build one provider configuration as code and reuse it in development, staging and production with different values only.
Several Strapi instances	Instances behind a load balancer must all point at the same external provider. A local upload folder on one node loses files on the others.	Confirm the upload provider is external before scaling. Test that an upload on one instance is readable from all of them.
Image variants and transformations	Generated thumbnails and formats multiply stored objects and processing time. Changing a variant later can mean regenerating existing files.	Agree the list of required sizes and formats with the front-end team before build. Generate variants on demand only where the provider supports it.
CDN and cache rules	Cache keys, invalidation after replacement, signed URLs and origin access settings each need configuration and testing. Mistakes show up as stale or exposed files.	Scope one CDN and one cache policy. Document the invalidation step used when a file is replaced or removed.
Storage location and access logging	Data residency, encryption settings and access log retention are set by your compliance obligations, and each must be configured and evidenced. Assessors usually ask for proof of these settings, not descriptions.	Confirm required regions, encryption and log retention with your compliance lead before selecting a bucket. Keep configuration in version control so changes leave a record.
Integrations that read media URLs	Front ends, mobile apps, search indexes and export jobs each store or parse media URLs. A URL format change affects every consumer.	List every consumer and its URL assumptions before cutover. Keep the public URL pattern stable or provide a redirect plan.
Credential rotation	Access keys for the provider recur on a schedule set by your policy. Each rotation touches every environment and instance that holds the key.	Use short-lived or role-based credentials where the provider supports them. Store keys in a secrets manager and automate rotation.
Provider and plugin upgrades	Upload provider packages and S3 SDK changes need testing against your Strapi version. Upgrades recur as Strapi 5 minor releases ship frequently.	Pin provider package versions. Keep an automated upload and retrieval test that runs after each upgrade.

How media storage differs across single node, HA and air-gapped setups

A single node runs Strapi and stores uploads on the same server's disk by default. This is the simplest setup to build and back up, and it needs no external storage service. The trade-off is that media lives with the application, so the server's disk size, backup routine and failure domain all decide how safe your files are.

Points to check:

Disk capacity: Uploads grow with content. Confirm how much space you can add to the volume and how quickly you can expand it.
Backup coverage: Media files are not in the database. Confirm that your backup job copies the uploads directory as well as the database.
Recovery path: If the server is rebuilt, confirm how uploads are restored and whether the restored files match the database records.
Migration cost later: Moving existing local uploads to an external provider later is a separate task. Ask a partner to estimate it from your file count and total size.
Provider choice: Even on one node, an S3-compatible provider can separate media from the application server. Confirm whether your hosting setup supports it.

Before you commit, confirm the backup and restore procedure for media files, not only for the database.

Migrating existing uploads without breaking stored links

Changing the upload provider does not move anything by itself. In Strapi, each uploaded file is recorded as a row in the upload file content type, and that row stores metadata such as the file name, MIME type, size, hash, and a provider-specific reference. The URL that the front end receives is usually built from the provider's base URL and the stored path, and rich text or JSON fields may also contain absolute URLs written in earlier content. When the provider or base URL changes, every stored link that pointed to the old location becomes a dead reference unless you deliberately keep both locations working. Before you change any setting, confirm with your team which fields hold media (single and multiple media fields, rich text blocks, custom JSON fields and components) and whether any content embeds absolute URLs to the old host. Those are the places where a bucket move quietly breaks pages long after the migration appears finished. Start with an inventory. Count the records in the media library and compare them with the files on the local upload directory of each Strapi instance, including the thumbnails and formats Strapi generates, because a missing variant can surface only when a page requests a specific size. Record the current provider, the current base URL, and any custom path or key naming. Then copy the objects to the new bucket with the same relative paths or keys, so the stored path in each record still resolves once the base URL changes. Keep a checksum or size comparison for each object so you can prove that the copy is complete and identical. Ask whether your storage team has versioning, lifecycle rules or bucket policies that could delete or transform objects during the copy window. Next, decide how URLs will resolve. You can rewrite stored absolute URLs in the database, or you can keep a consistent public base URL in front of both locations, for example through a CDN or a reverse proxy, so that existing links keep working while the backing store changes. Run the rewrite or the base URL change first against a restored copy of the production database, not against production. Take a database backup immediately before any change and confirm that you can restore it. Test the rollback path as well: know which environment setting reverts the provider, how long the old bucket will be retained, and who approves the rollback. Strapi's documentation says downgrading is not supported, so the rollback is a restore and a configuration switch, not a reverse data migration. Switch the environment setting only after the dry run has passed on the copy and the front end has been checked against it. Keep the old files until verification passes, which means comparing sampled URLs from the admin panel and the public API, confirming that media loads through the CDN, and watching logs for 404 responses. Plan the removal of the old objects as a separate, later change. If your project is still on Strapi v4, stop here: the v4 to v5 migration has its own upgrade tool, codemods and data migration steps, and this page assumes a Strapi 5 project.

Securing bucket access, signed URLs and upload secrets

Media storage moves files out of the Strapi server, which widens the set of places where access can go wrong. The cards below cover the bucket, the service identity that writes to it, how restricted files are served, and how Strapi itself limits what editors can upload.

Dedicated service identity for uploads

Create a separate identity that Strapi uses only for the media bucket, with write and read permissions limited to that bucket and its prefix. Do not reuse credentials from other applications or from a human administrator account. Check that the identity cannot list other buckets or change bucket policies, and confirm the exact policy syntax with your chosen provider's documentation before deployment.

Blocking public listing on the bucket

Keep bucket listing closed to anonymous users, so that a visitor who knows a file URL can fetch that object but cannot enumerate every file the CMS has stored. Verify this by requesting the bucket root without credentials after setup. Provider defaults differ, so confirm the block-public-access settings in your provider's current documentation.

Public read for approved content only

Grant anonymous read access only to a prefix or bucket that holds content meant to be public, such as published article images. Keep drafts, internal documents and personal files outside that scope. Review the policy whenever a new content type starts storing files, because a shared prefix can expose files that editors assumed were private.

Private media and signed URLs

For restricted files, keep the bucket private and issue time-limited signed URLs from Strapi or from a delivery layer only after the request passes your authorization rules. Decide the expiry window with the content owners, since a long window makes a leaked link useful for longer. Test that an expired or altered link is refused.

Secret rotation without code changes

Load storage keys from environment configuration or a secrets manager rather than from source files, so the credentials can be rotated without a code release. Plan a rotation procedure that creates the new key, updates the environment, restarts Strapi instances and then revokes the old key. Confirm how your hosting platform handles restarts so that uploads are not lost during rotation.

Upload type and size limits in Strapi

Restrict accepted file types and maximum file sizes in Strapi's upload settings and in the field configuration of each content type, so that editors cannot upload executables or oversized files. Check these limits at the Strapi layer and at the bucket or proxy layer, because the first control does not stop requests sent directly to the storage endpoint.

CORS limits for admin uploads

Allow cross-origin requests to the bucket only from the Strapi admin origin and only for the methods that uploads require. Avoid wildcard origins on write-enabled rules. Test uploads from the admin panel after any domain change, because CORS rules are often the cause of failed browser uploads.

Bucket access logs and review

Turn on server access or audit logging for the media bucket and send logs to a location the application identity cannot modify. Review who read restricted objects and which identities wrote or deleted files. Confirm the logging options, retention and cost with your provider, and check whether your compliance obligations require a specific retention period.

Testing Strapi media storage with S3 and CDN delivery

Testing an S3 and CDN media setup for Strapi should prove four things before cutover: every file type uploads and resolves correctly, a failed storage call never leaves a broken media record behind, all instances behave the same, and the provider can be rolled back without breaking links that already exist. Write these checks down as acceptance criteria with an owner and a pass condition for each, so the result is evidence rather than a judgment that the uploads seemed fine. Start with uploads from both the admin panel and the REST or GraphQL upload endpoint, using a test API token with the scope the front end will really use. Cover every file type in use, not just images: PDFs, video, audio, SVGs and any large files that will go through multipart handling. For each upload, confirm three things: the object exists in the bucket under the expected prefix, the media entry's stored URL resolves from outside your network, and the stored file's content type and size match what the admin panel shows. Check how the provider configuration handles private versus public objects, since a public bucket policy that works for images may expose documents you meant to restrict. Deletion needs its own test. Delete a media entry that is referenced by a content entry, then confirm whether the object was removed, flagged or left in place, and whether that matches the design you agreed. Also test replacement: upload a new file over an existing entry, then confirm the CDN serves the new content after invalidation and that the old cache entry no longer returns stale bytes. Verify this against the actual CDN behavior, since cache TTLs and invalidation timing are set in your CDN and your provider settings, not by Strapi. Two failure tests are where most launches go wrong. Configure a wrong secret key or bucket name in a non-production environment and attempt uploads: they should fail with a visible error in the admin panel and API, and no media record should be created pointing at a missing object. Then simulate an unreachable provider endpoint and repeat. Run the same uploads against every instance behind the load balancer, because a single node with stale environment variables is a common cause of intermittent failures. Finally, after migrating existing uploads, compare checksums or byte sizes between source and destination for a sample that includes the largest and oldest files. The rollback test is the one teams skip. Record the current provider configuration, switch to the new provider, then restore the previous setting in a staging copy. During the rollback window, confirm that existing URLs for migrated and newly uploaded files still resolve, and decide in advance how long the old storage must remain available. Confirm with your storage vendor and CDN provider how their own retention and invalidation behave during that window, since those limits belong to them, not to this plan.

What to monitor, back up and document after go-live

Once Strapi media lives in a bucket and behind a CDN, failures move out of the application server and into storage, delivery and credentials. The items below are the checks that keep uploads, delivery and access working after launch, and most of them need a named owner before go-live.

Upload error rates and failed writes

Track the rate of failed uploads from the Strapi admin panel and API, broken down by provider errors such as permission denials, timeouts and rejected object sizes. Set an alert on a sustained rise rather than single failures, and confirm that the provider's error logs are retained long enough to trace an incident. Editors often notice this first, so agree who receives the alert and who responds.

Bucket growth and storage cost

Watch total bucket size and object count over time, and compare growth against what editors expect to publish. Unused variants, abandoned drafts and duplicate uploads can grow a bucket without anyone noticing. Confirm whether the provider bills for stored data, requests and data transfer separately, because each line item moves differently as the library grows.

Request volume and egress charges

Measure requests to the bucket and data transferred out of it, especially when pages load many images on each view. Egress is often the largest recurring line for media-heavy sites, and it rises when the CDN cache hit ratio falls. Ask the provider for its current request and egress price tiers and any free allowance, then set a budget alert in the cloud account that pays for the bucket.

CDN hit ratio and cache rules

Track the share of media requests served from the CDN cache rather than the origin bucket, and watch for drops after a deployment or a change to URL patterns. A low ratio usually points to missing cache headers, query strings that split the cache, or image transforms generated on every request. Review the cache rules whenever the image formats or sizes served to the front end change.

Certificate expiry for custom domains

If media is served from a custom domain such as a subdomain you control, the TLS certificate on the CDN or load balancer must renew before it expires. Record which certificate covers which hostname, where it is managed, and whether renewal is automatic. Add an expiry alert that fires well ahead of the date, because a lapsed certificate breaks every image on the site at once.

Database and bucket backups

Back up the Strapi database and the bucket as separate items, since the database holds the file metadata that points to each object. Confirm whether the provider offers object versioning, replication to a second region or bucket, and how long deleted objects remain recoverable, because these features differ by provider and plan. Test a restore of a few objects and one database snapshot before relying on either.

Upgrade planning for Strapi and the provider package

Strapi 5 minor releases ship frequently, and the upload provider package is a separate dependency that can change independently. Schedule a regular review of both, run upload, delete and image format tests in a staging copy of the bucket, and record which versions passed. Read the release notes for changes to provider configuration before updating.

Environment variables, bucket policies and CDN settings

Write down every environment variable the upload provider reads, the bucket policy and CORS rules that permit Strapi to write and the front end to read, and the CDN origin, cache and transform settings. Keep this record in version control next to the deployment code, not in a single administrator's notes. It is the first thing an engineer needs when an upload fails at 2 a.m.

Rollback steps for media changes

Document how to revert a Strapi release or provider change that breaks uploads, including which configuration files change, how to restore the previous package version, and whether existing objects need any action. Rehearse the steps in staging. Rollback is harder when a data migration has already run, so note which steps cannot be reversed.

Owners for credential rotation

Assign a named owner for each access credential used by Strapi to reach the bucket, including the access key pair, the CDN token and any signing secret. Set a rotation schedule that the owner confirms, and check that the rotation procedure does not break uploads in progress. Record where each secret is stored so that a departing team member does not take the only copy with them.

What buyers ask before bringing in a partner for Strapi media storage

Can our own team set up Strapi media storage with S3 without a partner?

Yes, many teams can, if they already run Strapi in production and have engineers comfortable with cloud identity and storage settings. The provider configuration itself is the smaller task. The work that usually stalls in-house includes IAM policies scoped to one bucket, deciding which objects are public and which are private, CORS settings for the admin panel, a plan for moving existing uploads, and a tested rollback. Ask whether your engineers have made an upload change in production before and who will own the bucket policy and keys after launch. A partner is most useful when the team lacks cloud identity experience or cannot spare time for a proper test window. Strapi Community Edition is MIT-licensed, so the software itself carries no license fee for this work, but your labor and cloud charges still apply.

What drives the cost and effort of Strapi media storage work?

The agreed scope drives most of the cost more than the choice of provider does. The main components are designing bucket and identity access, the number of content types and media fields that reference uploads, the volume and variety of existing files, the CDN decision, the number of environments, and the test window. One-time costs cover setup, migration of existing uploads and testing. Recurring costs include storage, data transfer and CDN charges that your cloud provider bills you based on usage, plus any ongoing support retainer. Those cloud charges come from your provider and your traffic, so ask the partner to list them separately from services. DeployOpen does not publish a price list. A quote follows from a written, fixed scope, so ask for timing and cost per workstream, not one total.

What does the client need to provide before media storage work starts?

Mostly access and decisions. Provide a bucket or an agreed naming and region plan, an identity whose rights are limited to that bucket, the choice of S3-compatible provider, network paths from the Strapi hosts to storage and any CDN, and a test window in a non-production copy where uploads can be exercised. Name an owner for the bucket policy, access keys and rotation. Ask for credentials to be issued through your secrets process. If Strapi runs in an air-gapped network, the storage endpoint must be reachable inside that network, which can narrow the provider choice. Confirm each dependency with your cloud, network and security teams before kickoff, because the written scope will list them as client responsibilities.

How are existing Strapi uploads moved to external storage?

Existing files stay on the application server until they are copied, and the database records that point to them must be updated to match. A common sequence is to inventory the upload folder and its database entries, copy the objects to the bucket using the same paths or a mapped path, verify counts and checksums, then switch the provider and check sample pages against the new URLs. Keep old URLs working during cutover and keep the original files until verification is signed off. Total file count and size determine how long the copy runs, so request the inventory before quoting. Also confirm whether generated image formats exist in the old set and whether they need regeneration. The copy script should be safe to re-run if it is interrupted.

Does moving Strapi media to S3 mean the CDN must change?

Not always, but the CDN origin and URL patterns usually need review. A CDN can keep serving media if its origin points at the new bucket or a stable public hostname, and the URLs Strapi returns resolve correctly. Changes are typically needed when the CDN currently pulls from the Strapi server, when private objects require signed URLs, or when the hostname changes. Cache invalidation after cutover should be a documented step. Confirm with the team that runs the CDN whether the origin, cache rules and TLS certificates need updates. Front-end code should not hard-code old hostnames, so ask the partner to list every media URL pattern the front end uses before cutover.

How do Strapi upgrades affect the upload provider package?

The upload provider is a separate package, so a Strapi core upgrade can require a matching provider version. Strapi 5 minor releases have shipped frequently, for example v5.57.0 on October 7, 2026, so compatibility checks need to happen on a regular cadence. Before each upgrade, confirm the provider supports the target Strapi version, pin versions in your lockfile, and test an upload, a read and a delete in staging. Moves such as v4 to v5 need the provider reviewed as part of the migration plan, since older projects may run older provider packages. Confirm compatibility with the package maintainer's release notes, and include the provider's SDK dependencies in your regular dependency patching cycle.

What does ongoing support cover after Strapi media storage goes live?

After launch, the usual scope covers monitoring upload and delivery errors, reviewing bucket policies, rotating access keys, updating the provider and its dependencies, testing media behavior after each Strapi upgrade, and reviewing access. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Whether a retainer includes monitoring, on-call response or upgrade testing depends on what is written into that scope, so read the scope line by line. Storage and transfer charges from your cloud provider continue as a recurring cost. Before signing, ask for the response process, the review schedule and the list of exclusions.

How DeployOpen scopes, builds and hands over Strapi media storage

DeployOpen plans media storage as part of the Strapi build, from the start. Each engagement settles where uploads are kept outside the application server, which upload provider serves them, how files reach readers, and how existing uploads move across. Work runs inside your own cloud accounts, data centers or air-gapped networks, under a written, fixed scope.

How we scope

The written scope names the storage target, such as an S3-compatible bucket, and its owner.
It records which content types and fields hold media, and which image formats and sizes must be generated.
Scope also covers CDN delivery, access rules for private files, and migration of existing uploads, if needed.

How we build

Install and configure the upload provider, keeping credentials in environment configuration and out of the codebase.
Set bucket policies, public or signed access for each file type, and CORS rules for admin uploads.
Test uploads, previews, image format generation and deletion behavior in staging before cutover.

How we hand over

A runbook covers configuration values, bucket layout, access policies, and how to rotate storage credentials.
Documented steps for the migration run, including file counts, reconciliation results and a tested rollback path.
A walkthrough with your platform and content teams covers how editors upload, replace and remove media.

How we support

Ongoing support is available as a retainer, covering upload provider plugin updates and dependency security fixes.
Support can include checks after Strapi 5 minor releases, which ship roughly weekly, to confirm uploads still behave.
Agree during scoping which storage, CDN and backup responsibilities stay with your team after launch.