How to Install Uploads to S3 for WordPress Safely

Uploads to S3 can synchronize configured WordPress media and storage paths to Amazon S3, rewrite eligible public URLs, and optionally remove local sources after a successful upload or positive verification. The plugin provides the WordPress side of the workflow. A safe implementation also requires a deliberately configured AWS bucket, limited credentials, a path plan, public-delivery decisions, and a staged migration test.

Choose the storage architecture first

Decide whether S3 will serve media directly or sit behind Amazon CloudFront. A public base URL can point to either delivery path. CloudFront is optional and must be created and configured in AWS separately; setting a distribution hostname in WordPress does not provision the distribution, certificate, cache policy, or origin access.

Define object prefixes before uploading files. A predictable structure such as an environment or hostname prefix keeps production, staging, and multiple sites from writing to the same object keys. Domain-to-prefix mappings are especially useful when installations share a bucket. Avoid changing that plan after a large migration because moved objects, saved attachment URLs, caches, backups, and external references can all depend on it.

Also decide which local paths belong in S3. The normal WordPress uploads directory is the usual starting point. Custom plugin storage, exports, private files, caches, temporary files, and executable code need separate decisions. Public media and protected downloads do not have the same access requirements.

Prepare the AWS side with limited access

1. Create or select the S3 bucket in the intended AWS account and region. Record the exact bucket name and region; a mismatch can look like a credential or network failure.
2. Create dedicated credentials for this site or workload. Do not reuse an administrator’s general AWS access key.
3. Grant only the bucket and prefix permissions needed for the enabled operations. The product documents operations including PutObject, GetObject, HeadObject, CopyObject, DeleteObject, ListBucket, and PutBucketCORS. Restrict resources and prefixes rather than granting account-wide S3 access.
4. Choose a public-delivery model. Do not disable S3 public-access protections globally just to make one test object load. Prefer a reviewed bucket or CloudFront policy that exposes only the content meant for visitors.
5. Configure CORS only for origins and methods the actual browser workflow needs. Server-to-server uploads alone may not require the same browser permissions as direct client uploads.
6. Store credentials in a secrets process with named ownership and rotation. The plugin supports WordPress settings or wp-config.php constants; constants are often preferable when deployment tooling already protects configuration, but the right choice depends on how the site is operated.

Install and connect the plugin

Uploads to S3 currently requires WordPress 6.0 or newer and PHP 7.4 or newer. Confirm those minimums and review compatibility with the active theme, WooCommerce, image optimization, backup, security, and caching plugins. Take a database and filesystem backup, then use staging when the Media Library already contains important assets.

1. Download the purchased ZIP from CodingRepo. In WordPress, go to Plugins, choose Add Plugin and Upload Plugin, install the ZIP, and activate it.
2. Open the plugin settings and enter the region, bucket, credentials or constant-based credential mode, and public base URL.
3. Add the current site’s domain-to-prefix mapping. Verify production and staging do not resolve to the same prefix unless shared objects are an explicit requirement.
4. Keep the normal WordPress uploads storage path enabled for the initial test. Leave local-source deletion off.
5. Run the plugin’s connection or inventory checks and confirm it can list the intended prefix without exposing credentials in screenshots or logs.

Run a small, reversible migration

Create one new Media Library image after configuration. Confirm the original and generated image sizes are uploaded to the expected keys. Open the public page and inspect its image URLs, responsive srcset, HTTP status, content type, cache headers, and browser console. Test image editing, replacement, deletion, and any ecommerce gallery or variation images your site uses.

Next, choose a small existing folder or a handful of attachments for manual synchronization. Keep skip-existing checks enabled when appropriate, review every reported failure, and compare object size or other verification data before treating the remote copy as complete. If a local attachment is unavailable but the matching object already exists in S3, test the product’s adoption workflow on a noncritical record before using it broadly.

Do not enable source deletion during the first pass. URL rewriting and object availability should survive a cache clear, an anonymous browser session, and all responsive image sizes first. Retain a separate backup even after synchronization; replication to S3 is not automatically the same as a recoverable backup.

Introduce URL rewriting and CloudFront carefully

When direct S3 delivery is used, the public base URL must match the bucket’s reviewed public endpoint or custom delivery domain. When CloudFront is used, point the public base URL to the configured distribution domain only after the distribution can retrieve the intended objects. Confirm HTTPS, certificate coverage, allowed paths, query-string behavior, compression, and cache policy.

Test pages while logged out so an administrator session does not hide caching or authorization problems. Inspect HTML, CSS background images, feeds, REST responses, Open Graph images, sitemaps, WooCommerce emails, and any external integrations that consume media URLs. Purge the applicable application and CDN caches after a mapping change. A successful WordPress settings save does not prove every visitor-facing reference works.

Enable automation one control at a time

After the pilot succeeds, synchronize existing media in measured batches. Review failed-file details between batches, and avoid saturating PHP workers or network capacity on a live store. Hourly synchronization can be enabled for paths that need it after WordPress cron reliability has been confirmed. Use ignore rules for files or folders that must remain local.

Source deletion deserves a separate approval. Enable it only after verified remote storage, successful URL rewriting, a tested restore path, and monitoring are in place. The plugin deletes a local source only following a successful upload or positive verification, but an operational error elsewhere can still make a remote-only object unavailable. Start with a limited path and watch disk use, missing-object responses, and application behavior before expanding the policy.

Plan monitoring and recovery

• Review synchronization failures and skipped objects on a schedule.
• Alert on elevated S3 or CloudFront 4xx and 5xx responses and unexpected AWS cost changes.
• Retest uploads and generated image sizes after WordPress, image-processing, WooCommerce, or plugin updates.
• Rotate AWS credentials without printing them into tickets, command history, or public screenshots.
• Test the read-only S3-to-local backup scheduler separately if it is enabled, and confirm that S3 remains the master as designed.
• Document how to disable rewriting, restore local files, or switch the delivery base during an incident.

AWS storage, requests, bandwidth, CloudFront, logs, and related services can generate usage charges even though the WordPress plugin itself does not require a recurring SaaS subscription. Set budgets and cost alerts in the AWS account.